Hi Paul,
Please see zzh2> below.
-----Original Message-----
From: Paul Kyzivat <pkyzi...@alum.mit.edu>
Sent: Wednesday, September 8, 2021 11:15 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>;
draft-ietf-bess-evpn-bum-procedure-updates....@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Re: Gen-ART Last Call review of
draft-ietf-bess-evpn-bum-procedure-updates-09
[External Email. Be cautious of content]
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.
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.
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.
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.
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?
Zzh2> Correct.
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.
Zzh2> It does reuse the text from RFC7117 with modifications when it comes
selective/segmented tunnels.
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?
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.
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?
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.
And if rfc7117 is obsoleted (replaced by a later bis) then this document
will continue to be based on the then obsolete document.
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.
In the remainder of the document I find no explicit text that appears to
normatively updates RFC7432. I find this mystifying.
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.
Zzh2> I hope it is becoming clearer with the explanations 😊
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?
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.
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.
I stand by this statement above.
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*" 😊
IMO a different style of specification is called for. Probably an
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.
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.
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.
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.
IOW, I think you are weaving a tangled web and it would be helpful to
stand back and consider how best to untangle it.
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
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
Juniper Business Use Only
