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

[Italo Busi <[e-mail]>]

Hi Greg,

Thanks for your prompt reply and sorry to be late (still processing my mail log after holidays)

See some feedbacks in line marked with [[Italo Busi]]

Thanks, Italo

From: [e-mail] [mailto:[e-mail]]
Sent: sabato 21 agosto 2021 01:44
To: Italo Busi <[e-mail]>
Cc: [e-mail]; [e-mail]; Mach Chen <[e-mail]>; [e-mail]
Subject: Re:[mpls] MPLS-RT review for draft-mirsky-mpls-p2mp-bfd-14


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


[cid:image001.gif@01D7A333.09E8A4A0]

[cid:image002.gif@01D7A333.09E8A4A0]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: ItaloBusi
To: [e-mail];[e-mail];Mach<mailto:[e-mail];[e-mail];Mach> Chen;
CC: [e-mail]<mailto:[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]<mailto:[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<https://datatracker.ietf.org/doc/html/rfc6513> defines Inclusive Tree (Section 2.2.1) P-Multicast Service Interfaces and Aggregate Tree (Section 6.3).

[[Italo Busi] ] Thanks: I would suggest to add this (as informative) also in the draft



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.

[[Italo Busi] ] I am trying to fully understand the general message you wish to convey with this text:
   <...> The p2mp MPLS LSP label MAY provide the identification of
   the multipoint tree in case of an inclusive p-tree or upstream-
   assigned label in case of aggregate p-tree.

If your intention is to leave the assumption of how the identity of the multicast tree can be verified out of scope of the draft, I would suggest to be explicit about that

Thinking further, I am having the feeling that if the p2mp MPLS LSP label is not in the packet (e.g., because of PHP), then the tail cannot verify the identity of the multicast tree and that, in any case, the source address and the My Discriminator are sufficient to identify the BFD session at the tail.

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.

[[Italo Busi] ] I think it would be better to add some text explaining this to the draft and to mark the draft as an update of RFC8562 (I expect that not all the readers are familiar with the IESG discussion)



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?

[[Italo Busi] ] It’s fine for me



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 Busi] ] I would suggest to mark the draft as an update of RFC8563 since in section 5.2.1 (not section 5.1 as I have originally written incorrectly) RFC8563 clearly states that the forward unicast path is not used

BTW, is the forward unicast path required to be an IP path? If I understand correctly, the tail node will use the Your Discriminator field to associate the unicast BFD control packet with a local BFD session, so this packet can also be encapsulated within a G-ACh


Italo