Skip to main content

Early Review of draft-ietf-bess-evpn-bum-procedure-updates-11

Request Review of draft-ietf-bess-evpn-bum-procedure-updates
Requested revision No specific revision (document currently at 14)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2021-10-08
Requested 2021-08-24
Requested by Martin Vigoureux
Authors Zhaohui (Jeffrey) Zhang , Wen Lin , Jorge Rabadan , Keyur Patel , Ali Sajassi
I-D last updated 2021-10-15
Completed reviews Rtgdir Early review of -11 by Sasha Vainshtein (diff)
Tsvart Last Call review of -09 by Gorry Fairhurst (diff)
Genart Last Call review of -09 by Paul Kyzivat (diff)
Opsdir Last Call review of -09 by Scott O. Bradner (diff)
Genart Telechat review of -11 by Paul Kyzivat (diff)
Opsdir Telechat review of -11 by Scott O. Bradner (diff)
Assignment Reviewer Sasha Vainshtein
State Completed
Request Early review on draft-ietf-bess-evpn-bum-procedure-updates by Routing Area Directorate Assigned
Posted at
Reviewed revision 11 (document currently at 14)
Result Ready
Completed 2021-10-10
I have looked up
and confirm that all my comments have been addressed in this revision.


Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Thursday, October 7, 2021 3:48 PM
<> Cc:;; 'Luc André Burdet' <> Subject: RTG-DIR
early review: draft-ietf-bess-evpn-bum-procedure-updates-10


I have been selected to do a routing directorate “early” review of this draft: 

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

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

Reviewer: Alexander (”Sasha”) Vainshtein

Review Date: 05-Oct-21

Intended Status: Standards Track


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


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

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
                                                         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

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

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




Office: +972-39266302
Cell:      +972-549266302

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.