Thanks Ilango. Your response below addresses all of my comments. Anoop
On Sun, Oct 21, 2018 at 8:40 AM Ganga, Ilango S <[email protected]> wrote: > Hi Anoop, > > > > Thanks for your review and comments. Please see my responses inline. > > > > Regards, > > Ilango > > > > *From:* nvo3 [mailto:[email protected]] *On Behalf Of *Anoop Ghanwani > *Sent:* Saturday, October 13, 2018 11:54 AM > *To:* [email protected] > *Subject:* Re: [nvo3] Working Group Last Call and IPR Poll for > draft-ietf-nvo3-geneve-08.txt > > > > I have a few comments. > > > > Thanks, > > Anoop > > > > -- > > > > section 3.5 > > >>> > > Packets in which the total length of all > > options is not equal to the 'Opt Len' in the base header are > > invalid and MUST be silently dropped if received by an endpoint. > > >>> > > what if none of the options are critical and the implementation is > choosing to remove the options headers without even processing them? does > this still apply? if so, it would be good to call it out. > > > > <Ilango> The intent of this statement is for endpoints that processes the > options to drop such packets, this is not applicable for endpoints that do > not process the options. For better clarity, we will add clarifying text to > the end of sentence as follows: > > > > “invalid and MUST be silently dropped if received by an endpoint *that > processes the options*.” > > </> > > > > section 4.1 > > what is the guidance for ttl? like dscp, there is also a uniform and pipe > model for ttl. > > > > <Ilango> You bring up a good point, we will add text outlining TTL > behavior to the end of section 4.1.2 as follows: > > > > 4.1.2. DSCP, ECN *and TTL* > > <Add the following paragraph at the end of section 4.1.2 > > > Though Uniform or Pipe models could be used for TTL (or Hop Limit in case > of IPv6) handling when tunneling IP packets, Pipe model is more aligned > with network virtualization. [RFC 2003] provides guidance on handling TTL > between inner IP header and outer IP tunnels; this model is more aligned > with the Pipe model and is recommended for use with Geneve for network > virtualization applications. > > </> > > > > section 4.1.3 > > may be helpful to add a reference to rfc 8293. > > > > <Ilango> Yes, it could be useful to provide an informative reference to > 8293, to the end of section 4.1.3 as follows: > > > > “In addition, [RFC 8293] provides examples of various mechanisms that can > be used for multicast handling in network virtualization overlay > networks.” > > </> > > > > > > <Ilango> We will address the following Editorial items as appropriate to > make it consistent. > > </> > > Editorial > > - endpoint, tunnel endpoint, geneve endpoint are used interchangeably. > also endpoint and end point. suggest change all to "tunnel endpoint" which > is the only term defined. > > - in the definition of ECMP, change: > > while avoiding reordering a single stream. -> > > while avoiding reordering of packets within a flow. > > (stream is not used or defined anywhere else.) > > - transit and non-terminating are used interchangeably. suggest change to > transit which is defined. > > - section 3.5.1 > > Options or their ordering, ... -> Options, or their ordering, ... > > - section 5 > > "(VXLAN, NVGRE )" has an extra space > > - section 6.1 > > DTLs -> DTLS > > - section 6.2 > > change implementation to specification in the text below. > > >> > > Implementation of such a mechanism is beyond the scope of this > > document. > > >> > > - section 6.3 > > Authentication mechanism -> authentication mechanism > > > > > > > > *From:* Bocci, Matthew (Nokia - GB) [mailto:[email protected] > <[email protected]>] > *Sent:* Tuesday, October 9, 2018 2:08 AM > *To:* NVO3 <[email protected]> > *Cc:* [email protected] > *Subject:* Working Group Last Call and IPR Poll for > draft-ietf-nvo3-geneve-08.txt > > > > This email begins a two-week working group last call for > draft-ietf-nvo3-geneve-08.txt. > > > > Please review the draft and post any comments to the NVO3 working group > list. If you have read the latest version of the draft but have no comments > and believe it is ready for publication as a standards track RFC, please > also indicate so to the WG email list. > > > > 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. > > > > Currently there are two IPR disclosures against this document. > > > > 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. > > > > This poll will run until Friday 26th October. > > > > Regards > > > > Matthew and Sam > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
