Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09

From: Paul Kyzivat <[email-masked]>
Date: Sat, 4 Sep 2021 12:48:52 -0400

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

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

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

Summary:

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

General:

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.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 8 Sep 2021 13:24:09 +0000

Hi Paul,

Thank you for your review and comments.

Please see zzh> below.

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Sent: Saturday, September 4, 2021 12:49 PM
To: [email-masked]
Cc: General Area Review Team <[email-masked]>
Subject: Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[External Email. Be cautious of content]

<https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!NEt6yMaO-gk!W0Qg_GJNKPW9qxyacZa9GrMR4O0HrEFl8S5yRxLO1hOD_VPsIHq7quz78j2zMaGr$ >.

Summary:

General:

Zzh> RFC7432's reference to RFC7117 is informational (so that people familiar with 7117 can easily relate to the similar procedures), and it (RFC7432) covers "inclusive P2MP tunnel" only (when it comes to BUM support), i.e., all BUM traffic (from a PE) goes into a single P2MP tunnel that reaches all other PEs, whether a PE needs to receive traffic or not. That inclusive tunnel is also un-segmented.
Zzh> RFC7117 itself does also cover selective and segmented tunnel (for VPLS), and this document, covers selective and/or segmented tunnel for EVPN.

zzh> This document does indeed not update RFC7117/7524, which is for VPLS/MVPN not for EVPN.
Zzh> However, since most of the selective/segmented tunnel procedures for EVPN are very similar to those in RFC7117/7524, we decided not to repeat them in this document, but to refer to 7117/7524 with modifications pointed out.

Zzh> As explained above, the intention is to refer to existing procedures in RFC7117/7524 with modifications pointed out for EVPN selective/segmented tunnels. Those modifications are for EVPN only not for VPLS/MVPN.

Zzh> All procedures in this document (including those referring to 7117/7524) are additional optional procedures that 7432 does not cover.

Zzh> Yes.
Zzh> RFC7117 is for VPLS, which predates EVPN. EVPN comes later and is specified in 7432, though 7432 has informational reference to 7117 when it comes to "inclusive non-segmented P2MP" tunnel, and this document refers to 7117's selective/segmented tunnel procedures with modifications pointed out.

Zzh> Hope my explanation above is making things a little bit clearer now. You can see that it is definitely not a RFC7117bis; it is not a RFC7432bis either (rather it is an extension to RFC7432).
Zzh> I can put in some text to explain the above in the document, and any suggestions are appreciated (quite often I take things for granted and not realizing where/what can add clarity).
Zzh> Thanks!
Zzh> Jeffrey

Juniper Business Use Only

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 8 Sep 2021 11:14:47 -0400

Hi Jeffrey (Zhaohui),

You comments are helpful for me to better understand how this document 
relates to the other two. But it doesn't alter my conclusions. More inline.

> zzh> This document does indeed not update RFC7117/7524, which is for VPLS/MVPN not for EVPN.

IIUC you are saying that 7117 and 7524 intend to serve similar roles, 
each for a different VPN technology, each standing alone for the VPN 
technology it addresses.

Then this document is intended to serve a similar role for EVPN.

Do I have that right?

> Zzh> However, since most of the selective/segmented tunnel procedures for EVPN are very similar to those in RFC7117/7524,  > we decided not to repeat them in this document, but to refer to 
7117/7524 with modifications pointed out.

So this document doesn't stand alone. It is highly dependent on rfc7117, 
being in effect a derivative work.

> Zzh> As explained above, the intention is to refer to existing procedures in RFC7117/7524 with modifications pointed out for EVPN selective/segmented tunnels. Those modifications are for EVPN only…

So, if revisions are ever made to rfc7117, to fix bugs or whatever, and 
those revisions are relevant to EVPN as well then it will be necessary 
to make comparable revisions to this document?

And if rfc7117 is obsoleted (replaced by a later bis) then this document 
will continue to be based on the then obsolete document.

> Zzh> All procedures in this document (including those referring to 7117/7524) are additional optional procedures that 7432 does not cover.

The relationship is very confusing.

> the fact to determine whether an implementation conforms to this document.

I stand by this statement above.

> RFC7117bis and perhaps a RFC7432bis.

