Re: WGLC comments on bfd-mpls-05

Rahul Aggarwal <rahul@juniper.net> Thu, 01 May 2008 03:41 UTC

Return-Path: <rtg-bfd-bounces@ietf.org>
X-Original-To: rtg-bfd-archive@megatron.ietf.org
Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F42328C1CC; Wed, 30 Apr 2008 20:41:58 -0700 (PDT)
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F9C28C1CC for <rtg-bfd@core3.amsl.com>; Wed, 30 Apr 2008 20:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.079
X-Spam-Level:
X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRdeIiX0w1+p for <rtg-bfd@core3.amsl.com>; Wed, 30 Apr 2008 20:41:56 -0700 (PDT)
Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id C38223A6A6C for <rtg-bfd@ietf.org>; Wed, 30 Apr 2008 20:41:55 -0700 (PDT)
Received: from source ([66.129.224.36]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Apr 2008 20:41:57 PDT
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 20:41:23 -0700
Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m413fNx82151; Wed, 30 Apr 2008 20:41:23 -0700 (PDT) (envelope-from rahul@juniper.net)
Date: Wed, 30 Apr 2008 20:41:23 -0700
From: Rahul Aggarwal <rahul@juniper.net>
To: cpignata@cisco.com
Subject: Re: WGLC comments on bfd-mpls-05
Message-ID: <20080430203803.K89520@sapphire.juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-OriginalArrivalTime: 01 May 2008 03:41:23.0521 (UTC) FILETIME=[3A0AF310:01C8AB3D]
Cc: Ross Callon <rcallon@juniper.net>, rtg-bfd@ietf.org, dward@cisco.com
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

Hi Carlos,

Thanks for the comments. Please see below:

>
> Please find a couple of comments regarding bfd-mpls-05. I realize this
> is way past end of WGLC, but I hope the comments are useful and can be
> given consideration.
>
>
> 3.1. BFD for MPLS LSPs: Motivation
>
>        The LSP may be  associated with any of the following FECs:
>          a) RSVP IPv4/IPv6 Session [RFC3209]
>          b) LDP IPv4/IPv6 prefix [RFC3036]
>          c) VPN IPv4/IPv6 prefix [RFC4364]
>          d) Layer 2 VPN [L2-VPN]
>          e) Layer 2 Circuit ID [RFC4447]
>
> Does item e) refer to both the PWid FEC and the Generalized PWid FEC
> (128 and 129)?
>

Yes. I will clarify this.

> Are BGP Labeled IPv4/IPv6 prefixes [RFC3107] excluded for a reason?
>

Will add BGP labeled prefixes to the list.

> Also, for the e) FECs, there is the VCCV signaling aspects to be
> considered, from RFC4447 / RFC5085 to provide the VCCV control channel
> associated with the PW before BFD could be sent. Please also see last
> comment.
>

More on this below.

> ---
>
> 3.2. Using BFD in Conjunction with LSP-Ping
>
>         a) Association of a LSP-Ping echo request message with a FEC. In
>       the case of Penultimate Hop Popping (PHP), for a single label stack
>       LSP, the only way to associate a fault detection message with a FEC
>       is by carrying the FEC in the message.
>
> Is this the case not only for PHP but also for UHP with exp-null?

Correct. Will clarify this.

> Additionally for aggregated FECs in general (e.g., in the case of
> per-VRF label vs. per-VPNv4-FEC label, etc) the same applies but OTOH
> there would need to be only one BFD session per "vrf aggregated fec"
> (since it's the same label stack for different VPNv4 FECs, and the LSP
> being tested is identical), correct? Could this be clarified in the
> document?
>

The spec is clear on this subject in section 4:

"If the LSP
   is associated with multiple FECs, a BFD session SHOULD established
   for each FEC. For instance this may happen in the case of next-hop
   label allocation. Hence the operation is conceptually similar to the
   data plane fault detection procedures of LSP-Ping."



>       LSP-Ping provides this
>       functionality. Next-hop label allocation also makes it necessary to
>       carry the FEC in the fault detection message as the label alone is
>       not sufficient to identify the LSP being verified.
> ...
>       i) LSP-Ping is used for boot-strapping the BFD session as described
>       later in this document.
>
> There seem to be cases where there is no need for boot-strapping the BFD
> session with LSP-Ping. For example, for PWs, both ends can start sending
> BFD Control messages with Your Discr value of zero in an Active role, as
> the PW Label provides the context to bootstrap the session.
>

Please see below.

> ---
>
> 4. Theory of Operation
>
>       If there are multiple alternate paths from an ingress LSR to an
>       egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to
>       determine each of these alternate paths. A BFD session SHOULD be
>       established for each alternate path that is discovered.
>
> There may also be multiple ECMPs for other FECs, like VPNv4/VPNv6
> prefixes. Does this SHOULD apply to those as well?

No. As in those cases the ingress LSR knows the multiple paths and there
is no need to use the LSP-traceroute mechanism.

> For other FECs, there
> wouldn't be ECMPs (e.g., PWs RFC 4928), should that be explicitly mentioned?
>

No. The above text applies only to the LDP ECMP case.

> ---
>
> 5. Initialization and Demultiplexing
>
>
>     A BFD session may be established for a FEC associated with a MPLS
>     LSP. As desribed above in the case of PHP and next-hop label
>     allocation the BFD control packet received by the egress LSR does not
>     contain sufficient information to associate it with a BFD session.
>     Hence the demultiplexing MUST be done using the remote discriminator
>     field in the received BFD control packet. The exchange of BFD
>     discriminators for this purpose is described in the next section.
>
> 6. Session Establishment
>
>     To establish a BFD session a LSP-Ping echo
>     request message MUST carry the local discriminator assigned by the
>     ingress LSR for the BFD session. This MUST subsequently be used as
>     the My Discriminator field in the BFD session packets sent by the
>     ingress LSR.
>
> There seem to be other additional cases besides PHP where discriminators
> need to be exchanged/boot-strapped (e.g., UHP and single label),

