[mpls] MPLS-RT review for draft-mirsky-mpls-p2mp-bfd-14

[Italo Busi <[e-mail]>]

Hi all,
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.
Therefore, I think that the draft is ready to be adopted as a WG document.
I have few comments that can be addressed either before or after WG adoption.


1)      The abstract and introduction have a bit confused me when I have started to read the document



After having read the whole draft, my understanding is that the document is describing three points:

*       Procedures for BFD over p2mp LSPs

*       Use of LSP Ping to bootstrap a BFD over p2mp LSP session

*       The behavior of the active tail for head notification



The first two point apply to any case and not only to active tails with unsolicited notifications mode.



Is my understanding correct?



In this case, it may be better to move the content of section 4.2 to a new section 5.



I would also propose the following rephrasing for the abstract (could be further improved):



OLD

   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) using active tails with unsolicited

   notifications mode.  It also describes the applicability of LSP Ping,

   as in-band, and the control plane, as out-band, solutions to

   bootstrap a BFD session in this environment.

NEW

   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).



   It also describes the applicability of LSP Ping,

   as in-band, and the control plane, as out-band, solutions to

   bootstrap a BFD session.



   It also describes the behavior of the active tail for head notification.



I would also propose the following rephrasing for the abstract (could be further improved):



OLD

   [RFC8562] defines a method of using Bidirectional Detection (BFD)

   [RFC5880] to monitor and detect unicast failures between the sender

   (head) and one or more receivers (tails) in multipoint or multicast

   networks.  [RFC8562] added two BFD session types - MultipointHead and

   MultipointTail.  Throughout this document, MultipointHead and

   MultipointTail refer to the value of the bfd.SessionType is set on a

   BFD endpoint.  This document describes procedures for using such

   modes of BFD protocol to detect data plane failures in Multiprotocol

   Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched

   Paths (LSPs).  The document also describes the applicability of out-

   band solutions to bootstrap a BFD session in this environment.

NEW

   [RFC8562] defines a method of using Bidirectional Detection (BFD)

   [RFC5880] to monitor and detect unicast failures between the sender

   (head) and one or more receivers (tails) in multipoint or multicast

   networks.



   [RFC8562] added two BFD session types - MultipointHead and

   MultipointTail.  Throughout this document, MultipointHead and

   MultipointTail refer to the value of the bfd.SessionType is set on a

   BFD endpoint.



   This document describes procedures for using such

   modes of BFD protocol to detect data plane failures in Multiprotocol

   Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched

   Paths (LSPs).



   The document also describes the applicability of out-

   band solutions to bootstrap a BFD session in this environment.



   It also describes the behavior of the active tail for head notification.



2)      Could you provide some reference where the inclusive p-tree and aggregate p-tree are defined?



If I understand properly the text, the issue is that the MPLS LSP label is not always present so it is not sufficient to always identify the multipoint tree.



Am I missing something?



3)      The setting of the IP DA in section 3.1 of this draft does not seem the same as in RFC8562:

*       section 3.1 of this draft says: 127.0.0.1/32 for IPv4 or ::1/128 for IPv6

*       RFC8562 says: 127.0.0.0/8 range for IPv4 or 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6



Is there any specific reason not to use other values in the range defined by RFC8562?



4)      For section 3.2, have you considered re-using the BFD CV codepoint defined in RFC6428 instead of defining a new codepoint?



5)      In section 5.1 of RFC8563, it is said that this mechanism "uses the reverse unicast path, but not the forward unicast path"



It is therefore not clear then how the head can send the unicast IP/UDP encapsulated BFD Control packet with the Final (F) bit set to the egress LSR

Italo