Telechat Review of draft-ietf-bess-evpn-bum-procedure-updates-11
review-ietf-bess-evpn-bum-procedure-updates-11-genart-telechat-kyzivat-2021-10-13-00

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-bum-procedure-updates-11
Reviewer: Paul Kyzivat
Review Date: 2021-10-13
IETF LC End Date: 2021-09-07
IESG Telechat date: 2021-10-21

Summary:

This draft has serious issues, described in the review, and needs to be 
rethought.

General:

This review is substantially the same as my Last Call review. The 
authors disagreed with my primary concern, but neither did they dissuade 
me from my opinion. I understand that this largely a matter of 
philosophy and style. I'm repeating my concern here for consideration by 
the IESG. What follows is verbatim from my LC review.

My review of this document is limited because I have no knowledge of the 
subject domain. Nevertheless I think I was able to grasp the gist of 
what this document intends to achieve and identify a concern. However it 
is possible that I have misunderstood and so my comments may be off base.

While I have no reason to doubt the mechanisms specified, I think the 
manner in which they are specified is likely to lead to confusion and 
misunderstanding by developers.

IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not 
address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM 
traffic for EVPN while referencing RFC7117 for some of its procedures, 
even though RFC7117 had no provision for support of EVPN.

It appears to me that someone who had an implementation of RFC7117 for 
VPLS might have had to modify it to support RFC7432, yet RFC7432 did not 
indicate that it updated RFC7117. The developer would have had to infer 
what changes were required. But at least the changes seem to be small 
and unlikely to be misunderstood.

The current document specifies in its heading and abstract that it 
updates RFC7432, while not mentioning RFC7117. Yet section 2 says:

    ... For brevity, only changes/additions to relevant
    [RFC7117] and [RFC7524] procedures are specified, instead of
    repeating the entire procedures.

 From these it is ambiguous whether RFC7117 is or is not being updated. 
It then goes on to state:

    Note that these are to be applied
    to EVPN only, and not updates to [RFC7117] or [RFC7524].

This further clouds things. How could it be known how future updates to 
those documents might interact with the changes in this document?

In the remainder of the document I find no explicit text that appears to 
normatively updates RFC7432. I find this mystifying.

However there are numerous places that normatively change RFC7117. 
Several of these are of the form:

    The following bullet in Section N.N.N.N of [RFC7117]:
    ...
    is changed to the following when applied to EVPN:
    ...

even though RFC7117 didn't contemplate supporting EVPN at all. This 
seems to assume that an entirely different implementation of RFC7117 
will be made for EVPN and these modifications made to that, while not 
impacting implementations of RFC7117 being used for other types of VPNs. 
Is this a reasonable assumption?

Overall it seems that it will be very difficult for a developer to read 
this document and determine exactly what must be implemented, or after 
the fact to determine whether an implementation conforms to this document.

IMO a different style of specification is called for. Probably an 
RFC7117bis and perhaps a RFC7432bis.