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

[[e-mail]]

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: [e-mail] 
www.zte.com.cn






Original Mail



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


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

 

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?


GIM>> Yes, you're abolutely correct.


 


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


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


 


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.


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


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.


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


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


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


 


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?


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.


 


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?


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.


 


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


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?


 


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


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