From rtg-bfd-bounces@ietf.org Mon May 5 13:11:06 2008 Return-Path: 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 BA1623A6D07; Mon, 5 May 2008 13:11:06 -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 81FD33A6D07 for ; Mon, 5 May 2008 13:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 YHZSrlVePUrl for ; Mon, 5 May 2008 13:11:03 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id A2D833A68DE for ; Mon, 5 May 2008 13:11:03 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m45KB0T23965; Mon, 5 May 2008 16:11:00 -0400 (EDT) Received: from [64.102.157.132] (dhcp-64-102-157-132.cisco.com [64.102.157.132]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m45KBgu18409; Mon, 5 May 2008 16:11:50 -0400 (EDT) Message-ID: <481F69CA.1020406@cisco.com> Date: Mon, 05 May 2008 16:10:50 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: WGLC comments on bfd-mpls-05 References: <20080430203803.K89520@sapphire.juniper.net> In-Reply-To: <20080430203803.K89520@sapphire.juniper.net> X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Rahul, Thank you for your answers, please find some follow-ups below. On 4/30/2008 11:41 PM, Rahul Aggarwal said the following: > 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. Thanks, please see below as well. > >> --- >> >> 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." > > OK, Thanks, that's clear (sorry I missed it when reading the previous part). And implicit-ack on the responses I skip over. > >> 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. 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? > >> --- >> >> 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). > >> --- >> >> 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]. > > >> 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]. 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? 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. > >> 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. But multiple addresses can be discovered for that path in the Multipath Information field, "a particular address" is not "the address". Just a nit though. > >> 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. Yes, for the control channel, but it would still lack the connectivity verification (CV) types. > > "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). 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), and the other limitation is regarding alternate encapsulations for BFD (PW-ACH mode, and functional modes specified as different CV Types as well). Thanks again, --Carlos. > > rahul > > >> Thanks, >> >> -- >> --Carlos Pignataro. >> Escalation RTP - cisco Systems >> >> >> >> > -- --Carlos Pignataro. Escalation RTP - cisco Systems From rtg-bfd-bounces@ietf.org Mon May 5 16:54:37 2008 Return-Path: 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 ; 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 ; 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 ; 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, 5 May 2008 16:54:28 -0700 (PDT) From: Rahul Aggarwal To: Carlos Pignataro 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 , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Carlos, > >> 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 > From rtg-bfd-bounces@ietf.org Tue May 6 11:51:11 2008 Return-Path: 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 42CDB3A6C10; Tue, 6 May 2008 11:51:11 -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 69B573A6890 for ; Tue, 6 May 2008 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 JqEGV8htom37 for ; Tue, 6 May 2008 11:51:04 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 312273A6C10 for ; Tue, 6 May 2008 11:51:04 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m46Ip1202869; Tue, 6 May 2008 14:51:01 -0400 (EDT) Received: from [64.102.157.132] (dhcp-64-102-157-132.cisco.com [64.102.157.132]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m46Ipru06526; Tue, 6 May 2008 14:51:53 -0400 (EDT) Message-ID: <4820A894.2040608@cisco.com> Date: Tue, 06 May 2008 14:51:00 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: WGLC comments on bfd-mpls-05 References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> In-Reply-To: <20080505154957.M81069@sapphire.juniper.net> X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Rahul, Thanks, please see inline. On 5/5/2008 7:54 PM, Rahul Aggarwal said the following: > Hi Carlos, > > > >>>> 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." Yes, but Section 3.1 says the following: In addition LSP-Ping also provides a mechanism for verifying the MPLS control plane against the data plane. [...] BFD cannot be used for verifying the MPLS control plane against the data plane. However BFD can be used to detect a data plane failure in the forwarding path of a MPLS LSP. [...] LSP-Ping includes extensive control plane verification. BFD on the other hand was designed as a light-weight means of testing only the data plane. As a result, LSP-Ping is computationally more expensive than BFD for detecting MPLS LSP data plane faults. BFD is also more suitable for being implemented in hardware or firmware due to its fixed packet format. Thus the use of BFD for detecting MPLS LSP data plane faults has the following advantages: [...] There may be other potential cases where fast failure detection is desired for MPLS LSPs. The control-plane verification is inherent to LSP-Ping, and orthogonal to running BFD over the PW. It's not an inherent dependency (running LSP-Ping independent of BFD seems to achieve the same). > > >>>> --- >>>> >>>> 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]." > Thanks. That clarifies. Regarding IP addresses, that para would continue with something like this, right? The source IP address is a routable address of the replier. The destination IP address MUST be copied from the source IP address of the LSP-Ping echo request message received from the ingress LSR. Also, I just noticed that the regarding the TTL, the text says (does it apply to both directions since it's in a separate para?): The IP TTL MUST be set to 1. Is this done intentionally to ensure intercepting the packet to the control plane in the ingress -> egress direction (even with the destination in 127/8)? If so, could the Security Considerations mention that the GTSM is not in effect in that direction, and with a routed multi-hop reply? Or should it be set to 255 and GTSM-checked on receipt? And in the egress -> ingress direction, should the TTL be set to 255 (and checked for GTSM if the dest port if 3784, but not if the dest port is 4784)? >>> >>>> 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. Please see below. > >>>> 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. If this specification makes use of the control channel from RFC5085 for PW LSPs, only fault detection message payload types that are signaled and agreed as CV types can run over the control channel, from RFC5085. > >> 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." > Yes. Agreed. Along these lines, the Session Establishment procedures in Section 6 say: On receipt of the LSP-Ping echo request message, the egress LSR MUST send a BFD control packet to the ingress LSR. This BFD control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP-Ping echo request message. I think this should additionally require successful FEC Validation ("Validate FEC Stack" flag in the MPLS echo request) before sending a BFD control packet back, or at least a successful (return-code 3) label operation check on receipt of the MPLS Echo request. > >> 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. LSP-Ping over PW-ACH is defined in RFC5085, so the LSP-Ping CV Type is relevant for the PW case, or it could not bootstrap the session. From RFC5085, for other connectivity-verification/payload types (like BFD) over the PW-ACH, a CV Type is needed. The procedures in this draft strictly seem to update these rules, with an implicit CV Type "negotiation"/agreement by means of sending (at the ingress LSR) and parsing/understanding (at the egress LSR) the BFD Discriminator TLV in the MPLS Echo request. There is the bootstrapping (and LSP-Ping as a CV Type over the PW-ACH should have been negotiated before this can happen for the PW case from RFC5085) as a "negotiation", so there wouldn't be unexpected CV Types/payloads received (if the BFD TLV is not supported it would result in "TLV not understood" since it's 15). But I think this would need to be spelled out. Thanks, --Carlos. > > rahul > >> Thanks again, >> >> --Carlos. >> >>> rahul >>> >>> >>>> Thanks, >>>> >>>> -- >>>> --Carlos Pignataro. >>>> Escalation RTP - cisco Systems >>>> >>>> >>>> >>>> >> -- >> --Carlos Pignataro. >> Escalation RTP - cisco Systems >> > -- --Carlos Pignataro. Escalation RTP - cisco Systems From rtg-bfd-bounces@ietf.org Tue May 6 17:43:36 2008 Return-Path: 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 400FD3A6DEA; Tue, 6 May 2008 17:43: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 4E3EC3A6DEA for ; Tue, 6 May 2008 17:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 41zHtDpV64Z3 for ; Tue, 6 May 2008 17:43:34 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id CF5A53A6866 for ; Tue, 6 May 2008 17:43:33 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Tue, 06 May 2008 17:43:31 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 May 2008 17:40:58 -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 m470ewx47909; Tue, 6 May 2008 17:40:58 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Tue, 6 May 2008 17:40:58 -0700 (PDT) From: Rahul Aggarwal To: Carlos Pignataro Subject: Re: WGLC comments on bfd-mpls-05 In-Reply-To: <4820A894.2040608@cisco.com> Message-ID: <20080506130108.O46817@sapphire.juniper.net> References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 May 2008 00:40:58.0619 (UTC) FILETIME=[04607CB0:01C8AFDB] Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Carlos, We are down to a couple of points. Please see below: > > > > > > >>>> --- > >>>> > >>>> 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]." > > > > Thanks. That clarifies. > > Regarding IP addresses, that para would continue with something like > this, right? > > The source IP address is a routable address of the replier. The > destination IP address MUST be copied from the source IP address of > the LSP-Ping echo request message received from the ingress LSR. > Something like that, yes. > Also, I just noticed that the regarding the TTL, the text says (does it > apply to both directions since it's in a separate para?): > > The IP TTL MUST be set to 1. > > Is this done intentionally to ensure intercepting the packet to the > control plane in the ingress -> egress direction (even with the > destination in 127/8)? Look at section 4.4 of RFC4379. I will add a reference to that. >If so, could the Security Considerations mention > that the GTSM is not in effect in that direction, > and with a routed > multi-hop reply? Or should it be set to 255 and GTSM-checked on receipt? > And in the egress -> ingress direction, should the TTL be set to 255 > (and checked for GTSM if the dest port if 3784, but not if the dest port > is 4784)? > The revised text will make it clear that for a routed reply [BFD-MHOP] applies and otherwise [BFD-IP] applies. I don't think there is any need to state the above here. > > > >>>> 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. > > If this specification makes use of the control channel from RFC5085 for > PW LSPs, only fault detection message payload types that are signaled > and agreed as CV types can run over the control channel, from RFC5085. > Please see below. > > > >> 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." > > > > Yes. Agreed. > Great. > Along these lines, the Session Establishment procedures in Section 6 say: > > On receipt of the LSP-Ping echo request message, the egress LSR MUST > send a BFD control packet to the ingress LSR. This BFD control > packet MUST set the Your Discriminator field to the discriminator > received from the ingress LSR in the LSP-Ping echo request message. > > I think this should additionally require successful FEC Validation > ("Validate FEC Stack" flag in the MPLS echo request) before sending a > BFD control packet back, or at least a successful (return-code 3) label > operation check on receipt of the MPLS Echo request. > This is normal LSP-Ping procedure. > > > >> 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. > > LSP-Ping over PW-ACH is defined in RFC5085, so the LSP-Ping CV Type is > relevant for the PW case, or it could not bootstrap the session. From > RFC5085, for other connectivity-verification/payload types (like BFD) > over the PW-ACH, a CV Type is needed. > > The procedures in this draft strictly seem to update these rules, with > an implicit CV Type "negotiation"/agreement by means of sending (at the > ingress LSR) and parsing/understanding (at the egress LSR) the BFD > Discriminator TLV in the MPLS Echo request. There is the bootstrapping > (and LSP-Ping as a CV Type over the PW-ACH should have been negotiated > before this can happen for the PW case from RFC5085) as a "negotiation", > so there wouldn't be unexpected CV Types/payloads received (if the BFD > TLV is not supported it would result in "TLV not understood" since it's > 15). But I think this would need to be spelled out. > How about inserting the following text to clarify this: "To enable fault detection procedures specified in this document, for a particular MPLS LSP, this document requires the ingress and egress LSRs to be configured. This includes configuration for supporting BFD and LSP-Ping as specified in this document. It also includes configuration that enables to the ingress LSR to determine the method used by the egress LSR to identify OAM packets e.g. whether the TTL of the innermost MPLS label needs to be set to 1 to enable the egress LSR to identify the OAM packet. This applies to fault detection for MPLS PWs as well. Extending [RFC5085] procedures to signal BFD capability between PW endpoints is outside the scope of this document." rahul > Thanks, > > --Carlos. > > > > > rahul > > > >> Thanks again, > >> > >> --Carlos. > >> > >>> rahul > >>> > >>> > >>>> Thanks, > >>>> > >>>> -- > >>>> --Carlos Pignataro. > >>>> Escalation RTP - cisco Systems > >>>> > >>>> > >>>> > >>>> > >> -- > >> --Carlos Pignataro. > >> Escalation RTP - cisco Systems > >> > > > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems > From rtg-bfd-bounces@ietf.org Wed May 7 11:55:22 2008 Return-Path: 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 D047C3A685F; Wed, 7 May 2008 11:55:22 -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 F31543A685F for ; Wed, 7 May 2008 11:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_35=1, 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 nAZrDPJK0wjJ for ; Wed, 7 May 2008 11:55:19 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 1344C3A67B1 for ; Wed, 7 May 2008 11:55:18 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m47ItCP19627; Wed, 7 May 2008 14:55:13 -0400 (EDT) Received: from [64.102.157.132] (dhcp-64-102-157-132.cisco.com [64.102.157.132]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m47Itqu24310; Wed, 7 May 2008 14:56:03 -0400 (EDT) Message-ID: <4821FB01.90209@cisco.com> Date: Wed, 07 May 2008 14:54:57 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: WGLC comments on bfd-mpls-05 References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> In-Reply-To: <20080506130108.O46817@sapphire.juniper.net> X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Rahul, On 5/6/2008 8:40 PM, Rahul Aggarwal said the following: > Hi Carlos, > > We are down to a couple of points. Please see below: Yes, thank you for your responses and revisions. Please see inline. > > > >>> >>>>>> --- >>>>>> >>>>>> 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]." >>> >> Thanks. That clarifies. >> >> Regarding IP addresses, that para would continue with something like >> this, right? >> >> The source IP address is a routable address of the replier. The >> destination IP address MUST be copied from the source IP address of >> the LSP-Ping echo request message received from the ingress LSR. >> > > Something like that, yes. > >> Also, I just noticed that the regarding the TTL, the text says (does it >> apply to both directions since it's in a separate para?): >> >> The IP TTL MUST be set to 1. >> >> Is this done intentionally to ensure intercepting the packet to the >> control plane in the ingress -> egress direction (even with the >> destination in 127/8)? > > Look at section 4.4 of RFC4379. I will add a reference to that. > OK, thanks. (I was asking because the IP TTL 1 processing exception does not apply to the e2e PW case, and there is the PW-ACH exception) > >> If so, could the Security Considerations mention >> that the GTSM is not in effect in that direction, >> and with a routed >> multi-hop reply? Or should it be set to 255 and GTSM-checked on receipt? >> And in the egress -> ingress direction, should the TTL be set to 255 >> (and checked for GTSM if the dest port if 3784, but not if the dest port >> is 4784)? >> > > The revised text will make it clear that for a routed reply > [BFD-MHOP] applies and otherwise [BFD-IP] applies. I don't think > there is any need to state the above here. Thanks. Would this apply only to encapsulation (since the text is within the Encapsulation section), or also to the GTSM procedures from [BFD-IP]? Could that be clarified as well, since it might not be directly apparent? > > > >>>>>> 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. >> If this specification makes use of the control channel from RFC5085 for >> PW LSPs, only fault detection message payload types that are signaled >> and agreed as CV types can run over the control channel, from RFC5085. >> > > Please see below. > >>>> 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." >>> >> Yes. Agreed. >> > > Great. > >> Along these lines, the Session Establishment procedures in Section 6 say: >> >> On receipt of the LSP-Ping echo request message, the egress LSR MUST >> send a BFD control packet to the ingress LSR. This BFD control >> packet MUST set the Your Discriminator field to the discriminator >> received from the ingress LSR in the LSP-Ping echo request message. >> >> I think this should additionally require successful FEC Validation >> ("Validate FEC Stack" flag in the MPLS echo request) before sending a >> BFD control packet back, or at least a successful (return-code 3) label >> operation check on receipt of the MPLS Echo request. >> > > This is normal LSP-Ping procedure. The normal LSP-Ping procedure generates an LSP-Ping reply with a result code that could differ from "AOK", and could for example be "Replying router has no mapping for the FEC at stack-depth " or "No label entry at stack-depth "; in these cases, in the new procedures, I think that the egress LSR should not send a BFD control packet (as there is a FEC<->Label mismatch detected, and the feature of using LSP-Ping with BFD so that "the 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" would become a NOOP). Shouldn't the BFD session be bootstrapped only after a successful control-plane checking (and ideally including FEC Validation)? > >>>> 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. >> LSP-Ping over PW-ACH is defined in RFC5085, so the LSP-Ping CV Type is >> relevant for the PW case, or it could not bootstrap the session. From >> RFC5085, for other connectivity-verification/payload types (like BFD) >> over the PW-ACH, a CV Type is needed. >> >> The procedures in this draft strictly seem to update these rules, with >> an implicit CV Type "negotiation"/agreement by means of sending (at the >> ingress LSR) and parsing/understanding (at the egress LSR) the BFD >> Discriminator TLV in the MPLS Echo request. There is the bootstrapping >> (and LSP-Ping as a CV Type over the PW-ACH should have been negotiated >> before this can happen for the PW case from RFC5085) as a "negotiation", >> so there wouldn't be unexpected CV Types/payloads received (if the BFD >> TLV is not supported it would result in "TLV not understood" since it's >> 15). But I think this would need to be spelled out. >> > > How about inserting the following text to clarify this: I think this clarifies, with two small comments inline, thanks: > > "To enable fault detection procedures specified in this document, for a > particular MPLS LSP, this document requires the ingress and > egress LSRs to be configured. This includes configuration for supporting > BFD and LSP-Ping as specified in this document. It also includes > configuration that enables to the ingress LSR to determine the ^ or signaling > method used by the egress LSR to identify OAM packets e.g. whether the TTL > of the innermost MPLS label needs to be set to 1 to enable the egress LSR > to identify the OAM packet. This applies to fault detection for MPLS PWs > as well. "For fault detection for MPLS PWs, this document also assume that a PW control channel (e.g., a PW-ACH) and support for LSP-Ping are provided prior to initializing the procedures specified in this document, as specified in [RFC5085]. " or something along those lines. > Extending [RFC5085] procedures to signal BFD capability > between PW endpoints is outside the scope of this document." > Should this pointer to [RFC5085] be normative, and the one to pwe3-vccv-bfd in "The use of BFD for PWs is further described in [VCCV] and [OAM-MAP]." be informative? Thanks, --Carlos. > rahul > >> Thanks, >> >> --Carlos. >> >>> rahul >>> >>>> Thanks again, >>>> >>>> --Carlos. >>>> >>>>> rahul >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> -- >>>>>> --Carlos Pignataro. >>>>>> Escalation RTP - cisco Systems >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>>> --Carlos Pignataro. >>>> Escalation RTP - cisco Systems >>>> >> -- >> --Carlos Pignataro. >> Escalation RTP - cisco Systems >> > -- --Carlos Pignataro. Escalation RTP - cisco Systems From rtg-bfd-bounces@ietf.org Wed May 7 13:01:03 2008 Return-Path: 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 F3F3F3A6E64; Wed, 7 May 2008 13:01:02 -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 144D43A6C2B for ; Wed, 7 May 2008 13:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_BACKHAIR_35=1, 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 2cO-vRE3u9mg for ; Wed, 7 May 2008 13:01:00 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id 7D3383A67F5 for ; Wed, 7 May 2008 13:00:59 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 13:00:55 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 13:00:07 -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 m47K05x96201; Wed, 7 May 2008 13:00:05 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Wed, 7 May 2008 13:00:05 -0700 (PDT) From: Rahul Aggarwal To: Carlos Pignataro Subject: Re: WGLC comments on bfd-mpls-05 In-Reply-To: <4821FB01.90209@cisco.com> Message-ID: <20080507121818.R82170@sapphire.juniper.net> References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> <4821FB01.90209@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 May 2008 20:00:07.0804 (UTC) FILETIME=[F2EBEBC0:01C8B07C] Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Carlos, > > > >> If so, could the Security Considerations mention > >> that the GTSM is not in effect in that direction, > >> and with a routed > >> multi-hop reply? Or should it be set to 255 and GTSM-checked on receipt? > >> And in the egress -> ingress direction, should the TTL be set to 255 > >> (and checked for GTSM if the dest port if 3784, but not if the dest port > >> is 4784)? > >> > > > > The revised text will make it clear that for a routed reply > > [BFD-MHOP] applies and otherwise [BFD-IP] applies. I don't think > > there is any need to state the above here. > > Thanks. Would this apply only to encapsulation (since the text is within > the Encapsulation section), or also to the GTSM procedures from > [BFD-IP]? Could that be clarified as well, since it might not be > directly apparent? > I will clarify this. > >> > >> On receipt of the LSP-Ping echo request message, the egress LSR MUST > >> send a BFD control packet to the ingress LSR. This BFD control > >> packet MUST set the Your Discriminator field to the discriminator > >> received from the ingress LSR in the LSP-Ping echo request message. > >> > >> I think this should additionally require successful FEC Validation > >> ("Validate FEC Stack" flag in the MPLS echo request) before sending a > >> BFD control packet back, or at least a successful (return-code 3) label > >> operation check on receipt of the MPLS Echo request. > >> > > > > This is normal LSP-Ping procedure. > > The normal LSP-Ping procedure generates an LSP-Ping reply with a result > code that could differ from "AOK", and could for example be "Replying > router has no mapping for the FEC at stack-depth " or "No label > entry at stack-depth "; in these cases, in the new procedures, I > think that the egress LSR should not send a BFD control packet (as there > is a FEC<->Label mismatch detected, and the feature of using LSP-Ping > with BFD so that "the 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" would become a NOOP). Shouldn't the BFD session be > bootstrapped only after a successful control-plane checking (and ideally > including FEC Validation)? > I see there is value in clarifying this. Will do. > > > > How about inserting the following text to clarify this: > > I think this clarifies, with two small comments inline, thanks: > > > > > "To enable fault detection procedures specified in this document, for a > > particular MPLS LSP, this document requires the ingress and > > egress LSRs to be configured. This includes configuration for supporting > > BFD and LSP-Ping as specified in this document. It also includes > > configuration that enables to the ingress LSR to determine the > ^ > or signaling > The whole point is that this document does not specify any signaling to discover the ingress/egress capabilities. It relies on configuration. > > method used by the egress LSR to identify OAM packets e.g. whether the TTL > > of the innermost MPLS label needs to be set to 1 to enable the egress LSR > > to identify the OAM packet. This applies to fault detection for MPLS PWs > > as well. > > "For fault detection for MPLS PWs, this document also assume that a PW > control channel (e.g., a PW-ACH) and support for LSP-Ping are provided > prior to initializing the procedures specified in this document, as > specified in [RFC5085]. " > > or something along those lines. > I don't think that makes sense as this document relies on configuration. Further there is no point in signaling LSP-Ping capability if BFD capability cannot be signaled. I fail to see why it is not enough to spell out that this document requires configuration. It doesn't preclude capability signaling to be added by another document. > > Extending [RFC5085] procedures to signal BFD capability > > between PW endpoints is outside the scope of this document." > > > > Should this pointer to [RFC5085] be normative, and the one to > pwe3-vccv-bfd in "The use of BFD for PWs is further described in [VCCV] > and [OAM-MAP]." be informative? > Both should be informative pointers. rahul From rtg-bfd-bounces@ietf.org Wed May 7 14:02:50 2008 Return-Path: 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 1750C3A6B0B; Wed, 7 May 2008 14:02:50 -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 98D9E28C6B2 for ; Wed, 7 May 2008 14:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_35=1] 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 G1K4NAj19yZh for ; Wed, 7 May 2008 14:02:46 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 541693A714E for ; Wed, 7 May 2008 14:02:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id AC06E35B687; Wed, 7 May 2008 17:03:38 -0400 (EDT) Received: from lucidvision.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22833-08; Wed, 7 May 2008 17:03:05 -0400 (EDT) Received: from Novi-Jablko.lucidvision.dyndns.org (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 2390E35B666; Wed, 7 May 2008 17:03:05 -0400 (EDT) Message-Id: From: Nadeau Thomas To: Rahul Aggarwal In-Reply-To: <20080507121818.R82170@sapphire.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: WGLC comments on bfd-mpls-05 Date: Wed, 7 May 2008 17:02:07 -0400 References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> <4821FB01.90209@cisco.com> <20080507121818.R82170@sapphire.juniper.net> X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: by amavisd-new at lucidvision.com Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On May 7, 2008:4:00 PM, at 4:00 PM, Rahul Aggarwal wrote: > > Hi Carlos, > > > >>> >>>> If so, could the Security Considerations mention >>>> that the GTSM is not in effect in that direction, >>>> and with a routed >>>> multi-hop reply? Or should it be set to 255 and GTSM-checked on >>>> receipt? >>>> And in the egress -> ingress direction, should the TTL be set to >>>> 255 >>>> (and checked for GTSM if the dest port if 3784, but not if the >>>> dest port >>>> is 4784)? >>>> >>> >>> The revised text will make it clear that for a routed reply >>> [BFD-MHOP] applies and otherwise [BFD-IP] applies. I don't think >>> there is any need to state the above here. >> >> Thanks. Would this apply only to encapsulation (since the text is >> within >> the Encapsulation section), or also to the GTSM procedures from >> [BFD-IP]? Could that be clarified as well, since it might not be >> directly apparent? >> > > I will clarify this. > > > >>>> >>>> On receipt of the LSP-Ping echo request message, the egress >>>> LSR MUST >>>> send a BFD control packet to the ingress LSR. This BFD control >>>> packet MUST set the Your Discriminator field to the >>>> discriminator >>>> received from the ingress LSR in the LSP-Ping echo request >>>> message. >>>> >>>> I think this should additionally require successful FEC Validation >>>> ("Validate FEC Stack" flag in the MPLS echo request) before >>>> sending a >>>> BFD control packet back, or at least a successful (return-code 3) >>>> label >>>> operation check on receipt of the MPLS Echo request. >>>> >>> >>> This is normal LSP-Ping procedure. >> >> The normal LSP-Ping procedure generates an LSP-Ping reply with a >> result >> code that could differ from "AOK", and could for example be "Replying >> router has no mapping for the FEC at stack-depth " or "No label >> entry at stack-depth "; in these cases, in the new procedures, I >> think that the egress LSR should not send a BFD control packet (as >> there >> is a FEC<->Label mismatch detected, and the feature of using LSP-Ping >> with BFD so that "the 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" would become a NOOP). Shouldn't the BFD session be >> bootstrapped only after a successful control-plane checking (and >> ideally >> including FEC Validation)? >> > > I see there is value in clarifying this. Will do. > > > >>> >>> How about inserting the following text to clarify this: >> >> I think this clarifies, with two small comments inline, thanks: >> >>> >>> "To enable fault detection procedures specified in this document, >>> for a >>> particular MPLS LSP, this document requires the ingress and >>> egress LSRs to be configured. This includes configuration for >>> supporting >>> BFD and LSP-Ping as specified in this document. It also includes >>> configuration that enables to the ingress LSR to determine the >> ^ >> or signaling >> > > The whole point is that this document does not specify any signaling > to > discover the ingress/egress capabilities. It relies on configuration. > >>> method used by the egress LSR to identify OAM packets e.g. whether >>> the TTL >>> of the innermost MPLS label needs to be set to 1 to enable the >>> egress LSR >>> to identify the OAM packet. This applies to fault detection for >>> MPLS PWs >>> as well. >> >> "For fault detection for MPLS PWs, this document also assume that a >> PW >> control channel (e.g., a PW-ACH) and support for LSP-Ping are >> provided >> prior to initializing the procedures specified in this document, as >> specified in [RFC5085]. " >> >> or something along those lines. >> > > I don't think that makes sense as this document relies on > configuration. > Further there is no point in signaling LSP-Ping capability if BFD > capability cannot be signaled. > > I fail to see why it is not enough to spell out that this document > requires configuration. It doesn't preclude capability signaling to be > added by another document. I agree for the static case things are explicitly configured. However, I think the confusion here lies in the fact that we could configure the capability, and then advertise the BFD/VCCV capability, right? But those are explicitly detailed in the vccv-bfd document (draft-ietf-pwe3-vccv-bfd-01). It might be most appropriate to simply remove the forward reference to the vccv-bfd stuff from here, and only refer to this document from there. --Tom >>> Extending [RFC5085] procedures to signal BFD capability >>> between PW endpoints is outside the scope of this document." >>> >> >> Should this pointer to [RFC5085] be normative, and the one to >> pwe3-vccv-bfd in "The use of BFD for PWs is further described in >> [VCCV] >> and [OAM-MAP]." be informative? >> > > Both should be informative pointers. > > rahul > > From rtg-bfd-bounces@ietf.org Wed May 7 16:49:54 2008 Return-Path: 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 DCCD728C3C5; Wed, 7 May 2008 16:49:54 -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 355403A6D4E for ; Wed, 7 May 2008 16:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 8juzGQxEa4Tx for ; Wed, 7 May 2008 16:49:51 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 5F1463A6AE6 for ; Wed, 7 May 2008 16:49:51 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Wed, 07 May 2008 16:49:42 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 May 2008 16:49: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 m47NnNx74081; Wed, 7 May 2008 16:49:23 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Wed, 7 May 2008 16:49:23 -0700 (PDT) From: Rahul Aggarwal To: Nadeau Thomas Subject: Re: WGLC comments on bfd-mpls-05 In-Reply-To: Message-ID: <20080507163742.U82170@sapphire.juniper.net> References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> <4821FB01.90209@cisco.com> <20080507121818.R82170@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 May 2008 23:49:23.0663 (UTC) FILETIME=[FA0D6DF0:01C8B09C] Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tom, Please see below: > I don't think that makes sense as this document relies on > > configuration. > > Further there is no point in signaling LSP-Ping capability if BFD > > capability cannot be signaled. > > > > I fail to see why it is not enough to spell out that this document > > requires configuration. It doesn't preclude capability signaling to be > > added by another document. > I agree for the static case things are explicitly configured. We are in sync. This is the key point. tom> > However, I think the confusion here lies in the fact that we could > configure the capability, and then advertise the BFD/VCCV capability, > right? This spec requires configuration and should just say that signaling of capabilities is out of scope. tom> > But those are explicitly detailed in the vccv-bfd document > (draft-ietf-pwe3-vccv-bfd-01). It might be most appropriate to simply > remove the forward reference to the vccv-bfd stuff from here, and only > refer to this document from there. > How about removing the forward reference to draft-ietf-pwe3-vccv-bfd-01. But leaving the reference to RFC5085 to say that there could be other ways to identify OAM packets other than ttl=1, for PWs ? And let that be an informative reference ? rahul From rtg-bfd-bounces@ietf.org Thu May 8 11:52:24 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9F63A6C44; Thu, 8 May 2008 11:52:24 -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 317A03A6B1B for ; Thu, 8 May 2008 11:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.467, 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 0bgvBw73E0pi for ; Thu, 8 May 2008 11:52:19 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id DE4D93A6B69 for ; Thu, 8 May 2008 11:51:01 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m48IovA05786; Thu, 8 May 2008 14:50:57 -0400 (EDT) Received: from [64.102.157.132] (dhcp-64-102-157-132.cisco.com [64.102.157.132]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m48Ipeu26593; Thu, 8 May 2008 14:51:40 -0400 (EDT) Message-ID: <48234B87.9020805@cisco.com> Date: Thu, 08 May 2008 14:50:47 -0400 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Rahul Aggarwal Subject: Re: WGLC comments on bfd-mpls-05 References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> <4821FB01.90209@cisco.com> <20080507121818.R82170@sapphire.juniper.net> <20080507163742.U82170@sapphire.juniper.net> In-Reply-To: <20080507163742.U82170@sapphire.juniper.net> X-Enigmail-Version: 0.95.6 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Rahul, Tom, Please find some comments inline on the last point (down to one). On 5/7/2008 7:49 PM, Rahul Aggarwal said the following: > Hi Tom, > > Please see below: > > > > >> I don't think that makes sense as this document relies on >>> configuration. That's fine, but my point is that instead of configuration, this document (for the PW case) relies on the existence of a control channel and capability/ability/agreement to run LSP-Ping, which in turn can be preformed by configuration (or other means equally). >>> Further there is no point in signaling LSP-Ping capability if BFD >>> capability cannot be signaled. >>> >>> I fail to see why it is not enough to spell out that this document >>> requires configuration. It doesn't preclude capability signaling to be >>> added by another document. > > I agree for the static case things are explicitly configured. Please note that I'm not referring to signaling the BFD procedures on this document. But these BFD procedures, for PWs, start with a control channel and LSP-Ping (signaled or configured), both defined in RFC5085. > > We are in sync. This is the key point. > > tom> >> However, I think the confusion here lies in the fact that we could >> configure the capability, and then advertise the BFD/VCCV capability, >> right? > > This spec requires configuration and should just say that signaling of > capabilities is out of scope. Note that RFC5085 says: Routers that implement VCCV create a Control Channel (CC) associated with a pseudowire. This control channel can be signaled (e.g., using LDP or L2TPv3 depending on the PWE3) or statically configured. Over this control channel, VCCV Connectivity Verification (CV) messages are sent. I mean (and I may not have been clear), not to signal capabilities for the procedures in this spec, but the configuration or signaling pre-requisite (and hence Normative for PWs) to start those procedures in this document (with LSP-Ping over the PW control channel). For the PW case specifically, a control channel needs to exist prior to OAM messages. This dependency can be realized by configuration or signaling. For example, the text says as an example use TTL=1 or: For MPLS PWs, alternatively, the presence of a fault detection message may be indicated by setting a bit in the control word [VCCV]. But to use this method, it needs to be signaled or configured as per RFC5085, otherwise OAMs could potentially be not intercepted and forwarded to the CE. The TTL=1 listed is another control channel type from RFC5085. > > tom> >> But those are explicitly detailed in the vccv-bfd document >> (draft-ietf-pwe3-vccv-bfd-01). It might be most appropriate to simply >> remove the forward reference to the vccv-bfd stuff from here, and only >> refer to this document from there. >> > > How about removing the forward reference to draft-ietf-pwe3-vccv-bfd-01. > But leaving the reference to RFC5085 to say that there could be > other ways to identify OAM packets other than ttl=1, for PWs ? Note that TTL=1 for PWs is one of the RFC5085 control channels, so it seem that RFC5085 is needed to bootstrap: Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 But regarding this forward pointer, my preference would be to leave it in (for completeness and cross-reference) in the same context as the existing text: "Use of BFD for PWs is further described in [VCCV-BFD] and [OAM-MAP].". Thanks, --Carlos. > And let > that be an informative reference ? > > rahul > -- --Carlos Pignataro. Escalation RTP - cisco Systems From rtg-bfd-bounces@ietf.org Thu May 8 16:13:34 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5FA028C47D; Thu, 8 May 2008 16:13:34 -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 5404028C482 for ; Thu, 8 May 2008 16:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 lbyi4VvlVDAp for ; Thu, 8 May 2008 16:13:31 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 93E0628C516 for ; Thu, 8 May 2008 16:13:30 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Thu, 08 May 2008 16:13:28 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 16:13:18 -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 m48NDHx86652; Thu, 8 May 2008 16:13:17 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Thu, 8 May 2008 16:13:17 -0700 (PDT) From: Rahul Aggarwal To: Carlos Pignataro Subject: Re: WGLC comments on bfd-mpls-05 In-Reply-To: <48234B87.9020805@cisco.com> Message-ID: <20080508160658.L13067@sapphire.juniper.net> References: <20080430203803.K89520@sapphire.juniper.net> <481F69CA.1020406@cisco.com> <20080505154957.M81069@sapphire.juniper.net> <4820A894.2040608@cisco.com> <20080506130108.O46817@sapphire.juniper.net> <4821FB01.90209@cisco.com> <20080507121818.R82170@sapphire.juniper.net> <20080507163742.U82170@sapphire.juniper.net> <48234B87.9020805@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 08 May 2008 23:13:18.0031 (UTC) FILETIME=[19A5F5F0:01C8B161] Cc: Ross Callon , 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" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Carlos, On Thu, 8 May 2008, Carlos Pignataro wrote: > Hi Rahul, Tom, > > Please find some comments inline on the last point (down to one). > > On 5/7/2008 7:49 PM, Rahul Aggarwal said the following: > > Hi Tom, > > > > Please see below: > > > > > > > > > >> I don't think that makes sense as this document relies on > >>> configuration. > > That's fine, but my point is that instead of configuration, this > document (for the PW case) relies on the existence of a control channel > and capability/ability/agreement to run LSP-Ping, which in turn can be > preformed by configuration (or other means equally). > And those other means are out of scope. Seems like we are in agrement and are saying the same thing. Let us not spin in wordsmithing. > > tom> > >> However, I think the confusion here lies in the fact that we could > >> configure the capability, and then advertise the BFD/VCCV capability, > >> right? > > > > This spec requires configuration and should just say that signaling of > > capabilities is out of scope. > > Note that RFC5085 says: > > Routers that implement VCCV create a Control Channel (CC) associated > with a pseudowire. This control channel can be signaled (e.g., using > LDP or L2TPv3 depending on the PWE3) or statically configured. Over > this control channel, VCCV Connectivity Verification (CV) messages > are sent. > > I mean (and I may not have been clear), not to signal capabilities for > the procedures in this spec, but the configuration or signaling > pre-requisite (and hence Normative for PWs) to start those procedures in > this document (with LSP-Ping over the PW control channel). > > For the PW case specifically, a control channel needs to exist prior to > OAM messages. This dependency can be realized by configuration or > signaling. For example, the text says as an example use TTL=1 or: > And this spec requires configuration. That is it. > For MPLS PWs, alternatively, > the presence of a fault detection message may be indicated by setting > a bit in the control word [VCCV]. > > But to use this method, it needs to be signaled or configured as per > RFC5085, otherwise OAMs could potentially be not intercepted and > forwarded to the CE. The TTL=1 listed is another control channel type > from RFC5085. > And the revised text that I had sent makes it clear that this needs to be configured. > > > > tom> > >> But those are explicitly detailed in the vccv-bfd document > >> (draft-ietf-pwe3-vccv-bfd-01). It might be most appropriate to simply > >> remove the forward reference to the vccv-bfd stuff from here, and only > >> refer to this document from there. > >> > > > > How about removing the forward reference to draft-ietf-pwe3-vccv-bfd-01. > > But leaving the reference to RFC5085 to say that there could be > > other ways to identify OAM packets other than ttl=1, for PWs ? > > Note that TTL=1 for PWs is one of the RFC5085 control channels, so it > seem that RFC5085 is needed to bootstrap: > > Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 > See above note on configuration. > But regarding this forward pointer, my preference would be to leave it > in (for completeness and cross-reference) in the same context as the > existing text: > > "Use of BFD for PWs is further described in [VCCV-BFD] and > [OAM-MAP].". > Based on Tom's comment, I am inclined to keep only RFC5085 as an informative reference, unless I hear more opinions on this. I will produce a revised ID. Thanks for the comments. rahul > Thanks, > > --Carlos. > > > > And let > > that be an informative reference ? > > > > rahul > > > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems > From rtg-bfd-bounces@ietf.org Fri May 30 06:20:58 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CB228C1C4; Fri, 30 May 2008 06:20: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 A216E3A68BF; Fri, 30 May 2008 06:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Y-hZkexsIR71; Fri, 30 May 2008 06:20:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5DAE23A69B5; Fri, 30 May 2008 06:20:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,566,1204531200"; d="scan'208";a="106064305" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 May 2008 06:20:51 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4UDKpTm024716; Fri, 30 May 2008 06:20:51 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4UDKo5L000977; Fri, 30 May 2008 13:20:51 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 09:20:50 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 09:20:50 -0400 In-Reply-To: <48347D72.5020700@isode.com> References: <48347D72.5020700@isode.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93C7DA82-535B-4B42-9B40-024E6388F131@cisco.com> Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: SecDir review of draft-ietf-bfd-base-08.txt Date: Fri, 30 May 2008 08:20:45 -0500 To: Alexey Melnikov X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 May 2008 13:20:50.0443 (UTC) FILETIME=[FAB8FDB0:01C8C257] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5330; t=1212153651; x=1213017651; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20SecDir=20review=20of=20draft-ietf-bfd-b ase-08.txt |Sender:=20; bh=Qy6IMQu4aNAdZgqhcbS0hR1VkaMkzDYxjtJRN2ynd/0=; b=RSAENGsyns/Fa8xUhS6AsdI4ta0kLsbK4Nm4/80OEYdSeW/ANDNrO3IsmY gsj2PUo+E67JOcwHyV3p6GLcOScho1WpuqUF+knnappyAx78Q9yNSLf9+HDL bxmN7Sw50B; Authentication-Results: sj-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "iesg@ietf.org" , rtg-bfd@ietf.org, "secdir@mit.edu" , David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Alexey - Thanks for the review. Some of the comments are relevant for us to clarify in the document but, others are not. A few inline. On May 21, 2008, at 2:52 PM, Alexey Melnikov wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document describes a protocol intended to detect faults in the > bidirectional path between two forwarding engines. Separate documents > define how this protocol can be implemented in protocols connecting > the > forwarding engines. > > In general I found the document to be well written and easy to > understand. I found the Security Considerations section to be > adequate, however I have some comments/additional suggestions. > > In section 4.1: > >> Authentication Present (A) >> >> If set, the Authentication Section is present and the session is >> to be authenticated. > > It looks like it might be very easy for an attacker to disable > authentication by clearing this field and stripping the Authentication > Section of the BFD Control packet. > I think this should be mentioned in the Security considerations > section. > (Or please let me know if this is covered elsewhere in the document.) > DW: If stripped then the session will be invalid. Security is negotiated and thus both sides must agree. >> Length >> >> Length of the BFD Control packet, in bytes. > > Does this include all fields, including version, ... and the Length > itself? > >> Auth Type >> >> The authentication type in use, if the Authentication Present >> (A) >> bit is set. >> >> 0 - Reserved >> 1 - Simple Password >> 2 - Keyed MD5 >> 3 - Meticulous Keyed MD5 >> 4 - Keyed SHA1 >> 5 - Meticulous Keyed SHA1 > > It is good that the document allows for various authentication types. > However, I don't see a point in defining Keyed MD5 and Meticulous > Keyed > MD5, considering that SHA1 variants are mandatory to implement anyway. > If there is a reason for defining MD5 variants (such as existing > implementations, or speed, etc.), I suggest the document say so. In > the absence of such reason I don't see a point in standardizing MD5 > variants in a new protocol. > DW: The point is that BFD is bootstrapped by routing protocols and often implementations have protocol independent key-chains. Given some operators asked that we allow the ability to use either the same protocol independent key-chain info and md5 and meticulous keyed md5 is available to them today; we continued to allow operators to use what is available. Therefore, the decision was purely operationally pragmatic. >> 6-255 - Reserved for future use > > In Section 4.3: > >> Auth Key/Checksum >> >> This field carries the 16 byte MD5 checksum for the packet. >> When >> the checksum is calculated, the shared MD5 key is stored in this >> field. (See section 6.7.3 for details.) > > This might be obvious, but I think it is worth noting that the shared > key is exactly 16 bytes in length. If it is not the case, then some > text > about padding the key when calculating the hash is needed. > DW: I believe it is clear it is already 16 bytes. >> 6.3. Demultiplexing and the Discriminator Fields >> >> Since multiple BFD sessions may be running between two systems, >> there >> needs to be a mechanism for demultiplexing received BFD packets to >> the proper session. >> >> Each system MUST choose an opaque discriminator value that >> identifies >> each session, and which MUST be unique among all BFD sessions on >> the >> system. The local discriminator is sent in the My Discriminator >> field in the BFD Control packet, and is echoed back in the Your > > Are there any considerations on how random (guessable) this value > should be? DW: It doesn't matter. > >> 6.7.1. Enabling and Disabling Authentication > [...] > >> One possible approach is to build an implementation such that >> authentication is configured, but not considered "in use" until the >> first packet containing a matching authentication section is >> received >> (providing the necessary synchronization.) Likewise, >> authentication >> could be configured off, but still considered "in use" until the >> receipt of the first packet without the authentication section. >> >> In order to avoid security risks, implementations using this method >> should only allow the authentication state to be changed once >> without >> some form of intervention (so that authentication cannot be >> turned on >> and off repeatedly simply based on the receipt of BFD Control >> packets >> from remote systems.) > > I am not sure I understand the last quoted paragraph, can you > elaborate > what are you trying to say? > DW: This is how to thwart the negotiation of auth and turning it on and off. Many thanks again -DWard