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

[Robert Raszuk <[e-mail]>]

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

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


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...
>


​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.