[BFD] bfd-mpls-05

["Damodharan SP - TLS , Chennai" <[e-mail]>]

WGLC comments on bfd-mpls-05

Hi,

   As per my understanding of bfd mpls and the comments from the below mail

 

   In "draft-ietf-bfd-mpls-05.txt"

       The UDP destination port to be used for control packets from egress to ingress is not clear.

       

   case 1.  "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."

       -> It means that the UDP destination port for the packet from egress to ingress

           should be copied from source udp port of the packet received the ingress.

     

  case  2.  "The BFD control packet sent by the egress LSR to the ingress LSR MAY
       be routed based on the destination IP address as per the procedures
       in [BFD-MHOP]."

 

       BFD-MHOP("https://hcltmail-chn.hcl.in/exchange/damodharansp/all-ids/draft-ietf-bfd-multihop-06.txt" rel="nofollow">draft-ietf-bfd-multihop-06.txt") :

       "The encapsulation of BFD Control packets for multihop application in
        IPv4 and IPv6 is identical to that defined in [https://hcltmail-chn.hcl.in/exchange/damodharansp/Drafts/FW:%20WGLC%20comments%20on%20bfd-mpls-05.EML/1_text.htm#ref-BFD-1HOP" rel="nofollow">BFD-1HOP], except that
        the UDP destination port MUST have a value of 4784.  This can aid in  
        the demultiplexing and internal routing of incoming BFD packets."

          

       -> It means that the UDP destination port must be 4784.

So  1. Which UDP destination port to use for the control packet from egress to ingress (case 1 or case 2)?

      2. Destination IP address to be used for the control packets from egress to ingress

          before receiving the bfd packets from ingress(after BFD Discriminator TLV is exchanged by lsp ping)?

 

Regards,

Damodharan.S

---

From: [e-mail] on behalf of Carlos Pignataro
Sent: Fri 2/29/2008 3:46 AM
To: BFD WG
Subject: WGLC comments on bfd-mpls-05

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

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------