Re: [nvo3] Mirja Kühlewind's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

["Ganga, Ilango S" <[e-mail]>]

Hi Mirja,

Thanks for your suggestions. We agree. Please see our responses inline.

Thanks,
Ilango


-----Original Message-----
From: Mirja Kuehlewind <[e-mail]> 
Sent: Monday, February 3, 2020 2:30 AM
To: Ganga, Ilango S <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; Jesse Gross <[e-mail]>; [e-mail]; Matthew Bocci <[e-mail]>; [e-mail]; T. Sridhar <[e-mail]>
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

Hi Ilango,

Please see inline.


> On 2. Feb 2020, at 20:46, Ganga, Ilango S <[e-mail]> wrote:
> 
> Hello Mirja,
> 
> Thanks for your review of the document and comments. Please see below for our responses inline, enclosed within <Response> </Response>. Let us know if you are satisfied with this resolution. 
> 
> Regards,
> Ilango Ganga
> Geneve Editor
> 
> 
> -----Original Message-----
> From: Mirja Kühlewind via Datatracker <[e-mail]> 
> Sent: Wednesday, December 4, 2019 10:14 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Matthew Bocci <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Subject: Mirja Kühlewind's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-nvo3-geneve-14: Discuss
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for the really well written document that addresses all transport related question well (and thanks to David for the early TSV review!). I only have one minor process point that need to be addressed before publication:
> 
> Inline with RFC6335 the Assignee and Contact of the port entry should also be updated to IESG <[e-mail]> and IETF Chair <[e-mail]> respectively.
> 
> IG>> <Response>
> Agreed. This was brought up during the IANA review and we have requested IANA to update the Assignee and Contact information (as noted above) before publication.
> </Response>

Can you please update this information in the IANA section in the next version of the document accordingly, so I can clear my discuss.

IG> <Response> Yes, we will add a note to this effect in the next version of the document.  </Response>

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 1) One small comment/question on the editorial note in sec 4.4.1:
> "It was discussed during TSVART early review if the level of
>   requirement for maintaining tunnel MTU at the ingress has to be "MAY"
>   or "SHOULD".  The discussion concluded that it was appropriate to
>   leave this as "MAY", considering the high level of state to be
>   maintained.
> I would have preferred a SHOULD and I'm not sure I understand what state your are talking about...?
> 
> IG>> <Response>
> The “state” (in the Editorial note) refers to tracking the MTU size per tunnel link (for all links) associated with the endpoint, which could be challenging depending on the number of endpoints and how they are represented internally in the implementation. So we have sufficient text in 4.4.1 to provide guidance to the operators/implementors.
> 
> We already have text that strongly RECOMMENDs to use Path MTU discovery to prevent or minimize fragmentation. So we could rephrase the sentence to simply restate that fact as follows:
> 
> Entire first paragraph of 4.4.1 is referenced below (revised text is enclosed in quotes " ") because we proposed to revise the first sentence in response to another comment:
> 
> "It is strongly RECOMMENDED that Path MTU Discovery ([RFC1191],
>   [RFC8201]) be used to prevent or minimize fragmentation.”
>   The use of Path MTU Discovery on the transit network provides the
>   encapsulating tunnel endpoint with soft-state about the link that it
>   may use to prevent or minimize fragmentation depending on its role in
>   the virtualized network. "The NVE can maintain this state (the MTU size of
>   the tunnel link(s) associated with the tunnel endpoint), so if a
>   tenant system sends large packets that when encapsulated exceed the
>   MTU size of the tunnel link, the tunnel endpoint can discard such
>   packets and send exception messages to the tenant system(s)."  If the
>   tunnel endpoint is associated with a routing or forwarding function
>   and/or has the capability to send ICMP messages, the encapsulating
>   tunnel endpoint MAY send ICMP fragmentation needed [RFC0792] or
>   Packet Too Big [RFC4443] messages to the tenant system(s). "When determining the MTU size of a tunnel link, 
>   maximum length of options should be considered as options may vary on a per-packet basis".
> 
> </Response>

Looks good to me. See below for the last sentence.

> 
> 2) And one more small question on sec 4.4.1. in general:
> Is the assumption that all tunnel packets have the same options (and therefore same Geneve header length) at a certain ingress, or should the announced MTU always consider the maximum length that a certain ingress could produce. Would be good to clarify this in the document!
> 
> IG>> <Response>  The options could vary on a per packet basis. We will add a sentence at the end of the first paragraph in 4.4.1 to clarify this point:
> “When determining the MTU size of a tunnel link, maximum length of options should be considered as options may vary on a per-packet basis.”

I’m not sure about the phase “should be considered” as it seem quite vague. How about “MUST be assumed” instead? Maybe that makes it more clear…?

IG> <Response> Yes, we will revise the text as follows:
“When determining the MTU size of a tunnel link, maximum length of options MUST be assumed as options may vary on a per-packet basis.”


> 
> The entire paragraph is reproduced above for reference. 
> </Response>
> 
> 3) Section 6:
> "When crossing an untrusted link, such as the public Internet, IPsec
>   [RFC4301] may be used to provide authentication and/or encryption of
>   the IP packets formed as part of Geneve encapsulation."
> Should this maybe be a normative SHOULD and not a lower case "may"?
> 
> IG>> <Response> We already have this requirement in section 6.1.1.  We can rephrase the sentence as follows to provide reference to the requirement in 6.6.1.
> 
> OLD:
> When crossing an untrusted link, such as the public Internet, IPsec
>   [RFC4301] may be used to provide authentication and/or encryption of
>   the IP packets formed as part of Geneve encapsulation.
> 
> NEW:
> “When crossing an untrusted link, such as the public Internet, VPN technologies such as IPsec
>   [RFC4301] should be used to provide authentication and/or encryption of
>   the IP packets formed as part of Geneve encapsulation (See section 6.1.1).”
> </Response>

Okay.

> 
> 3) And one random thought on the protocol design (given we all love to design protocols :-) ): Was it considered to require to have critical options first in order to speed up processing?
> 
> IG>> <Response> 
> There were quite a few discussions in the working group and the NVO3 design team around imposing ordering requirements on options. However, given that Geneve is intended to be a flexible and general purpose protocol, it seemed clear that there wasn't one ordering that would satisfy all the needs. However, certain use cases could order options in a particular way as an optimization and still be compatible with the protocol, and this can be managed by the control plane. The recommendation from the NVO3 design team is to let the control plane negotiate the ordering.  See section 4.5.1 that provides text to this effect.  
> </Response>

Okay, thanks!

Mirja

> 
> <End of Responses>
> 
>