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

[Paul Kyzivat <[e-mail]>]

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

On 9/10/21 8:44 AM, Jeffrey (Zhaohui) Zhang wrote:
> Hi Paul,
> 
> Please see zzh2> below.
> 
> -----Original Message-----
> From: Paul Kyzivat <[e-mail]>
> Sent: Wednesday, September 8, 2021 11:15 AM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]
> Cc: General Area Review Team <[e-mail]>
> 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
>