I have reviewed the doc and have the following comments. Anoop
== authors: Jorge is listed as working at Juniper but with a Nokia address. :) Throughout the document: Mixed use of GENEVE and Geneve. Suggest making it consistent (should be Geneve per the Geneve draft). There are also several occurrences of GENVE. (A typo.) pg 1, abstract >> EVPN control plane can also be used by a Network Virtualization Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in transmission and/or reception of Geneve encapsulated data packets. >> to >> EVPN control plane can also be used by Network Virtualization Edges (NVEs) to express Geneve tunnel option TLV(s) supported in the transmission and/or reception of Geneve encapsulated data packets. >> (remove 'a', Endpoints -> Edges, add missing space after TLV(s), add 'the' before transmission) sec 1, pg 2 >> The NVO3 working group have been working on different dataplane encapsulations. The Generic Network Virtualizationi Encapsulation [I-D.ietf-nvo3-geneve <https://tools.ietf.org/html/draft-ietf-bess-evpn-geneve-01#ref-I-D.ietf-nvo3-geneve>] have been recently recommended to be the proposed standard for network virtualization overlay encapsulation. >> to >> The NVO3 working group has evaluated different dataplane encapsulations. The Generic Network Virtualization Encapsulation [I-D.ietf-nvo3-geneve <https://tools.ietf.org/html/draft-ietf-bess-evpn-geneve-01#ref-I-D.ietf-nvo3-geneve>] has been recently recommended to be the proposed standard for NVO3 encapsulation. >> (fixed typos and grammar.) control plane determines -> control plane determine pg 3 Network Virtualization Edge devices (NVEs) -> Network Virtualization Edges (NVEs) >> This EVPN control plane extension will allow a Network Virtualization Edge (NVE) to express what Geneve option TLV types it is capable to receive or to send over the Geneve tunnel to its peers. >> to >> This EVPN control plane extension will allow an NVE to express what Geneve option TLV types it is capable of receiving from, or sending to, over the Geneve tunnel with its peers. >> sec 3 seems to be a mix of abbreviations and terminology. Would adjust the title to cover both or split in 2 sections, one for each. sec 3, pg 3 NVO3 Network Virtualization Overlays over Layer 3 -> NVO3: Network Virtualization Overlays over Layer 3. pg 4. >>> 4 <https://tools.ietf.org/html/draft-ietf-bess-evpn-geneve-01#section-4>. GENEVE extensions This document adds some extensions to the [I-D.ietf-nvo3-geneve <https://tools.ietf.org/html/draft-ietf-bess-evpn-geneve-01#ref-I-D.ietf-nvo3-geneve>] encapsulation that are relevant to the operation of EVPN. 4.1 <https://tools.ietf.org/html/draft-ietf-bess-evpn-geneve-01#section-4.1>. Ethernet option TLV >>> If there is only 1 extension, then I would say "document adds an extension...". pg 4 For GENVE encapsulation we need a bit to for this purpose. -> For Geneve, we need to add a bit for this purpose. pg5 >> Where: - Option Class is set to Ethernet (new Option Class requested to IANA) - Type is set to EVPN-OPTION (new type requested to IANA) and C bit must be set. - B bit is set to 1 for BUM traffic. - L bit is set to 1 for Leaf-Indication. - Source-ID is a 24-bit value that encodes the ESI-label value signaled on the EVPN Autodiscovery per-ES routes, as described in [RFC7432 <https://tools.ietf.org/html/rfc7432>] for multi-homing and [RFC8317 <https://tools.ietf.org/html/rfc8317>] for leaf-to-leaf BUM filtering. The ESI-label value is encoded in the high-order 20 bits of the Source-ESI field. >> This could benefit from some formatting. Very hard to read, as is. R bit is not defined. EVPN-OPTION appears to be missing from IANA section. "Local- bias" -> "Local-bias ESI- labels -> ESI-labels (extra space) >> The egress NVEs that make use of ESIs in the data path (because they have a local multi-homed ES or support [RFC8317 <https://tools.ietf.org/html/rfc8317>] >> Missing a closing parenthesis. >>> The use of the B bit is only relevant to GENEVE packets with Protocol Type 0x6558 (Bridged Ethernet). >>> The entire option is relevant only for bridged ethernet, right? What should an implementation do if it receives a packet where this is in conflict? pg 6 >>> Where, an NVE receiving the above sub-TLV, will send GENEVE packets to the originator NVE with with only the option TLVs the receiver NVE is capable of receiving, and following the same order. >>> This statement could be made clearer. I think it's combining control plane and data plane when describing originator or receiver. Also, there are 2 "withs". >>> Also the high order bit in the type, is the critical bit, MUST be set accordingly. >>> Please elaborate on what "set accordingly" means. Use appropriate reference to Geneve doc if needed. >>> In the datapath, NVE2, NVE3 and NVE4 only encapsulate overlay packets with the Geneve option TLV(s) that NVE1 is capable of receiving. >>> to >>> In the datapath, NVE2, NVE3 and NVE4 may only encapsulate overlay packets with the Geneve option TLV(s) that NVE1 is capable of receiving, and in case more than one option TLV is being used, they must be in the order specified by NVE1. >>> sec 7 >> Security considerations described in [RFC7432 <https://tools.ietf.org/html/rfc7432>] and in [I-D.ietf-bess-evpn-overlay <https://tools.ietf.org/html/draft-ietf-bess-evpn-geneve-01#ref-I-D.ietf-bess-evpn-overlay>] are equally applicable. >> Also security considerations in the Geneve doc especially since securing options in Geneve has been a tricky topic. On Mon, Jul 13, 2020 at 4:46 AM <[email protected]> wrote: > Hello WG, > > > > This email starts a two weeks Working Group Last Call on > draft-ietf-bess-evpn-geneve-01 [1]. > > > > This poll runs until * the 27th Of July *. > > > > We are also polling for knowledge of any undisclosed IPR that applies to > this Document, to ensure that IPR has been disclosed in compliance with > IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as an Author or a Contributor of this Document please > respond to this email and indicate whether or not you are aware of any > relevant undisclosed IPR. The Document won't progress without answers from > all the Authors and Contributors. > > There is currently no IPR disclosed. > > > > If you are not listed as an Author or a Contributor, then please > explicitly respond only if you are aware of any IPR that has not yet been > disclosed in conformance with IETF rules. > > > > We are also polling for any existing implementation as per [2]. > > > > Thank you, > > Stephane & Matthew > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-geneve/ > > [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
