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?
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.
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?
And if rfc7117 is obsoleted (replaced by a later bis) then this document
will continue to be based on the then obsolete document.
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.
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.
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.
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
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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
