Hi Alvaro, I took care of your remaining comments and published rev10 of the document just now. For more details please see my replies inline.
Cheers, Ali From: Alvaro Retana <aretana.i...@gmail.com> Date: Thursday, December 7, 2017 at 6:07 AM To: "bess-cha...@ietf.org" <bess-cha...@ietf.org>, Cisco Employee <saja...@cisco.com> Cc: Thomas Morin <thomas.mo...@orange.com>, "bess@ietf.org" <bess@ietf.org> Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08 On December 5, 2017 at 10:53:02 PM, Ali Sajassi (sajassi) (saja...@cisco.com<mailto:saja...@cisco.com>) 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. [Ali2] Done. 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? [Ali2] Yes, I modified it to the following: “…it is recommended that the GRE key field be present and be used to provide a 32-bit entropy value only if the P nodes can perform ECMP hashing based on the GRE key; otherwise, the GRE header should not include the GRE key.” ... 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. [Ali2] Got rid off rfc5512 and moved the idr-tunnel-encap to normative. 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. [Ali2] Done.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
