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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> wrote:

> 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
>
>
>
>
> 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 <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:*
>
>    <...> 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.*
>
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.

> 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)*
>
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?

>
>
> Italo
>
>
>
>
>