Re: [nvo3] Working Group Last Call and IPR Poll for draft-ietf-nvo3-geneve-08.txt

Thanks Ilango.  Your response below addresses all of my comments.

Anoop

On Sun, Oct 21, 2018 at 8:40 AM Ganga, Ilango S <ilango.s.ganga@intel.com>
wrote:

> Hi Anoop,
>
>
>
> Thanks for your review and comments. Please see my responses inline.
>
>
>
> Regards,
>
> Ilango
>
>
>
> *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Anoop Ghanwani
> *Sent:* Saturday, October 13, 2018 11:54 AM
> *To:* nvo3@ietf.org
> *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:matthew.bocci@nokia.com
> <matthew.bocci@nokia.com>]
> *Sent:* Tuesday, October 9, 2018 2:08 AM
> *To:* NVO3 <nvo3@ietf.org>
> *Cc:* draft-ietf-nvo3-geneve@ietf.org
> *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
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
>