Bo Wu,
Nice review.
All,
I have discussed expansion of abbreviations with the RFC Editor a bit over the last months.
I have a nit on SR-MPLS, since it occurs before the abbreviation list, it has to be expanded in text at first occurrence. Further it has ALSO to be expanded. In the abstract.
Also SR-MPLS is expanded as “segment routing with MPLS data plane”, the working group put “segment routing over MPLS” for the RFC Editors abbreviation list.
LSP not a well-known abbreviation (more than one valid abbreviation) and has to be expanded in the title.
/Loa
On Thu, 2 Jan 2025 at 09:56, Bo Wu via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Bo Wu
Review result: Has Nits
Hi,
I am the assigned OPS reviewer.
Thanks for the document. I have reviewed the version 08 draft, and the overall
structure and descriptions are clear.
This document defines extensions to the Bidirectional Forwarding Detection
(BFD) protocol for Multipoint Networks as described in RFC 8562, with a focus
on MPLS and SR p2mp multipoint networks. The updates include the definition of
a new MPLS G-ACh channel type for Multipoint BFD Session identity, as well as
updates to IP encapsulation definitions, bootstrapping, and specific operations.
Here are some minor comments:
1) Section 2.1. Terminology
It is recommended to rearrange the terms in alphabetical order for better
readability.
2) Section 3.1 IP Encapsulation of Multipoint BFD
"[RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp MPLS LSP.
This document updates [RFC8562] regarding the selection of the IPv6 destination
address:"
It is suggested to include the specific section of RFC 8562 as context, as it
is not immediately clear which sections of RFC 8562 need to be updated.
3) Section 3.2 Non-IP Encapsulation of Multipoint BFD
This section states that a new G-ACh channel type value is needed for the
identity of multipoint BFD session.
As mentioned above, it is recommended to reference the specific sections of RFC
8562, such as 5.7. Discriminators and Packet Demultiplexing. Additionally, the
new channel type value is currently defined as TBA1; it would be helpful to
name this value or expand on what TBA1 stands for.
4) Section 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP
“The notifications from leaves to the root will not use DetNet resources and,
as a result, will not congest DetNet flows, although they may negatively affect
other flows.”
In this text, the term "DetNet resource" is not referenced, and it's unclear
why DetNet is specified here. Is it necessary to limit the discussion to
DetNet, or could it apply to other network types as well?
Thanks,
Bo Wu
_______________________________________________
mpls mailing list -- mpls@xxxxxxxx
To unsubscribe send an email to mpls-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
