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

From: Warren Kumari <[email-masked]>
Date: Sun, 07 May 2017 10:05:35 -0700

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"?

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 7 May 2017 19:35:16 +0200

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 <[email-masked]> wrote:

> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Warren Kumari <[email-masked]>
Date: Sun, 07 May 2017 19:43:12 +0000

> References section (2nd from the top).

Yes, and I  read RFC7432 when I first reviewed this document - but I only
knew that was the one to read after grepping though RFCs for "EVPN" -- is
there any reason for the authirs *not* to make things easier for your
readers by saying: "
This document describes how EVPN [RFC7432] can be ..."?

> draft-ietf-bess-evpn-vpws

That sounds like a fine idea - perhaps the authors should add something
like "Readers of this document are expected to be familiar with RFC7209 and
RFC7432."
Mainly I don't understand why we wouldn't want to make it easier for
someone new to the technology...

W

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 7 May 2017 22:05:32 +0200

> is there any reason for the authirs *not* to make things easier for your
> readers by saying: "

​That clearly is a good edit suggestion for all alone occurrences of
[RFC7432] in the draft. ​

> someone new to the technology...

​I think in number of IETF drafts extending existing specifications there
is an implicit assumption that the reader is ​familiar with the base spec
or specs around it related to new work. IMHO normative or informative
references is a good place for it. So Adding RFC7209 to the latter may be
indeed helpful.

- - -

Regarding the draft itself my personal comment is that just like other
specs defining VPWS service this proposal also fails to include OEM section
describing or even defining tools which will allow user of such emulated
circuit to get all errors (or even MTU fluctuations) from the underlay it
traverses to be exposed and reported to the wire/circuit end points.

Being on the enterprise side which uses such circuits I can only see now
that there is huge missing gap between providing spec to construct given
service and the perspective of actual use of such emulated wires
established over third party IP or IP/MPLS networks.

IMO OEM NNI between those two planes should be made mandatory in all specs.

Kind regards,
//Robert.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 May 2017 13:53:24 -0700

On Sun, May 7, 2017 at 1:05 PM, Robert Raszuk <[email-masked]> wrote:

> or specs around it related to new work.
>

I'm sure this is true, but as someone who reads a lot of specs, this one is
unusually
reader-unfriendly to someone who is being asked to pick it up and review
it. It's
not unreasonable to expect that:

1. Acronyms be expanded on first use.
2. Terms of art come with citations to where they are defined.

-Ekr

---

From: John Scudder <[email-masked]>
Date: Sun, 7 May 2017 22:55:27 +0000

On May 7, 2017, at 4:53 PM, Eric Rescorla <[email-masked]> wrote:
> It's

All the more so since the RFC Editor will insist on this anyway.

--John