Re: [bess] Warren Kumari's No Objection on draft-ietf-bess-evpn-vpws-13: (with COMMENT)

Hi Warren,

In the draft you have reviewed EVPN term is use interchangeably with term
[RFC7432] which in turn is also already listed and defined in the Normative
References section (2nd from the top).

Personally if you assume that the reader of this document is not familiar
with EVPN I would also recommend to read few other L2 VPN related documents
as prerequisite before jumping to this one:

- RFC 7209 and all VPN related documents included in its references

- RFC 7432 and all VPN related documents included in its references

- all VPN related documents included in references of
draft-ietf-bess-evpn-vpws

- only then the draft in question itself.

Kind regards,
Robert.

On Sun, May 7, 2017 at 7:05 PM, Warren Kumari <warren@kumari.net> wrote:

> Warren Kumari has entered the following ballot position for
> draft-ietf-bess-evpn-vpws-13: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> [ For -11 / -12 ]
> This document is very heavy on the acronyms, and could do with some
> expanding of these -- for example, the document starts out with "This
> document describes how EVPN can be used...". I'm no MPLS VPN person, so
> much time was spent searching to try figure out what everything meant.
>
> I also agree with Spencer's "In multihoming scenarios, both B and P flags
> MUST NOT be both set. " being hard to parse, and disagree with Acee that
> is it clear.
>
> [ For -13 ]
> The draft was revised to address Alia's DISCUSS, and also Spencer's
> "traditional way" and "both B and P flags MUST NOT be both set" comment,
> but still does not expand EVPN; I also agree with Spencer that it would
> be helpful to expand P2P on first use.  I reread the document and have
> some additional comments - note that these are are only comments, but I
> think that they would make the document more readable...
>
> 1: Introduction:
> "that in EVPN terminology would mean a single pair of Ethernet Segments
> ES(es)." - I'm confused by the 'ES(es)' - guessing this was an editing
> failure and 'Ethernet Segments (ES)' was intended? If not,
>
> You use both "Ethernet AD" and "Ethernet A-D" - please choose and stick
> with one.
>
> 1.1: Terminology:
> "EVI: EVPN Instance." --  Ok, but EVPN is still not defined /
> referenced.
>
> 3.1  EVPN Layer 2 attributes extended community
> " A PE that receives an update with both B and P flags set MUST treat
> the
>  route as a withdrawal. If the PE receives a route with both B and P
>  clear, it MUST treat the route as a withdrawal from the sender PE."
> Do the above 2 sentences say the same thing? It sure sounds like
> repetition, if not, please explain the difference. If not, removing one
> would make this less confusing.
>
> Figure 3: EVPN-VPWS Deployment Model
> You use the terms / labels "PSN1", "PSN2" - what are these? "Provider
> <something> Network"?
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>