Hi Greg,
Thank you for promptly addressing my comments. The rev- 09 looks good, except that the first point seems to have not been fixed.
Thanks,
Bo Wu
From: Greg Mirsky <gregimirsky@xxxxxxxxx>
Sent: Friday, January 3, 2025 6:26 AM
To: Wubo (lana) <lana.wubo@xxxxxxxxxx>
Cc: ops-dir@xxxxxxxx; draft-ietf-mpls-p2mp-bfd.all@xxxxxxxx; last-call@xxxxxxxx; mpls@xxxxxxxx
Subject: Re: Opsdir last call review of draft-ietf-mpls-p2mp-bfd-08
Hi Bo Wu,
thank you for your thorough review and detailed comments. Please find my notes below tagged GIM>>. Attached is the diff that highlights all the updates applied in the working version of the draft.
Regards,
Greg
On Thu, Jan 2, 2025 at 12:53 AM 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.GIM>> Done.
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.GIM>> Added reference to Section 5.8 of RFC 8562.
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.GIM>> The new value of G-ACh is intended to identify all p2mp BFD sessions. Rules of demultiplexing p2mp BFD sessions defined in Section 5.7 of RFC 8562 are equally applicable to IP/UDP and non-IP encapsulations.
GIM>> As I understand it, abbreviation TBAn or TBDn is replaced before the publication by the actual value assigned by IANA. Updated text as follows s/TBA1/Multipoint BFD Session (TBA1)/
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?GIM>> Thank you for raising this question. I agree that the observation is equally applicable to other network types. Hence, I propose the following update:
OLD TEXT:
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.
NEW TEXT:
The notifications from leaves to the root will not
use resources allocated for the monitored multicast flow and, as a
result, will not congest that particular flow, although they may
negatively affect other flows.
Thanks,
Bo Wu
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
