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

From: Italo Busi <[email-masked]>
Date: Mon, 6 Sep 2021 13:45:04 +0000

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: [email-masked] [mailto:[email-masked]]
Sent: sabato 21 agosto 2021 01:44
To: Italo Busi <[email-masked]>
Cc: [email-masked]; [email-masked]; Mach Chen <[email-masked]>; [email-masked]
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

E: [email-masked]<mailto:[email-masked]>
www.zte.com.cn<http://www.zte.com.cn/>

Original Mail
Sender: ItaloBusi
To: [email-masked];[email-masked];Mach<mailto:[email-masked];[email-masked];Mach> Chen;
CC: [email-masked]<mailto:[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]<mailto:[email-masked]>
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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Sep 2021 19:36:43 -0700

Hi Italo,
many thanks for your follow-up notes that helped me make more improvements
to the draft. Please find my new notes in-lined below under the GIM2>> tag.
A new working version and the diff are attached.

Regards,
Greg

On Mon, Sep 6, 2021 at 6:45 AM Italo Busi <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* sabato 21 agosto 2021 01:44
> *To:* Italo Busi <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; Mach
> Chen <[email-masked]>; [email-masked]
> *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
>
>
>
> 预研标准部/有线研究院/有线产品经营部 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*
>
> [email-masked]
> 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.
>
> ·       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>> Thank you for your helpdul suggestion improving the Introduction.
> Accepted into the new working version of the draft.
>
> 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*
>
GIM2>> Based on the comment below, I agree that this is unnecessary and
the text can be removed..

>
>
> 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:*
>
> *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.*
>
GIM2>> Thank you for pointing it out to me. Indeed, the combination of the
Source IP address and My Discriminator value provide enough information to
demultiplex a BFD session at a tail in all scenarios, e.g., multiple BFD
p2mp sessions from the same Head. I've removed the text.

> ·       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.
>
> *[[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)*
>
GIM2>> I've added the following text:
NEW TEXT:
Note that that is different from how the destination
      IP address selection is defined in Section 7 [RFC5884].  Firstly,
      because only one loopback address ::1/128 is defined in IPv6.  And
      also, it is recommended to use the Entropy Label [RFC6790] to
      discover multiple alternate paths in an MPLS network.  Using a
      single loopback address both for IPv4 and IPv6 encapsulation makes
      it consistent and more straightforward for an implementation.

I am not sure that our proposal updates RFC 8562 (or RFC 5884). I think of
it as a simplification of the specification that makes IPv4 and IPv6
encapsulations look consistent.

>
>
> 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*
>
GIM2>> I've read the first paragraph in Section 5.2.1 again and probably
confused myself more:
   In this scenario, the tail sends unsolicited BFD packets in response
   to the detection of a multipoint path failure.  It uses the reverse
   unicast path, but not the forward unicast path.
I'll need an expert opinion on which element is meant in the "It uses ...".
Is it the tail that sends an unsolicited BFD control packet or the
characterizes the method as a whole. I hope it is okay to hold off marking
this as an update until we have a clearer interpretation of the text in RFC
8563.

> *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*
>
GIM2>> A very interesting question, thank you. I think that we can make the
following update:
OLD TEXT:
   o  BFD Control packet is encapsulated in IP/UDP with the destination
      IP address of the ingress LSR and the UDP destination port number
      set to 4784 per [RFC5883]
NEW TEXT:
  o  BFD Control packet MAY be encapsulated in IP/UDP with the
      destination IP address of the ingress LSR and the UDP destination
      port number set to 4784 per [RFC5883].  If non-IP encapsulation is
      used, then a BFD Control packet is encapsulated using PW-ACH
      encapsulation (without IP/UDP Headers) (0x0007) [RFC5885];
What is your opinion?