Skip to main content

Last Call Review of draft-ietf-bess-evpn-bum-procedure-updates-09

Request Review of draft-ietf-bess-evpn-bum-procedure-updates
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2021-09-07
Requested 2021-08-24
Authors Zhaohui (Jeffrey) Zhang , Wen Lin , Jorge Rabadan , Keyur Patel , Ali Sajassi
I-D last updated 2021-09-06
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 Scott O. Bradner
State Completed
Request Last Call review on draft-ietf-bess-evpn-bum-procedure-updates by Ops Directorate Assigned
Posted at
Reviewed revision 09 (document currently at 14)
Result Has issues
Completed 2021-09-06
This is an OPS-DIR review of “Updates on EVPN BUM Procedures”

These comments should be treated as any other last-call comments

This ID describes procedures to be used to support unknown unicast, and
multicast (BUM) traffic in Ethernet VPNs, and as such, will impact the
operators of networks where the procedures are used.

I found this document to be quite complex and expect that operators will have a
hard time getting all the details right when trying to implement it.  I do not
know if it can be made more straightforward but I would not want to be assigned
to get this running properly on a big network.

That said, the procedures seem useful enough to publish the document as
requested but I hope the WG does a pass to see if it can be simplified first
and deal with the following:

Section 5.3.1 – uses SHOULD – but I do not see why a  SHOULD is used instead of

        In my opinion, a SHOULD introduces operational or implementation
        confusion unless
the SHOULD is accompanied with an explanation of what might happen if the
SHOULD is not followed so that the implementer or operator knows if it’s
important and why – if I were writing RFC 2119 today, knowing what has happened
since I did write it, I would not include SHOULD & SHOULD NOT – far better to
say “MUST unless the following is the case” or “MUST NOT unless the following
is the case” –

        if the authors fell that there is a reason to not use MUST & MUST NOT
        then it would
help if they included the reason in the text