Re: [mpls] FW: New Version Notification for draft-ietf-bfd-rfc5884-bis-00.txt
Greg Mirsky <[email protected]> Fri, 19 Jun 2026 12:02:42 -0700
| Newsgroups | gmane.ietf.rtg-bfd,gmane.ietf.mpls |
|---|---|
| Message-ID | <CA+RyBmUgreZv2BxdGz2KJYEHqFb2UDcju=U-o_e3=cUV+0J9AA@mail.gmail.com> |
--000000000000b7566e06549ff0b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 RF=
C
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 environm=
ent
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 betwe=
en
two LERs over MPLS. In such a case, is the level of the normative langua=
ge
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=E2=80=AFAM Vengada Prasad Govindan (venggovi)
<[email protected]> 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 i=
f
> you respond to me over email copying the WG as well).
>
> Thanks
> Prasad
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Thursday, June 18, 2026 08:09 PM
> To: Thomas D. Nadeau <[email protected]>; George Swallow <[email protected]=
>;
> Kireeti Kompella <[email protected]>; Rahul Aggarwal <[email protected]=
>;
> Thomas Nadeau <[email protected]>; Vengada Prasad Govindan (venggovi) <
> [email protected]>; Vengada Prasad Govindan (venggovi) <
> [email protected]>
> 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 bee=
n
> 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 Switche=
d
> 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-bi=
s
>
>
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
>
--000000000000b7566e06549ff0b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Vengada,<div>Thank you for driving this important work.=
I have read the document and have several comments and questions:</div><di=
v><ul><li>As the 5884bis=C2=A0is the result of merging RFCs 5884 and 7726, =
should the lists of authors also be merged?</li><li>At some point, we need =
to update authors' affiliations and verify contact information.</li><li=
>Should Abstract and Introduction stress that this specification is applica=
ble only=C2=A0to point-to-point LSP and PW, and BFD over a point-to-multipo=
int LSP and PW is outside the scope?</li><li>The Abstract notes that the 58=
84bis 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><li>An addres=
s from an IPv4-mapped IPv6 address range=C2=A00:0:0:0:0:FFFF:7F00:0/104 doe=
sn't conform to the requirement in RFC 8029:</li></ul></div><blockquote=
style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>=C2=A0 =C2=A02.=
=C2=A0 If an LSP is broken in such a way that it prematurely terminates,</d=
iv></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:=
0px"><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0the diagnostic packet MUST NOT be IP f=
orwarded.</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:n=
one;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=3D"https://data=
tracker.ietf.org/doc/rfc9780/">RFC 9780</a> defines</div>an IPv6 address fr=
om the Dummy IPv6 Prefix address block 100:0:0:1::/64 for precisely this us=
e case.<br></blockquote><ul><li>The list in Section 3.1 - c) and d) should =
be separated.</li><li>Perhaps s/LSP Ping includes extensive control plane v=
erification/LSP Ping ensures extensive control plane verification/</li><li>=
a) and c) in the list in Section 3.2 need some beautification.</li><li>Shou=
ld 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=C2=A0
BFD control packets of different BFD sessions in the ECMP environment trave=
rse distinct paths?</li></ul><blockquote style=3D"margin:0 0 0 40px;border:=
none;padding:0px">=C2=A0 =C2=A0If there are multiple alternate paths from a=
n ingress LSR to an<br>=C2=A0 =C2=A0egress LSR for an LDP IP FEC, LSP Ping =
traceroute MAY be used to<br>=C2=A0 =C2=A0determine each of these alternate=
paths.=C2=A0 A BFD session SHOULD be<br>=C2=A0 =C2=A0established for each =
alternate path that is discovered.<br></blockquote><ul><li>Continuing on th=
e case of ECMP described above, consider a scenario=C2=A0when a single BFD =
session is used to=C2=A0monitor connectivity between two LERs over=C2=A0MPL=
S. 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=3D=
"margin:0 0 0 40px;border:none;padding:0px">=C2=A0 =C2=A0To use BFD for fau=
lt detection on an MPLS LSP, a BFD session MUST be<br>=C2=A0 =C2=A0establis=
hed for that particular MPLS LSP.=C2=A0 BFD Control packets MUST<br>=C2=A0 =
=C2=A0be sent along the same data path as the LSP being verified and are<br=
>=C2=A0 =C2=A0processed by the BFD processing module of the egress LSR.</bl=
ockquote><ul><li>It is not clear to me where the reference "as describ=
ed above" in Section 5 points to.</li><li>Should the following text fr=
om Section 6 be moved to Abstract and Introduction?</li></ul><blockquote st=
yle=3D"margin:0 0 0 40px;border:none;padding:0px">=C2=A0 =C2=A0This specifi=
cation<br>=C2=A0 =C2=A0describes procedures only for BFD asynchronous mode.=
=C2=A0 BFD demand mode<br>=C2=A0 =C2=A0is outside the scope of this specifi=
cation.=C2=A0 Further, the use of the<br>=C2=A0 =C2=A0BFD Echo function is =
outside the scope of this specification.<br></blockquote><ul><li>It seems l=
ike a forward reference to Section 6.1 would be helpful to a reader:</li></=
ul><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">=C2=A0 =
=C2=A0This BFD<br>=C2=A0 =C2=A0Control packet MUST set the Your Discriminat=
or field to the<br>=C2=A0 =C2=A0discriminator received from the ingress LSR=
in the LSP Ping Echo<br>=C2=A0 =C2=A0request 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 r=
eferences to RFC 5884, which can be removed from the 5884bis.</li><li>Shoul=
d the Operational Considerations section be added as required by=C2=A0<a hr=
ef=3D"https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/">draft=
-ietf-opsawg-rfc5706bis</a>?</li></ul><div>Thank you for your consideration=
.</div><div><br></div><div>Regards,</div><div>Greg</div></div><br><div clas=
s=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_att=
r">On Thu, Jun 18, 2026 at 8:53=E2=80=AFAM Vengada Prasad Govindan (venggov=
i) <venggovi=3D<a href=3D"mailto:[email protected]">40cisco.com=
@dmarc.ietf.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">Hello BFD/ MPLS WG,<br>
As part of BFD RFCs being promoted to Internet Standard, please find the -0=
0 version of the rfc5884-bis (the combined bis draft for RFC5884 and RFC772=
6). I have also incorporated 3 known errata for RFC5884 that have already b=
een 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 t=
he document since two documents got merged. There is a questionnaire to be =
filled by implementors in the Appendix. If you have experience with impleme=
ntations/ deployments, please respond to the questionnaire (I will be happy=
to record your responses in the document if you respond to me over email c=
opying the WG as well).<br>
<br>
Thanks<br>
Prasad<br>
<br>
-----Original Message-----<br>
From: <a href=3D"mailto:[email protected]" target=3D"_blank">interne=
[email protected]</a> <<a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a>> <br>
Sent: Thursday, June 18, 2026 08:09 PM<br>
To: Thomas D. Nadeau <<a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a>>; George Swallow <<a href=3D"mailto:swallo=
[email protected]" target=3D"_blank">[email protected]</a>>; Kireeti Kompella <=
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
t</a>>; Rahul Aggarwal <<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>>; Thomas Nadeau <<a href=3D"mailto:=
[email protected]" target=3D"_blank">[email protected]</a>>; Vengada Pra=
sad Govindan (venggovi) <<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>>; Vengada Prasad Govindan (venggovi) <=
;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
</a>><br>
Subject: New Version Notification for draft-ietf-bfd-rfc5884-bis-00.txt<br>
<br>
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 re=
pository.<br>
<br>
Name:=C2=A0 =C2=A0 =C2=A0draft-ietf-bfd-rfc5884-bis<br>
Revision: 00<br>
Title:=C2=A0 =C2=A0 Bidirectional Forwarding Detection (BFD) for MPLS Label=
Switched Paths (LSPs)<br>
Date:=C2=A0 =C2=A0 =C2=A02026-06-18<br>
Group:=C2=A0 =C2=A0 bfd<br>
Pages:=C2=A0 =C2=A0 18<br>
URL:=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/archive/id/draft-i=
etf-bfd-rfc5884-bis-00.txt" rel=3D"noreferrer" target=3D"_blank">https://ww=
w.ietf.org/archive/id/draft-ietf-bfd-rfc5884-bis-00.txt</a><br>
Status:=C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-=
bfd-rfc5884-bis/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.=
ietf.org/doc/draft-ietf-bfd-rfc5884-bis/</a><br>
HTML:=C2=A0 =C2=A0 =C2=A0<a href=3D"https://www.ietf.org/archive/id/draft-i=
etf-bfd-rfc5884-bis-00.html" rel=3D"noreferrer" target=3D"_blank">https://w=
ww.ietf.org/archive/id/draft-ietf-bfd-rfc5884-bis-00.html</a><br>
HTMLized: <a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-bfd-r=
fc5884-bis" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.o=
rg/doc/html/draft-ietf-bfd-rfc5884-bis</a><br>
<br>
<br>
Abstract:<br>
<br>
=C2=A0 =C2=A0One desirable application of Bidirectional Forwarding Detectio=
n (BFD)<br>
=C2=A0 =C2=A0is to detect a Multiprotocol Label Switching (MPLS) Label Swit=
ched<br>
=C2=A0 =C2=A0Path (LSP) data plane failure.=C2=A0 LSP Ping is an existing m=
echanism for<br>
=C2=A0 =C2=A0detecting MPLS data plane failures and for verifying the MPLS =
LSP<br>
=C2=A0 =C2=A0data plane against the control plane.=C2=A0 BFD can be used fo=
r the<br>
=C2=A0 =C2=A0former, but not for the latter.=C2=A0 However, the control pla=
ne<br>
=C2=A0 =C2=A0processing required for BFD Control packets is relatively smal=
ler<br>
=C2=A0 =C2=A0than the processing required for LSP Ping messages.=C2=A0 A co=
mbination of<br>
=C2=A0 =C2=A0LSP Ping and BFD can be used to provide faster data plane fail=
ure<br>
=C2=A0 =C2=A0detection and/or make it possible to provide such detection on=
a<br>
=C2=A0 =C2=A0greater number of LSPs.=C2=A0 This document describes the appl=
icability of<br>
=C2=A0 =C2=A0BFD in relation to LSP Ping for this application.=C2=A0 It als=
o describes<br>
=C2=A0 =C2=A0procedures for using BFD in this environment.=C2=A0 This docum=
ent<br>
=C2=A0 =C2=A0obsoletes RFC5884 and RFC7726.<br>
<br>
<br>
<br>
The IETF Secretariat<br>
<br>
<br>
_______________________________________________<br>
mpls mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">mpl=
[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a><br>
</blockquote></div>
--000000000000b7566e06549ff0b1--