Re: [mpls] FW: New Version Notification for draft-ietf-bfd-rfc5884-bis-00.txt

[Greg Mirsky <[e-mail]>]

Hi Vengada,
Thank you for driving this important work. I have read the document and
have several comments and questions:

   - As the 5884bis is the result of merging RFCs 5884 and 7726, should the
   lists of authors also be merged?
   - At some point, we need to update authors' affiliations and verify
   contact information.
   - Should Abstract and Introduction stress that this specification is
   applicable only to point-to-point LSP and PW, and BFD over a
   point-to-multipoint LSP and PW is outside the scope?
   - The Abstract notes that the 5884bis obsoletes RFC 5884 and 7726.
   Should that, possibly in a more extended statement, be noted in the
   Introduction?
   - I believe that reference to LSP ping should be switched from RFC 4379
   to RFC 8029.
   - An address from an IPv4-mapped IPv6 address
   range 0:0:0:0:0:FFFF:7F00:0/104 doesn't conform to the requirement in RFC
   8029:

   2.  If an LSP is broken in such a way that it prematurely terminates,

       the diagnostic packet MUST NOT be IP forwarded.

That is because IPv6 has a single loopback address ::1, and
0:0:0:0:0:FFFF:7F00:0/104 range is routable. RFC 9780
<https://datatracker.ietf.org/doc/rfc9780/> defines
an IPv6 address from the Dummy IPv6 Prefix address block 100:0:0:1::/64 for
precisely this use case.


   - The list in Section 3.1 - c) and d) should be separated.
   - Perhaps s/LSP Ping includes extensive control plane verification/LSP
   Ping ensures extensive control plane verification/
   - a) and c) in the list in Section 3.2 need some beautification.
   - Should we use consistent, e.g., alphabetical, marking of elements in
   the lists?
   - In Section 3.2, the last list is misaligned.
   - How useful is the following paragraph without discussing how to ensure
   that  BFD control packets of different BFD sessions in the ECMP environment
   traverse distinct paths?

   If there are multiple alternate paths from an ingress LSR to an
   egress LSR for an 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.


   - Continuing on the case of ECMP described above, consider a
   scenario when a single BFD session is used to monitor connectivity between
   two LERs over MPLS. In such a case, is the level of the normative language
   in the following reasonable? Could MUST be replaced by SHOULD?

   To use BFD for fault detection on an MPLS LSP, a BFD session MUST be
   established for that particular MPLS LSP.  BFD Control packets MUST
   be sent along the same data path as the LSP being verified and are
   processed by the BFD processing module of the egress LSR.


   - It is not clear to me where the reference "as described above" in
   Section 5 points to.
   - Should the following text from Section 6 be moved to Abstract and
   Introduction?

   This specification
   describes procedures only for BFD asynchronous mode.  BFD demand mode
   is outside the scope of this specification.  Further, the use of the
   BFD Echo function is outside the scope of this specification.


   - It seems like a forward reference to Section 6.1 would be helpful to a
   reader:

   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.


   - Would adding a figure to Section 6.1 to visualize the BFD
   Discriminator TLV be useful?
   - It seems like text imported from RFC 7726 carries references to RFC
   5884, which can be removed from the 5884bis.
   - Should the Operational Considerations section be added as required by
   draft-ietf-opsawg-rfc5706bis
   <https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/>?

Thank you for your consideration.

Regards,
Greg

On Thu, Jun 18, 2026 at 8:53 AM Vengada Prasad Govindan (venggovi)
<venggovi=[e-mail]> wrote:

> Hello BFD/ MPLS WG,
> As part of BFD RFCs being promoted to Internet Standard, please find the
> -00 version of the rfc5884-bis (the combined bis draft for RFC5884 and
> RFC7726). I have also incorporated 3 known errata for RFC5884 that have
> already been published. This document is the union of two RFCs (RFC5884
> contributing most of the text). It requires a good review from the WG for
> the flow of the document since two documents got merged. There is a
> questionnaire to be filled by implementors in the Appendix. If you have
> experience with implementations/ deployments, please respond to the
> questionnaire (I will be happy to record your responses in the document if
> you respond to me over email copying the WG as well).
>
> Thanks
> Prasad
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Thursday, June 18, 2026 08:09 PM
> To: Thomas D. Nadeau <[e-mail]>; George Swallow <[e-mail]>;
> Kireeti Kompella <[e-mail]>; Rahul Aggarwal <[e-mail]>;
> Thomas Nadeau <[e-mail]>; Vengada Prasad Govindan (venggovi) <
> [e-mail]>; Vengada Prasad Govindan (venggovi) <
> [e-mail]>
> Subject: New Version Notification for draft-ietf-bfd-rfc5884-bis-00.txt
>
> A new version of Internet-Draft draft-ietf-bfd-rfc5884-bis-00.txt has been
> successfully submitted by Vengada Prasad Govindan and posted to the IETF
> repository.
>
> Name:     draft-ietf-bfd-rfc5884-bis
> Revision: 00
> Title:    Bidirectional Forwarding Detection (BFD) for MPLS Label Switched
> Paths (LSPs)
> Date:     2026-06-18
> Group:    bfd
> Pages:    18
> URL:
> https://www.ietf.org/archive/id/draft-ietf-bfd-rfc5884-bis-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc5884-bis/
> HTML:
> https://www.ietf.org/archive/id/draft-ietf-bfd-rfc5884-bis-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc5884-bis
>
>
> Abstract:
>
>    One desirable application of Bidirectional Forwarding Detection (BFD)
>    is to detect a Multiprotocol Label Switching (MPLS) Label Switched
>    Path (LSP) data plane failure.  LSP Ping is an existing mechanism for
>    detecting MPLS data plane failures and for verifying the MPLS LSP
>    data plane against the control plane.  BFD can be used for the
>    former, but not for the latter.  However, the control plane
>    processing required for BFD Control packets is relatively smaller
>    than the processing required for LSP Ping messages.  A combination of
>    LSP Ping and BFD can be used to provide faster data plane failure
>    detection and/or make it possible to provide such detection on a
>    greater number of LSPs.  This document describes the applicability of
>    BFD in relation to LSP Ping for this application.  It also describes
>    procedures for using BFD in this environment.  This document
>    obsoletes RFC5884 and RFC7726.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>