Re: [mpls] FW: New Version Notification for draft-ietf-bfd-rfc5884-bis-00.txt
Jeffrey Haas <[email protected]> Fri, 19 Jun 2026 15:59:12 -0400
| Newsgroups | gmane.ietf.rtg-bfd,gmane.ietf.mpls |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------9u8wUW0aXPm802PyqBM30Jt3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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
--------------9u8wUW0aXPm802PyqBM30Jt3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Greg,</p>
<p>Thanks for the review for this round, and hopefully for the
entire -bis effort as we move things to Internet standard. Some
partial responses:</p>
<div class="moz-cite-prefix">On 6/19/26 15:02, Greg Mirsky wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>
<ul>
<li>As the 5884bis is the result of merging RFCs 5884 and
7726, should the lists of authors also be merged?</li>
</ul>
</div>
</div>
</blockquote>
<p>My recommendation for the next round would be to update the
author list with the union between the two drafts. </p>
<p>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.</p>
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>At some point, we need to update authors' affiliations
and verify contact information.</li>
</ul>
</div>
</div>
</blockquote>
... 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.
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>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?</li>
<li>The Abstract notes that the 5884bis obsoletes RFC 5884
and 7726. Should that, possibly in a more extended
statement, be noted in the Introduction?</li>
<li>I believe that reference to LSP ping should be switched
from RFC 4379 to RFC 8029.</li>
</ul>
</div>
</div>
</blockquote>
<p>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:</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/bfd-wg/draft-ietf-bfd-rfc5884-bis">https://github.com/bfd-wg/draft-ietf-bfd-rfc5884-bis</a></p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<div dir="ltr">
<div>
<ul>
<li>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:</li>
</ul>
</div>
</div>
</blockquote>
<p>Thanks for raising this point. I think it's likely to be a
substantive discussion point for this -bis.</p>
<p>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.</p>
<p>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.</p>
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<div dir="ltr">
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div> 2. If an LSP is broken in such a way that it
prematurely terminates,</div>
</blockquote>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div> the diagnostic packet MUST NOT be IP forwarded.</div>
</blockquote>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>That is because IPv6 has a single loopback address ::1,
and 0:0:0:0:0:FFFF:7F00:0/104 range is routable. <a
href="https://datatracker.ietf.org/doc/rfc9780/"
moz-do-not-send="true">RFC 9780</a> defines</div>
an IPv6 address from the Dummy IPv6 Prefix address block
100:0:0:1::/64 for precisely this use case.</blockquote>
</div>
</blockquote>
<p>Responding to the two core objections I would have raised during
the 8029 work:</p>
<p>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.</p>
<p>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.</p>
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<div dir="ltr">
<ul>
<li>The list in Section 3.1 - c) and d) should be separated.</li>
<li>Perhaps s/LSP Ping includes extensive control plane
verification/LSP Ping ensures extensive control plane
verification/</li>
<li>a) and c) in the list in Section 3.2 need some
beautification.</li>
<li>Should we use consistent, e.g., alphabetical, marking of
elements in the lists?</li>
<li>In Section 3.2, the last list is misaligned.</li>
<li>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?</li>
</ul>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
If there are multiple alternate paths from an ingress LSR to
an<br>
egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be
used to<br>
determine each of these alternate paths. A BFD session
SHOULD be<br>
established for each alternate path that is discovered.<br>
</blockquote>
<ul>
<li>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?</li>
</ul>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
To use BFD for fault detection on an MPLS LSP, a BFD session
MUST be<br>
established for that particular MPLS LSP. BFD Control
packets MUST<br>
be sent along the same data path as the LSP being verified
and are<br>
processed by the BFD processing module of the egress LSR.</blockquote>
</div>
</blockquote>
<p>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.</p>
<p>Should we restrict our ECMP discussions primarily to the MPLS
document or consider it earlier in the document cluster?</p>
<blockquote type="cite"
cite="mid:CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com">
<div dir="ltr">
<ul>
<li>It is not clear to me where the reference "as described
above" in Section 5 points to.</li>
<li>Should the following text from Section 6 be moved to
Abstract and Introduction?</li>
</ul>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
This specification<br>
describes procedures only for BFD asynchronous mode. BFD
demand mode<br>
is outside the scope of this specification. Further, the
use of the<br>
BFD Echo function is outside the scope of this
specification.<br>
</blockquote>
<ul>
<li>It seems like a forward reference to Section 6.1 would be
helpful to a reader:</li>
</ul>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
This BFD<br>
Control packet MUST set the Your Discriminator field to the<br>
discriminator received from the ingress LSR in the LSP Ping
Echo<br>
request message.<br>
</blockquote>
<ul>
<li>Would adding a figure to Section 6.1 to visualize the BFD
Discriminator TLV be useful?</li>
<li>It seems like text imported from RFC 7726 carries
references to RFC 5884, which can be removed from the
5884bis.</li>
<li>Should the Operational Considerations section be added as
required by <a
href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/"
moz-do-not-send="true">draft-ietf-opsawg-rfc5706bis</a>?</li>
</ul>
</div>
</blockquote>
<p>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".</p>
<p>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.</p>
<p>My two concerns for that are:</p>
<p>1. Our discussion with our AD was that we're trying to go for
minimal changes for these -bis. </p>
<p>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?</p>
<p>We'll want to hear from our AD and the OPS AD on these points.</p>
<p>-- Jeff</p>
<br>
</body>
</html>
--------------9u8wUW0aXPm802PyqBM30Jt3--