WGLC comments on bfd-mpls-05
Carlos Pignataro <cpignata@cisco.com> Thu, 28 February 2008 22:16 UTC
Return-Path: <rtg-bfd-bounces@ietf.org>
X-Original-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC6528C788; Thu, 28 Feb 2008 14:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.003
X-Spam-Level:
X-Spam-Status: No, score=-4.003 tagged_above=-999 required=5 tests=[AWL=2.596, 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 yLBD0ih1Seui; Thu, 28 Feb 2008 14:16:52 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9738128C3CB; Thu, 28 Feb 2008 14:16:52 -0800 (PST)
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 7430528C385 for <rtg-bfd@core3.amsl.com>; Thu, 28 Feb 2008 14:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 fRykKgHWrWz2 for <rtg-bfd@core3.amsl.com>; Thu, 28 Feb 2008 14:16:45 -0800 (PST)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 70E893A6AE1 for <rtg-bfd@ietf.org>; Thu, 28 Feb 2008 14:16:45 -0800 (PST)
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 m1SMGc607142 for <rtg-bfd@ietf.org>; Thu, 28 Feb 2008 17:16:38 -0500 (EST)
Received: from [64.102.159.125] (dhcp-64-102-159-125.cisco.com [64.102.159.125]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m1SMHGu16806; Thu, 28 Feb 2008 17:17:16 -0500 (EST)
Message-ID: <47C732C5.60608@cisco.com>
Date: Thu, 28 Feb 2008 17:16:37 -0500
From: Carlos Pignataro <cpignata@cisco.com>
Organization: cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0
MIME-Version: 1.0
To: BFD WG <rtg-bfd@ietf.org>
Subject: WGLC comments on bfd-mpls-05
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
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
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)? Are BGP Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason? 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. --- 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? 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? 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. --- 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? For other FECs, there wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned? --- 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), 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? --- 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? 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. --- 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? 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..."? Also, there is no mention of BFD Echo adjunct function to the asynchronous mode. --- 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? Thanks, -- --Carlos Pignataro. Escalation RTP - cisco Systems
- WGLC comments on bfd-mpls-05 Carlos Pignataro
- [BFD] bfd-mpls-05 Damodharan SP - TLS , Chennai
- Re: [BFD] bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Nadeau Thomas
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal
- Re: WGLC comments on bfd-mpls-05 Carlos Pignataro
- Re: WGLC comments on bfd-mpls-05 Rahul Aggarwal