Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

[Alvaro Retana <[e-mail]>]

On December 5, 2017 at 10:53:02 PM, Ali Sajassi (sajassi) ([e-mail])
wrote:

Ali:

Hi!

Thanks for the review. Please refer to my replies to your comments marked
with [Ali] inline. I have incorporated them in rev09 of the draft that has
just been published. Please let me know if you have any other comments.

The only significant issues left are about the references (see below).

I need the Normative references to be in place so I can start the IETF LC
(and can point them out there).  As soon as you post an update I’ll start
the LC.

Thanks!

Alvaro.



...

M3. From 5.2 (MPLS over GRE):



M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD
be present, and SHOULD be used to provide a 32-bit entropy field.”  What
are the cases when it is ok not to include the field, or use it for that
purpose?  IOW, why are these SHOULDs not MUSTs?  Or maybe, when is the key
field needed?



[Ali] The reason it is a “SHOULD” because, the MPLS over GRE encap still
works without the key field set to the entropy value; however, if that’s
done, then ECMP won’t work well in the network. Also, the core routers in
the network may not support ECMP based on GRE key and that’s another reason
for “SHOULD”.

Can you include something along those lines?


...

M8. References



M8.1. TUNNEL-ENCAP (aka draft-ietf-idr-tunnel-encaps) should be Normative,
which btw is marked to Obsolete rfc5512; I mention this because both are
listed in several parts, so you should take rfc5512 out.



[Ali] Please refer to Thomas explanation on this which is copied here for
your convenience:

“This was debated on a while ago, and this is somehow the conclusion of

the discussion:



https://mailarchive.ietf.org/arch/msg/bess/z1J2VD9rtCQC7NHnmi_4tz_bR_w



Copy-paste:

----

We'll also add idr-tunnel-encaps a Informative reference. With respect

to Tunnel Encap Extended Community (which is the only part of

idr-tunnel-encap used by evpn-overlay draft), idr-tunel-encap draft

itself references RFC 5512.



During the course of WG LC and RFC editorship of evpn-overlay draft, if

we see that idr-tunnel-encap is progressing fast, then we can drop the

reference to RFC 5512 and make the reference to idr-tunnel-encap

Normative. Otherwise, we'll keep both references with RFC 5512 as

Normative and idr-tunnel-encap as Informative.

----



The question probably is whether or not idr-tunnel-encap progress is

sufficient.”

As I replied back:

If anything, both references should at least be of the same type: I can see
no reasoning why one would be Normative and the other Informative.

In this case, idr-tunnel-encap already went through WGLC (according to the
datatracker) — we can’t ignore the fact that idr has consensus on
deprecating rfc5512.  Again, we don’t need both references.


M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, RFC4023



[Ali] Please refer to Thomas explanation on this which is copied here for
your convenience:

“My process fu is weakening, but if this specification is standard track

(and I believe it should be), I believe it can't normatively depend on

Informative specs and some of the above are in this category.”

My reply:

It can if we call the Down References out in the IETF Last Call and no one
opposes.  I think we already processed at least one document with a DownRef
toVXLAN, so I don’t think that’s a problem.

In any case, the type of Reference should be decided based on the real
dependency of the document, not on its status.