OK. Now I see that a rfc7117bis isn't appropriate. Yet I think it calls 
for some sort of explicit derivative work, that is effectively a copy of 
rfc7117 with your changes applied. Perhaps it should also replace 
rfc7432 regarding EVPS.

Or, perhaps there should be a single document that provides a framework 
specifying the common aspects of VPNs, with supplementary documents for 
each VPN type that covers that covers the aspects unique to each.

IOW, I think you are weaving a tangled web and it would be helpful to 
stand back and consider how best to untangle it.

	Thanks,
	Paul

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 10 Sep 2021 12:44:08 +0000

Hi Paul,

Please see zzh2> below.

-----Original Message-----
From: Paul Kyzivat <[email-masked]>
Sent: Wednesday, September 8, 2021 11:15 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Cc: General Area Review Team <[email-masked]>
Subject: Re: Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09

Hi Jeffrey (Zhaohui),

Do I have that right?

Zzh2> Correct.

Zzh2> It does reuse the text from RFC7117 with modifications when it comes selective/segmented tunnels.

Zzh2> Only if to fix bugs in relevant 7117 text and that bug applies here as well. Other optional extensions to the relevant RFC7117 text would not require changes in this document.
Zzh2> Note that this "referring to rfc7117 text with modification pointed out" is just to avoid repeating the text that is already specified for a similar technology.
Zzh2> The alternative is to copy the same text in this document - and if there is a bug to be fixed in relevant original 7117 text, it's likely this document needs a revision, too.
Zzh2> This can be viewed as a (partial) snapshot of 7117 included in this document. If there is a 7117bis, this snapshot does not change.

Zzh2> Both VPLS and EVPN are Ethernet VPN technologies, though EVPN is the more modern/advanced, and it's less likely that there will be new development on the VPLS technology.
Zzh2> As explained above, this document having a (partial) snapshot of RFC7117 (even if becomes obsolete) is fine for practical purposes.

Zzh2> I hope it is becoming clearer with the explanations 😊

Zzh2> A developer reads this document and comes to these text:

   ...  For brevity, only changes/additions to relevant
   [RFC7117] and [RFC7524] procedures are specified, instead of
   repeating the entire procedures.  Note that these are to be applied
   to EVPN only, and not updates to [RFC7117] or [RFC7524].

Zzh2> and for example to "5.1.  Changes to Section 7.2.2 of [RFC7117]". It should be clear "exactly what must be implemented", and from that, one should be able to determine whether an implementation conforms to this document?
Zzh2> Oh yes, the title of section 5.1 should say "Changes to Section 7.2.2 of [RFC7117] *when applied to EVPN*" 😊

Zzh2> Yes it is " effectively a copy of rfc7117 with your changes applied" but *only for* the selective/segmented tunnel part. Both 7117 and 7432 cover much more than that, so this document is not a rfc7432bis either. This document defines optional extensions to 7432 - specifically selective/segmented tunnels for multicast traffic.

Zzh2> There are IP VPN and Ethernet VPN. For the latter there are VPLS and EVPN.
Zzh2> RFC6514 specifies multicast aspect for IPVPN. Some principles of RFC6514 derived into RFC7117 for VPLS, and those same principles are applicable to EVPN as well. But since both EVPN and VPLS are for Ethernet VPN, it is better to base this document on 7117 instead of 6514.
Zzh2> So, with the evolution history and IP/Ethernet differences, there is no need for another single framework document. Even if we make one, we'll still face the issues like "what if that framework document needs to be revised/obsoleted". We can also look it from another angle: RFC7117 could be viewed as that base document for multicast in Ethernet VPN, and this document is the supplementary document for EVPN.

Zzh2> We can either make a (modified) copy of RFC7117 wrt procedures for selective/segmented tunnels, or just refer to the relevant text in 7117 and point out changes. The latter is what RFC7432 did (when it comes to the default inclusive non-segmented tunnels), and I hope that after the explanation it makes sense for this document's current approach 😊

Zzh2> Thanks!
Zzh2> Jeffrey

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Sep 2021 11:47:09 -0400

Hi,

This is just a genart review, so of course you are free to disregard it. 
Just consider it to offer some thinking points brought into the 
discussion of the draft.

	Best Wishes,
	Paul