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

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]
Sent: Tuesday, October 9, 2018 2:08 AM
To: NVO3 <nvo3@ietf.org<mailto:nvo3@ietf.org>>
Cc: draft-ietf-nvo3-geneve@ietf.org<mailto: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<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3