Re: WGLC comments on bfd-mpls-05
Rahul Aggarwal <rahul@juniper.net> Mon, 05 May 2008 23:54 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 F1A8B3A68B5; Mon, 5 May 2008 16:54:36 -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 F3E683A68B5 for <rtg-bfd@core3.amsl.com>; Mon, 5 May 2008 16:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 CjMx8yulx+wn for <rtg-bfd@core3.amsl.com>; Mon, 5 May 2008 16:54:33 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 1FAA23A6870 for <rtg-bfd@ietf.org>; Mon, 5 May 2008 16:54:33 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Mon, 05 May 2008 16:53:29 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 May 2008 16:54:28 -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 m45NsSx35048; Mon, 5 May 2008 16:54:28 -0700 (PDT) (envelope-from rahul@juniper.net)
Date: Mon, 05 May 2008 16:54:28 -0700
From: Rahul Aggarwal <rahul@juniper.net>
To: Carlos Pignataro <cpignata@cisco.com>
Subject: Re: WGLC comments on bfd-mpls-05
In-Reply-To: <481F69CA.1020406@cisco.com>
Message-ID: <20080505154957.M81069@sapphire.juniper.net>
References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-OriginalArrivalTime: 05 May 2008 23:54:28.0392 (UTC) FILETIME=[5ADBE280:01C8AF0B]
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, <snipped> > >> 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. > > I meant for VPNv4 stacked over LDP FECs. Testing a VPNv4 FEC may result > in multipaths from the underlying LDP ECMPs. Does the SHOULD apply in > that case as well? > No. > > > >> --- > >> > >> 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. > > But this adds a dependency on LSP-Ping that is not "required". Section > 3.2 of the document lists three functions for which LSP-Ping is used, > that are not directly applicable to the PW case (a. and b. do not apply > to PW LSPs, and c. is optionally applicable, but orthogonal/not tied to > the BFD procedures). > Section 3.2 states the following that applies to PWs: "In addition to this presence of the FEC in the echo request message makes it possible to verify the control plane against the data plane at the egress LSR." > > > >> --- > >> > >> 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. > > Thanks. But in this case, if the packet is being tunneled, the BFD would > have both udp.src and udp.dst as 3784, right? And if not tunneled, the > pair 3794/4784, instead of using udp source from [49152 .. 65535]. > No. The modified text will say the following: "The BFD control packet sent by the egress LSR MUST have a well known destination port 4784, if it is routed [BFD-MHOP], or it MUST have a well known destination port 3784 [BFD-IP] if it is encapsulated in a MPLS label stack. The source port MUST be assigned by the egress lSR as per the procedures in [BFD-IP]." > > > > > >> 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. > > From ingress to egress, the spec says in Section 7: > > 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]. > This is correct. > And from egress to ingress, the spec says in Section 7: > > 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. > > If from egress -> ingress the dest port is 3784 or 4784, it could end up > with both fixed src and dst ports (in which it seems it does not address > the two requirements from [BFD-IP]). Or how would the flow be in this case? > See above for the modified text. The intention was to use the source port as in [BFD-IP]. > Should the egress instead send his own MyDisc in an LSP-Ping echo reply, > and have the ingress send the first BFD Control message? Or the ingress > communicate also its source port in the LSP-Ping echo? > > > > >> --- > >> > >> 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. > > That would address the CC Type, but not the CV Type. > This draft applies to *only* BFD for MPLS LSPs. Hence the CV type discussion is simply not relevant. > >> > >> 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. > > Yes, for the control channel, but it would still lack the connectivity > verification (CV) types. > This draft specifies procedures for *only BFD*. Hence the entire CV type discussion is simply not relevant. > > > > "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 > > I think there's one problem and two limitations with that approach. The > issue is that, for BFD to be run over the control-channel, it would need > to define the CV Type(s)/payload type(s) for BFD (as a normative > procedure). As I said this draft specifies fully standalone procedures to run BFD over a MPLS LSP including PWs. For a bidrectional LSP both ends are supposed to be configured for BFD. Signaling BFD as a CV type is certainly not required for the procedures in this draft. > The limitations are that, for the PW case there is no > requirement to use LSP-Ping to bootstrap the session (and can remove the > dependency on LSP-Ping for the PW case), For the procedures in this draft bootstrapping using LSP-Ping is a MUST. As for reasons for using LSP-Ping for PWs in conjunction with BFD see section 3.2: ""In addition to this presence of the FEC in the echo request message makes is possible to verify the control plane against the data plane at the egress LSR." > and the other limitation is > regarding alternate encapsulations for BFD (PW-ACH mode, and functional > modes specified as different CV Types as well). > The use of PW-ACH is spelled out in RFC5085. The use of other CV types is simply not relevant to this draft as it covers only BFD. rahul > Thanks again, > > --Carlos. > > > > > rahul > > > > > >> Thanks, > >> > >> -- > >> --Carlos Pignataro. > >> Escalation RTP - cisco Systems > >> > >> > >> > >> > > > > -- > --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