UHP is a valid case and I will mention it.

> but
> situations where it's not needed (e.g., PWs). Should these cases be
> enumerated/framed or clarified? Is this "MUST" (the first one in Section
> 6) too strong considering cases where bootstrapping with LSP-Ping is not
> needed (e.g., PWs) or should the MUST be conditioned to the cases where
> is needed?
>

For consistant operation of the BFD MPLS state machine the procedures in
this document require LSP-Ping bootstrapping to all types of LSPs.
Hence the text should stay as is.

> ---
>
> 6. Session Establishment
>
>     On receipt of the LSP-Ping echo request message, the egress LSR MUST
>     send a BFD control packet to the ingress LSR.
> ...
> 7. Encapsulation
>
>     BFD control packets sent by the egress LSR are UDP packets. The
>     source IP address is a routable address of the replier; the source
>     port is the well-known UDP port 3784.  The destination IP address and
>     UDP port MUST be copied from the source IP address and UDP port of
>     the control packet received from the ingress LSR.
>
> LSP-Ping (ingress->egress) is used to exchange the ingress My
> Discriminator. And then a BFD Control packet (egress->ingress) is used
> to exchange the egress My Discriminator. Section 6 says that the egress
> replies with a BFD Control packet (before it has received a BFD Control
> packet from ingress), and Section 7 says that the egress copies the dest
> UDP port from the source's ingress.
> Therefore it seems that the
> destination UDP Port of the first BFD Control packet (from egress to
> ingress) is unspecified, and could be anything in the [49152 .. 65535]
> range since:
>
>     The BFD control packet sent by the ingress LSR MUST be a UDP packet
>     with a well known destination port 3784 [BFD-IP] and a source port
>     assigned by the sender as per the procedures in [BFD-IP].
>
> Should the egress use also 3784 as destination port in the first BFD
> Control packet?

Thanks for catching this bug. The egress should either use 3784 as the
dest port if the return packet is being tunnelled. It should use 4784
otherwise. I will clarify this.


> Should the port be also included in the LSP-Ping
> message? Or should the UDP port be allowed to change in the first packet
> from the ingress->egress?
> If the egress uses 3784 as dest UDP port, these two requirements from
> [BFD-IP] seem to end up contradicting on this case:
>
>     The same UDP
>     source port number MUST be used for all BFD Control packets
>     associated with a particular session.  The source port number SHOULD
>     be unique among all BFD sessions on the system.
>     ...
>     but the number of distinct uses of
>     the same UDP source port number SHOULD be minimize
>
> So that would seem to leave the other two options (send the UDP Port in
> the LSP-Ping, or allow for the UDP Port to change during the handshake.
>

Specifying the dest port as 3784 or 4784 for the egress to ingress BFD
packets addresses this.

> ---
>
> 7. Encapsulation
>
>     For MPLS PWs, alternatively,
>     the presence of a fault detection message may be indicated by setting
>     a bit in the control word [VCCV].
>
> This procedure needs signaling or static configuration to create the
> VCCV control channel before BFD packets could be exchanged over the
> control channel (with the bit in the CW). Are more details needed?

I will specify that the two ends in this case are assumed to be configured
to use this control channel. And signaling this capability is outside the
scope of this document.

> See
> below as well.
>
> ---
>
> 7. Encapsulation
>
>       In this case the destination IP address, used in a
>       BFD session established for one such alternate path, is the address
>       in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to
>       exercise that particular alternate path.
>
> A nit, where it says "is the address", there may be (and typically will
> be) multiple addresses from 127/8 to exercise a particular ECMP. Should
> that say "is one address from the 127/8 ... that exercises..."?
>

No. It is a particular address discovered for that path. The current text
is correct.

> Also, there is no mention of BFD Echo adjunct function to the
> asynchronous mode.
>

I will specify that the echo function is out of scope.

> ---
>
> 11.2. Informative References
>
>       [VCCV]     T. Nadeau, C. Pignataro, R. Aggarwal,
>                  "Pseudo Wire (PW) Virtual Circuit Connection Verification
>                  ((VCCV)", draft-ietf-pwe3-vccv-13.txt
>
> This reference points to rev 13 of this document. In the subsequent
> revision, this document was split into what resulted in RFC 5085 and the
> ID draft-ietf-pwe3-vccv-bfd. It seems that some citations refer to the
> former, while others to the latter, and they appear to be made in a
> Normative fashion (e.g., because the VCCV control channel needs to exist
> in order to send BFD packets over it).
> However, given that PWs need an associated VCCV control channel, do not
> need LSP-Ping boot-strapping (as can get the context from the PW label),
> should this document point to draft-ietf-pwe3-vccv-bfd (that goes into
> different BFD functional modes) for the PW case instead of also defining
> it here, since it has a number of specific unique issues?
>

This document simply needs to point to RFC 5085 for the control word based
control channel.

"The use of BFD for PWs is further described in [VCCV] and [OAM-MAP]."

It should point to draft-ietf-pwe3-vccv-bfd in the above statement
in section 3.1

rahul


> Thanks,
>
> --
> --Carlos Pignataro.
> Escalation RTP - cisco Systems
>
>
>
>