RE: RtgDir review: draft-ietf-nvo3-geneve-14

["Ganga, Ilango S" <ilango.s.ganga@xxxxxxxxx>]

Hello Tal,

 

Thanks for your detailed review and suggestions. Please see below for our responses in-line below, enclosed within <Response> </Response>. Let us know if you are satisfied with this resolution.

 

Regards,                          

Ilango Ganga

Geneve Editor

 

 

From: Tal Mizrahi <tal.mizrahi.phd@xxxxxxxxx>
Sent: Thursday, November 28, 2019 5:59 AM
To: rtg-ads@xxxxxxxx
Cc: rtg-dir@xxxxxxxx; draft-ietf-nvo3-geneve@xxxxxxxx; NVO3 <nvo3@xxxxxxxx>; nvo3-chairs@xxxxxxxx; IETF <ietf@xxxxxxxx>
Subject: RtgDir review: draft-ietf-nvo3-geneve-14

 

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-nvo3-geneve-14
Reviewer: Tal Mizrahi
Review Date: 28-Nov-2019
Intended Status: Standards Track


Summary:
========
I have some minor concerns about this document that I think should be resolved before publication.


Comments:
=========

The draft is clear and well-written. 

Specific comments are provided below.

Section 2.2:
"The presence of a Geneve variable length header SHOULD NOT prevent the tunnel endpoints and transit devices from using such offload capabilities." - this is purely an implementation consideration, and uppercase requirement language is not appropriate.

 

IG> <Response> The previous statement says that tunnel endpoints MAY use offload capabilities and the subsequent statement states that presence of the variable length header SHOULD NOT prevent tunnel end points from using such offload capabilities. So we believe it is an appropriate use of normative statement here; even though it is an implementation consideration, it provides guidance to implementors to ensure the correct use of Geneve variable length options. If you still see this as an issue, we could lower the case to “should not” in this sentence.

</Response>

Section 3.4:
  "Transit devices MUST maintain consistent forwarding behavior
   irrespective of the value of 'Opt Len', including ECMP link
   selection.  These devices SHOULD be able to forward packets
   containing options without resorting to a slow path."
The first sentence makes sense, but the second sentence is implementation-specific. Given the first sentence, I would recommend to remove the second sentence.

 

IG> <Response> It is useful to have an informational statement to provide guidance. So change sentence as follows.

“These devices are expected to forward packets containing options without resorting to slow path.”

</Response”>

Section 3.5:
OLD:
for standardized and experimental options
NEW:
for allocated and for experimental options
Explanation:
the word "standardized" is misleading, because the document is requesting an "IETF Review" allocation policy.

 

IG> <Response>. Agreed. We will change the text as follows: 

“IANA will be requested to reserve specific ranges for allocation by IETF Review and for Experimental Use (See Section 7)”. 

</Response>

Section 3.5.1:
I could not find a specification of what a receiving endpoint should do if the total length of the Geneve header + options exceeds its processing depth. Drop? Notify the peer tunnel endpoint?

 

IG> <Response> We propose the following to address this point:

Add the following statement to 3.5.1 at the end of section “some requirements are imposed on options and devices that process them:”

“If a tunnel end point receives a Geneve packet with ‘Opt Len’ (total length of all options) that exceeds the options processing capability of the tunnel endpoint then the tunnel end point MUST drop such packets. An implementation may raise an exception to the control plane of such an event. It is the responsibility of the control plane to ensure the communicating peer tunnel end points have the processing capability to handle the total length of options. Specification of control plane mechanisms is beyond the scope of this document.“

</Response>

Section 4.2:
"Geneve MUST be used with congestion controlled traffic or within a network that is traffic managed to avoid congestion (TMCE)" - the MUST does not seem appropriate. It is up to the operator whether congestion control is required or not.

 

IG> <Response> Section 4.2 requirements are based on the resolution to the TSVART early review.  This is consistent with congestion considerations for design and use with UDP tunnels in RFC 8085 and RFC 8086.             

</Response>

Section 4.6:
This section should be rephrased. This section currently defines how hardware offloading in NICs should be implemented, including MUST requirements. A network protocol should not define requirements for specific implementation approaches. Instead, the section should describe what is expected from ANY intermediate node in the network (switch, router, or hardware component along the path) to do or not do (for example not to change the order of Geneve options).

 

IG> <Response> It is common for network virtualization tunnel end points to be implemented in Servers with NICs. As stated in this section, there is no requirement that a given implementation employ such offloads;  however,  if an implementation chooses to do so, this section describes the rules so it does not affect the intended operation of the tunnel end point. Also the expectations of forwarding elements like switches and routers (transit devices) is already described in other sections of this document. 

</Response>

Section 5:
- I suggest to remove this section, or to significantly revise it. As opposed to its title, it does not discuss interoperability, but migration from other tunnel protocols to Geneve.
- The following sentences are inaccurate: "Geneve does not introduce any interoperability issues as it appears to most devices as UDP packets.", and "Geneve is a superset of the functionality of the most common protocols used for network virtualization (VXLAN,NVGRE)"
- It appears that removing this section would not remove significant information.  

 

IG> <Response> We think it is useful to have this informational section on transition. So we propose few modifications as noted below:

Change the title to “Section 5: Transition considerations”. 

In addition modify the following sentences:

Change to:

“Geneve is compatible with existing IP networks as it appears to most devices as UDP packets."

Change to:

“Geneve builds on the base data plane functionality provided by the most common protocols used for network virtualization (VXLAN,NVGRE)"

</Response>

Section 7:
OLD:
are to be reserved for standardized options for allocation by IETF Review
NEW:
are to be assigned by the IETF Review policy
Explanation:
This sentence is confusing, since "Standards Action" and "IETF Review" are two different IANA policies.

 

IG> <Response> Agreed. We will change the sentence as suggested,

“are to be assigned by the IETF Review policy”

</Response>

Section 1:
Currently section 1.1 starts a whole page after section 1 starts. I suggest to separate the Requirement Language and the Terminology from the Introduction (two different sections).

 

IG> <Response> We don’t see an issue with current formatting of Section 1. Other RFCs follow similar format. Example RFC 8086, RFC 8300.

</Response>

References:
IEEE.802.1Q_2014 is not the latest version of 802.1Q.

 

IG> <Response> We will change the reference to the latest version:  IEEE Std 802.1Q-2018.

</Response>

 

 

Cheers,

Tal Mizrahi.