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

From: Italo Busi <[email-masked]>
Date: Thu, 19 Aug 2021 14:25:51 +0000

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

---

From: <[email-masked]>
Date: Sat, 21 Aug 2021 07:43:31 +0800 (CST)

Hi Italo,

I much appreciate your detailed review, thoughtful comments, and helpful suggestions. I've applied the proposed updates to a new version of the draft. Please find my answers below in-line tagged GIM>>.

Kind regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: ItaloBusi
To: [email-masked];[email-masked];Mach Chen;
CC: [email-masked];
Date: 2021/08/19 07:26
Subject: [mpls] MPLS-RT review for draft-mirsky-mpls-p2mp-bfd-14

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

Hi all,

 

 

·       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

 

GIM>> Yes, you're abolutely correct.

GIM>> I agree and made the appropriate update in the working version of the drtaft.

 

OLD

NEW

  

   bootstrap a BFD session.

 GIM>> Thank you for the suggested text. It improves the Abstract.

 

OLD

NEW

   networks.

   BFD endpoint.

   Paths (LSPs).

 

 GIM>> Thank you for your helpdul suggestion improving the Introduction. Accepted into the new working version of the draft.

GIM>> RFC 6513 defines Inclusive Tree (Section 2.2.1) P-Multicast Service Interfaces and Aggregate Tree (Section 6.3).

 

Am I missing something?

GIM>> If you're asking about how a tail demultiplexes BFD control packets, then RFC 8562 explains the updated procedure. Because p2mp BFD does not use the three-way handshake, BFD control packets cannot be demultiplexed using the value in the Your Discriminator field. Instead, RFC 8562 defines in Section 5.7 that the three-tuple, source address, My Discriminator, and the identity of the multicast tree must be used. In the draft, we don't assume how the identity of the multicast tree can be verified.

·       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

GIM>> Yes, you're right. In the course of IESG reviewing RFCs 8562 and 8971 BFD for VXLAN, we've received comments (even DISCUSS) on the choice of the destination IP address in the case of IP/UDP encapsulation of the BFD control packet. Initially, using the destination address in MPLS LSP ping was suggested to exercise available ECMP paths and then use the same address for the BFD session. But that was the accepted mechanism before the introduction of the Entropy label in RFC 6790. But the strongest argument to use a single IPv4 loopback address was that that would match with what is used in IPv6.

GIM>> Yes, we had and decided that using a new ACH type may help implementors as the behavior of the remote peer is different from when ACH 0x0022 is used. What do you think?

 

GIM>> Thank you for pointing this out. The Unsolicited Notification mode is described in Section 5.2.1 RFC 8563 somewhat tersely. The mechanism of tail notifying the head is not described and is implicitly out of scope. We may need to discuss whether this document updates RFC 8563 in part how Section 5.2.1 characterizes the unsolicited notification method with BFD WG. On the other hand, the text seems to be only informative without any normative content. What would you suggest?

Italo