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

Reply via email to