Re: WGLC comments on bfd-mpls-05
Rahul Aggarwal <rahul@juniper.net> Thu, 01 May 2008 03:41 UTC
Return-Path: <rtg-bfd-bounces@ietf.org>
X-Original-To: rtg-bfd-archive@megatron.ietf.org
Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F42328C1CC; Wed, 30 Apr 2008 20:41:58 -0700 (PDT)
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F9C28C1CC for <rtg-bfd@core3.amsl.com>; Wed, 30 Apr 2008 20:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.079
X-Spam-Level:
X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRdeIiX0w1+p for <rtg-bfd@core3.amsl.com>; Wed, 30 Apr 2008 20:41:56 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id C38223A6A6C for <rtg-bfd@ietf.org>; Wed, 30 Apr 2008 20:41:55 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Apr 2008 20:41:57 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 20:41:23 -0700
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m413fNx82151; Wed, 30 Apr 2008 20:41:23 -0700 (PDT) (envelope-from rahul@juniper.net)
Date: Wed, 30 Apr 2008 20:41:23 -0700
From: Rahul Aggarwal <rahul@juniper.net>
To: cpignata@cisco.com
Subject: Re: WGLC comments on bfd-mpls-05
Message-ID: <20080430203803.K89520@sapphire.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-OriginalArrivalTime: 01 May 2008 03:41:23.0521 (UTC) FILETIME=[3A0AF310:01C8AB3D]
Cc: Ross Callon <rcallon@juniper.net>, rtg-bfd@ietf.org, dward@cisco.com
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
Hi Carlos, Thanks for the comments. Please see below: > > Please find a couple of comments regarding bfd-mpls-05. I realize this > is way past end of WGLC, but I hope the comments are useful and can be > given consideration. > > > 3.1. BFD for MPLS LSPs: Motivation > > The LSP may be associated with any of the following FECs: > a) RSVP IPv4/IPv6 Session [RFC3209] > b) LDP IPv4/IPv6 prefix [RFC3036] > c) VPN IPv4/IPv6 prefix [RFC4364] > d) Layer 2 VPN [L2-VPN] > e) Layer 2 Circuit ID [RFC4447] > > Does item e) refer to both the PWid FEC and the Generalized PWid FEC > (128 and 129)? > Yes. I will clarify this. > Are BGP Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason? > Will add BGP labeled prefixes to the list. > Also, for the e) FECs, there is the VCCV signaling aspects to be > considered, from RFC4447 / RFC5085 to provide the VCCV control channel > associated with the PW before BFD could be sent. Please also see last > comment. > More on this below. > --- > > 3.2. Using BFD in Conjunction with LSP-Ping > > a) Association of a LSP-Ping echo request message with a FEC. In > the case of Penultimate Hop Popping (PHP), for a single label stack > LSP, the only way to associate a fault detection message with a FEC > is by carrying the FEC in the message. > > Is this the case not only for PHP but also for UHP with exp-null? Correct. Will clarify this. > Additionally for aggregated FECs in general (e.g., in the case of > per-VRF label vs. per-VPNv4-FEC label, etc) the same applies but OTOH > there would need to be only one BFD session per "vrf aggregated fec" > (since it's the same label stack for different VPNv4 FECs, and the LSP > being tested is identical), correct? Could this be clarified in the > document? > The spec is clear on this subject in section 4: "If the LSP is associated with multiple FECs, a BFD session SHOULD established for each FEC. For instance this may happen in the case of next-hop label allocation. Hence the operation is conceptually similar to the data plane fault detection procedures of LSP-Ping." > LSP-Ping provides this > functionality. Next-hop label allocation also makes it necessary to > carry the FEC in the fault detection message as the label alone is > not sufficient to identify the LSP being verified. > ... > i) LSP-Ping is used for boot-strapping the BFD session as described > later in this document. > > There seem to be cases where there is no need for boot-strapping the BFD > session with LSP-Ping. For example, for PWs, both ends can start sending > BFD Control messages with Your Discr value of zero in an Active role, as > the PW Label provides the context to bootstrap the session. > Please see below. > --- > > 4. Theory of Operation > > If there are multiple alternate paths from an ingress LSR to an > egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to > determine each of these alternate paths. A BFD session SHOULD be > established for each alternate path that is discovered. > > There may also be multiple ECMPs for other FECs, like VPNv4/VPNv6 > prefixes. Does this SHOULD apply to those as well? No. As in those cases the ingress LSR knows the multiple paths and there is no need to use the LSP-traceroute mechanism. > For other FECs, there > wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned? > No. The above text applies only to the LDP ECMP case. > --- > > 5. Initialization and Demultiplexing > > > A BFD session may be established for a FEC associated with a MPLS > LSP. As desribed above in the case of PHP and next-hop label > allocation the BFD control packet received by the egress LSR does not > contain sufficient information to associate it with a BFD session. > Hence the demultiplexing MUST be done using the remote discriminator > field in the received BFD control packet. The exchange of BFD > discriminators for this purpose is described in the next section. > > 6. Session Establishment > > To establish a BFD session a LSP-Ping echo > request message MUST carry the local discriminator assigned by the > ingress LSR for the BFD session. This MUST subsequently be used as > the My Discriminator field in the BFD session packets sent by the > ingress LSR. > > There seem to be other additional cases besides PHP where discriminators > need to be exchanged/boot-strapped (e.g., UHP and single label), UHP is a valid case and I will mention it. > but > situations where it's not needed (e.g., PWs). Should these cases be > enumerated/framed or clarified? Is this "MUST" (the first one in Section > 6) too strong considering cases where bootstrapping with LSP-Ping is not > needed (e.g., PWs) or should the MUST be conditioned to the cases where > is needed? > For consistant operation of the BFD MPLS state machine the procedures in this document require LSP-Ping bootstrapping to all types of LSPs. Hence the text should stay as is. > --- > > 6. Session Establishment > > On receipt of the LSP-Ping echo request message, the egress LSR MUST > send a BFD control packet to the ingress LSR. > ... > 7. Encapsulation > > BFD control packets sent by the egress LSR are UDP packets. The > source IP address is a routable address of the replier; the source > port is the well-known UDP port 3784. The destination IP address and > UDP port MUST be copied from the source IP address and UDP port of > the control packet received from the ingress LSR. > > LSP-Ping (ingress->egress) is used to exchange the ingress My > Discriminator. And then a BFD Control packet (egress->ingress) is used > to exchange the egress My Discriminator. Section 6 says that the egress > replies with a BFD Control packet (before it has received a BFD Control > packet from ingress), and Section 7 says that the egress copies the dest > UDP port from the source's ingress. > Therefore it seems that the > destination UDP Port of the first BFD Control packet (from egress to > ingress) is unspecified, and could be anything in the [49152 .. 65535] > range since: > > The BFD control packet sent by the ingress LSR MUST be a UDP packet > with a well known destination port 3784 [BFD-IP] and a source port > assigned by the sender as per the procedures in [BFD-IP]. > > Should the egress use also 3784 as destination port in the first BFD > Control packet? Thanks for catching this bug. The egress should either use 3784 as the dest port if the return packet is being tunnelled. It should use 4784 otherwise. I will clarify this. > Should the port be also included in the LSP-Ping > message? Or should the UDP port be allowed to change in the first packet > from the ingress->egress? > If the egress uses 3784 as dest UDP port, these two requirements from > [BFD-IP] seem to end up contradicting on this case: > > The same UDP > source port number MUST be used for all BFD Control packets > associated with a particular session. The source port number SHOULD > be unique among all BFD sessions on the system. > ... > but the number of distinct uses of > the same UDP source port number SHOULD be minimize > > So that would seem to leave the other two options (send the UDP Port in > the LSP-Ping, or allow for the UDP Port to change during the handshake. > Specifying the dest port as 3784 or 4784 for the egress to ingress BFD packets addresses this. > --- > > 7. Encapsulation > > For MPLS PWs, alternatively, > the presence of a fault detection message may be indicated by setting > a bit in the control word [VCCV]. > > This procedure needs signaling or static configuration to create the > VCCV control channel before BFD packets could be exchanged over the > control channel (with the bit in the CW). Are more details needed? I will specify that the two ends in this case are assumed to be configured to use this control channel. And signaling this capability is outside the scope of this document. > See > below as well. > > --- > > 7. Encapsulation > > In this case the destination IP address, used in a > BFD session established for one such alternate path, is the address > in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to > exercise that particular alternate path. > > A nit, where it says "is the address", there may be (and typically will > be) multiple addresses from 127/8 to exercise a particular ECMP. Should > that say "is one address from the 127/8 ... that exercises..."? > No. It is a particular address discovered for that path. The current text is correct. > Also, there is no mention of BFD Echo adjunct function to the > asynchronous mode. > I will specify that the echo function is out of scope. > --- > > 11.2. Informative References > > [VCCV] T. Nadeau, C. Pignataro, R. Aggarwal, > "Pseudo Wire (PW) Virtual Circuit Connection Verification > ((VCCV)", draft-ietf-pwe3-vccv-13.txt > > This reference points to rev 13 of this document. In the subsequent > revision, this document was split into what resulted in RFC 5085 and the > ID draft-ietf-pwe3-vccv-bfd. It seems that some citations refer to the > former, while others to the latter, and they appear to be made in a > Normative fashion (e.g., because the VCCV control channel needs to exist > in order to send BFD packets over it). > However, given that PWs need an associated VCCV control channel, do not > need LSP-Ping boot-strapping (as can get the context from the PW label), > should this document point to draft-ietf-pwe3-vccv-bfd (that goes into > different BFD functional modes) for the PW case instead of also defining > it here, since it has a number of specific unique issues? > This document simply needs to point to RFC 5085 for the control word based control channel. "The use of BFD for PWs is further described in [VCCV] and [OAM-MAP]." It should point to draft-ietf-pwe3-vccv-bfd in the above statement in section 3.1 rahul > Thanks, > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems > > > >
- WGLC comments on bfd-mpls-05 Carlos Pignataro
- [BFD] bfd-mpls-05 Damodharan SP - TLS , Chennai
- Re: [BFD] bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Nadeau Thomas
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal