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

[Jeffrey Haas <[e-mail]>]

Greg,

Thanks for the review for this round, and hopefully for the entire -bis 
effort as we move things to Internet standard.  Some partial responses:

On 6/19/26 15:02, Greg Mirsky wrote:
>
>   * As the 5884bis is the result of merging RFCs 5884 and 7726, should
>     the lists of authors also be merged?
>
My recommendation for the next round would be to update the author list 
with the union between the two drafts.

This will clearly push us well past the usual 5-author limit. We will be 
asking our AD to seek early advice about how we'll deal with this as 
part of publication.

>   * At some point, we need to update authors' affiliations and verify
>     contact information.
>
... and get them to respond to the last call.  I somewhat expect this 
part of the effort to be harder than gathering the implementation 
report.  Current practice for non-responsive authors involves moving 
them out of the author line into the contributors section.  However, 
we're interested in supplying appropriate credit to all involved.
>
>   * 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.
>
In addition to our editors taking feedback from the list, we also have a 
github repository for each document where issues can be opened to track 
comments to conclusion.  The repository for this document is:

https://github.com/bfd-wg/draft-ietf-bfd-rfc5884-bis


>   * 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:
>
Thanks for raising this point. I think it's likely to be a substantive 
discussion point for this -bis.

My personal opinion is that the change from the loopback network done in 
RFC 8029 was a mistake and has implications well outside of the BFD 
considerations.  Somewhat disturbing, this particular change happened 
after the prior BFD group review and wasn't flagged for explicit BFD 
working group review during the IESG review process.

I've flagged this previously to our AD and also in email conversations 
for the v6ops chairs since the new network are effectively de facto 
changes to the IPv6 host considerations.  I will also own up to not 
rigorously following up on this since my own discovery of this change 
happened in the midst of an IETF session and I forgot to do the 
followups in email.  Given my failures in better flagging this (Reshad 
may have taken different actions that we haven't discussed), let's 
consider this a fresh start on discussing the issue.  It might be worth 
spinning this point to its own thread.

>        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.
>
Responding to the two core objections I would have raised during the 
8029 work:

1. The new dummy networks are just as routable.  What's worse is that 
the desired behavior of them would have resulted in a desire to mark 
these networks as "martian" addresses so that routing stacks avoid 
routing them.

2. The forwarding desire for these networks is that they are solely 
local.  The loopback address (IPv6) and loopback network (IPv4) didn't 
have this problem.  The IPv6 mapped network had mixed semantics that 
were perhaps inconsistently standardized. However, the new networks have 
no "magic" semantics beyond this RFC and implementing the "do not 
forward" semantic is an update to the IPv6 host considerations.  Did I 
miss updates in the various IPv6 working groups to standardize that?  I 
admit to not being able to follow them, but discussion with some of the 
relevant SMEs seemed to surprise them as well.

>   * 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.
>
Expanding on the point here, BFD behavior in the presence of ECMP was 
under-specified in our prior documents.  It periodically comes up as a 
discussion point - and more so for the explicitly routed MPLS cases.

Should we restrict our ECMP discussions primarily to the MPLS document 
or consider it earlier in the document cluster?

>   * 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/>?
>
Our recent RFC work for the authentication documents did have some 
discussion with the IESG about operational considerations as part of the 
IESG review process.  At least one of the comments could largely have 
been read as "these are operational considerations generic to BFD and 
don't belong in the incremental feature document".

We're in the midst of -bis work, and thus it's appropriate to consider 
such general-purpose operational considerations, as well as such 
considerations for each specific document.

My two concerns for that are:

1. Our discussion with our AD was that we're trying to go for minimal 
changes for these -bis.

2. 5706-bis is itself in flight. Is it going to be "done" enough to want 
to attach it as a heavy boat anchor to the update?

We'll want to hear from our AD and the OPS AD on these points.

-- Jeff