Re: [bess] RTG-DIR early review: draft-ietf-bess-evpn-bum-procedure-updates-10

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Sasha,

Thank you so much for your review and comments/suggestions. It was a pleasant experience working with you to address the issues you pointed out.

I have submitted revision -11 that addresses the two concerns you raised: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-bum-procedure-updates/

Thanks!
Jeffrey

From: BESS <[e-mail]> On Behalf Of Alexander Vainshtein
Sent: Thursday, October 7, 2021 8:48 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; Luc André Burdet <[e-mail]>; [e-mail]
Subject: [bess] RTG-DIR early review: draft-ietf-bess-evpn-bum-procedure-updates-10

[External Email. Be cautious of content]


Hello

I have been selected to do a routing directorate “early” review of this draft:  draft-ietf-bess-evpn-bum-procedure-updates-10<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-10__;!!NEt6yMaO-gk!RZeb-QnJHpkipVRZAUFJL92vdgTYhHeHc9Fu-ObilFS5scomMz3AbGZpuGJiAfr-$>.

The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached.

As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.com/v3/__http:/trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!!NEt6yMaO-gk!RZeb-QnJHpkipVRZAUFJL92vdgTYhHeHc9Fu-ObilFS5scomMz3AbGZpuHxmV7zA$>

Document: draft-ietf-bess-evpn-bum-procedure-updates-10

Reviewer: Alexander (”Sasha”) Vainshtein

Review Date: 05-Oct-21

Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before it is submitted to the IESG.

Comments:

The draft defines updates to RFC 7432 that deal with two aspects of handling broadcast, unknown unicast and multicast (BUM) traffic:

  1.  Usage of segmented Provider P2MP tunnels for implementing Provider Multicast Service Interface (PMSI) for deliver of BUM traffic in EVPN. In this regard the draft extends original definition of inter-AS segmented P-tunnels in NG MVPN defined in RFC 6513/RFC 6514 and continues the work on usage of such tunnels in VPLS  (RFC 7117) and in inter-area (as opposed to inter-AS) scenarios for both MVPN and VPLS (RFC 7524).
  2.  Usage of selective PMSI for delivery of specific multicast flows just to the PEs that have expressed interest in these flows using P2MP tunnel LSPs. In this regard the draft extends the work started in draft-ietf-bess-evpn-igmp-mld-proxy where selective delivery of BUM traffic is limited to ingress replication (IR) provider tunneling technology.

The draft is written in a very dense way. E.g., Section 5.1 of the draft contains just the deltas between the mechanisms already defined in RFC 7117 and the mechanisms proposed in this draft.  The authors explicitly state that they have intentionally selected this style, and, of course, it is quite valid to use it – but it requires very good understanding of the “previous art” in order to understand this draft. I cannot say whether this s or is not inevitable, but it definitely does not make the life of the reader/implementer simple.

While the draft provides a good description of motivation for using segmented P-tunnels for delivery of BUM traffic in intra-AS as well as inter-AS scenarios, personally I wonder how such usage is related with the techniques used for inter-AS/inter-domain “known unicast” traffic in EVPN. Specifically I doubt usage of segmented P-tunnels for delivery of BUM traffic within a single AS is justified if an analog of “inter-AS Option C” is used for end-to-end delivery of known unicast traffic in the same service. It would be nice if the authors could elaborate on this point. Please note that this is not an issue to be addressed in the next revisions of the draft, just a point of personal interest.

I have presented my early comments on the draft to the authors, and received timely and satisfactory responses. I would like to specially thank Jeffrey (Zhaohui Zhang) for excellent cooperation.

The following has raised some concerns for me.

  1.  Section 7 “Multi-homing Support” discusses two deployment scenarios:

     *   Multi-homed segments do not span different ACs or regions. In this case the draft says that “a segmentation point will remove the ESI label from the packets”. I have two issues with this text:

                                                 i.    This text does not represent a requirement (no capitalized MUST or SHOULD) while, to the best of my understanding, the described behavior is mandatory unless DCB labels (defined in draft-ietf-bess-evpn-aggregation-label) are used as ECI labels

                                                ii.    The required behavior, i.e. removal of the label not on top of the stack (the segmentation point performs forwarding based on the received “tunnel”  label) is not part of the MPLS architecture as defined in RFC 3031 and RFC 5331.

I have discussed these issues with the authors, and they have agreed to restrict the draft to just the situations in which DCB labels are used as ESI labels. In this case their removal is not required, and both issues would disappear.

     *   Multi-homed segments do not span different ACs or regions. The text in the draft says that “additional procedures are needed to work with segmentation.  The procedures are well understood but omitted here until the requirement becomes clear”. From my POV such language is not appropriate in a Standards Track document, and the authors should decide whether they explicitly consider the scenario in question out of scope (possibly left for further study) or to provide detailed specification of these procedures. I have discussed this issue with the authors and they have agreed to state explicitly that this scenario is out of scope of the draft. After additional discussion it seems that restricting ESI labels used with segmented P-tunnels to just DCB labels eliminates this issue the Information Model of the MH ES, CLI and YANG as well.

  1.  In Section 6.3 of the draft the authors propose for the segmentation points to advertise I-PMSI/S-PMSI EVPN routes with “next hop self”. It also says that “If a downstream PE/RBR needs to originate Leaf A-D routes, it constructs an IP-based Route Target  Extended Community by placing the IP address carried in the Next Hop of the received I/S-PMSI A-D route in the Global Administrator field of the Community, with the Local Administrator field of this Community set to 0 and setting the  Extended Communities attribute of the Leaf A-D route to that Community”

     *   I have asked the authors to clarify this point and, specifically, to explain how such a scheme would interact with Constrained distribution (RFC 4684) of Leaf A-D routes
     *   The authors have indicated that this mechanism effectively is already defined in RFC 7524, and agreed to add the required clarification and references
     *   I have later found that a similar scheme is defined in Section 9.2 of RFC 6514 and that the required interaction with the constrained route distribution mechanism is also defined there.

Nits: I did not perform any nits checks on the draft.

Hopefully this review will be useful.

Regards,

Sasha








Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.


Juniper Business Use Only