Re: [mpls] MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-14

[Greg Mirsky <[e-mail]>]

Hi Shraddha,
thank you for your kind words supporting this work. I greatly appreciate
your comments and suggestions. Please find my answers below under the GIM>>
tag.
I'll be glad to apply and submit the updates proposed below if you find
them acceptable.

Regards,
Greg

On Wed, Sep 15, 2021 at 12:17 AM Shraddha Hegde <[e-mail]>
wrote:

> Hi Authors,
>
> I have been selected as one of the  MPLS-RT reviewers of
> draft-mirsky-mpls-p2mp-bfd-14.
>
> I think that the document is coherent, is it useful (i.e., it addresses a
> real need for operational networks), and it is technically sound.
>
GIM>> Thank you

>
>
> I have few comments that can be addressed either before or after WG
> adoption.
>
> 1. Introduction
>
> The introduction section specifies "Multiprotocol
>    Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched
>    Paths (LSPs)" as the scope of the document.
>    It would be good to state  explicitly
>    whether this draft applies to SR P2MP or not.
>
GIM>> Would the following update in Abstract and Introduction be helpful:
OLD TEXT:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) for multipoint networks to detect data plane failures
   in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)
   Label Switched Paths (LSPs).
NEW TEXT:
   This document describes procedures for using Bidirectional Forwarding
   Detection (BFD) for multipoint networks to detect data plane failures
   in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)
   Label Switched Paths (LSPs) and Segment Routing (SR) point-to-
   multipoint policies with SR-MPLS data plane.


>
>    2.
>     IP Encapsulation of Multipoint BFD
>
>         Is there a reason why entropy label is specified with "SHOULD"
>         and the UDP source port mechansim is a "MAY".?
>         If there is a preference, the reason for that preference should be
>         clearly described.
>
GIM>> As discussed in the Motivation section RFC 6790, generating entropy
information at the ingress LSR has clear advantages compared to when a
transit LSR infers entropy using MPLS label stack or payload information. I
propose adding that as the following text in Section 3.1:
NEW TEXT:
   The Motivation section [RFC6790] lists several advantages of
   generating the entropy value by an ingress Label Switching Router
   (LSR) compared to when a transit LSR infers entropy using the
   information in the MPLS label stack or payload.  Thus this
   specification further clarifies that:

>
>         3. section 4.1
>         For the benefit of the reader, Describe how the LSP Ping messages
> are constructed.
>
GIM>> This specification does not change procedures defined in RFC 8029,
RFC 6425 and RFC 8287 (adding RFC 8287 as Normative reference). Would
adding references as below be acceptable:
NEW TEXT:
   For the case
   of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in
   Section 3.1 [RFC6425].  For the case of p2mp SR policy with SR-MPLS
   data plane, an implementation of this specification MUST follow
   procedures defined in [RFC8287].

>
>
>         4. section 4.1
>         Does the presence of BFD discriminator TLV indicate that the LSP
> ping
>         is for bootstrapping the P2MP BFD session?. Would be good to
> clarify that.
>
GIM>> You are right, the presence of the BFD Discriminator TLV in an LSP
echo request is to bootstrap a BFD session. This specification uses the BFD
Discriminator TLV as it is defined in RFC 5884 but only recommends using
"Do not reply" value in the Reply mode field. The second paragraph in
Section 4.1 is intended to provide information to an implementor who have
chosen to use LSP Ping (with the next text as proposed above):
   LSP Ping, as defined in [RFC6425], MAY be used to bootstrap
   MultipointTail.  If LSP Ping is used, it MUST include the Target FEC
   TLV and the BFD Discriminator TLV defined in [RFC5884].  For the case
   of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in
   Section 3.1 [RFC6425].  For the case of p2mp SR policy with SR-MPLS
   data plane, an implementation of this specification MUST follow
   procedures defined in [RFC8287].  Setting the value of Reply Mode
   field to "Do not reply" [RFC8029] for the LSP Ping to bootstrap
   MultipointTail of the p2mp BFD session is RECOMMENDED.  Indeed,
   because BFD over a multipoint network uses BFD Demand mode, the LSP
   echo reply from a tail has no useful information to convey to the
   head, unlike in the case of the BFD over a p2p MPLS LSP [RFC5884].
 Would appreciate if you suggest a specific text.

Regards,
Greg

>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Loa Andersson <[e-mail]>
> Sent: Thursday, July 22, 2021 3:28 PM
> To: Mach Chen <[e-mail]>; Italo Busi <[e-mail]>;
> Rakesh Gandhi (rgandhi) <[e-mail]>; Shraddha Hegde <
> [e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: MPLS-RT review of draft-mirsky-mpls-p2mp-bfd-14
>
> [External Email. Be cautious of content]
>
>
> Mach, Italo, Rakesh, and Shraddha,
>
> You have been selected as MPLS-RT reviewers for
> draft-mirsky-mpls-p2mp-bfd-14
>
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
>
> Reviews should comment on whether the document is coherent, is it useful
> (ie, is it likely to be actually useful in operational networks), and is
> the document technically sound?  We are interested in knowing whether the
> document is ready to be considered for WG adoption (ie, it doesn't have to
> be perfect at this point, but should be a good start).
>
> Reviews should be sent to the document authors, WG co-chairs and WG
> secretary, and CC'd to the MPLS WG email list. If necessary, comments may
> be sent privately to only the WG chairs.
>
> If you have technical comments you should try to be explicit about what
> *really* need to be resolved before adopting it as a working group
> document, and what can wait until the document is a working group document
> and the working group has the revision control.
>
> Next week is IETF week, so we'd like to set the dead-line two weeks after
> the conclusion of the IETF 111.
>
> Can you review the document by August 13, 2021?
>
>
> Thanks, Loa
> (as MPLS WG chair)
>
> --
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]
>