Greg,
Thanks for your work,I think we are almost there.
If I read correctly SR-MPLS is still not expanded in the Abstract, since
the Abstract is may be used stand alone, abbreviations need to be
expanded in the Abstract.
And I think "BFD" in the title also need to be expanded.
/Loa
Den 02/01/2025 kl. 23:29, skrev Greg Mirsky:
Hi Loa,
thank you for your thoughtful recommendations. I corrected SR-MPLS
extended form and expanded LSP in the full title of the draft. These and
changes addressing comments shared by Bo Wu are highlighted in the
attached diff. WDYT?
Regards,
Greg
On Thu, Jan 2, 2025 at 5:55 AM Loa Andersson <loa.pi.nu@xxxxxxxxx
<mailto:loa.pi.nu@xxxxxxxxx>> wrote:
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
<mailto: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 <mailto:mpls@xxxxxxxx>
To unsubscribe send an email to mpls-leave@xxxxxxxx
<mailto:mpls-leave@xxxxxxxx>
--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
loa@xxxxx
loa.pi.nu.@xxxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
