Hi Mirja, Thanks for your suggestions. We agree. Please see our responses inline.
Thanks, Ilango -----Original Message----- From: Mirja Kuehlewind <[email protected]> Sent: Monday, February 3, 2020 2:30 AM To: Ganga, Ilango S <[email protected]> Cc: The IESG <[email protected]>; [email protected]; Jesse Gross <[email protected]>; [email protected]; Matthew Bocci <[email protected]>; [email protected]; T. Sridhar <[email protected]> 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 <[email protected]> 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 <[email protected]> > Sent: Wednesday, December 4, 2019 10:14 AM > To: The IESG <[email protected]> > Cc: [email protected]; Matthew Bocci <[email protected]>; > [email protected]; [email protected]; [email protected] > 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 <[email protected]> and IETF Chair <[email protected]> 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> > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
