Re: [RTG-DIR] RtgDir review: draft-ietf-bess-evpn-overlay-10

["Ali Sajassi (sajassi)" <[e-mail]>]

Lou,

Thanks for your comments. Please refer my responses inline.

On 1/9/18, 3:37 PM, "Lou Berger" <[e-mail]> wrote:

    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-bess-evpn-overlay-10.txt
    Reviewer: Lou Berger
    Review Date: Jan 9, 2018
    IETF LC End Date: date-if-known
    Intended Status: Standards Track
    
    Summary:
    
    I have some minor concerns about this document that I think should be 
    resolved before publication.
    
    Comments:
    
    To me the document reads more like an applicability statement than a 
    PS.  I think a few things can and should be done to the document to 
    clean this up.  Some are trivial, some may take more thought.  The core 
    issues are related to (a) detecting/handling configuration mismatches 
    and (b) definition of support for multiple encapsulation types.  I 
    suspect all raised issues can be addressed via documentation changes.
    
    Major Issues:
    
    
    Minor Issues:
    
    - The document defines a number of deployment options that are not 
    compatible, e.g., section 5.1.2 options 1 and 2, or allowing for 
    "locally configured encapsulation".  It would be good  if the document 
    should explain how such mismatches can be detected by an implementation 
    or in operation and addressed.  If an option can be eliminated, such as 
    configured encapsulation, this should be considered.
    
The options are the same as in RFC7432 and thus handling of one or both are the same as in RFC7432. I have changed the paragraph to mention that these options are the same as RFC 7432 (except for the fact that broadcast domains are presented by VNIs instead of VIDs):

“When the EVPN control plane is used in conjunction with VXLAN (or NVGRE encapsulation), just like [RFC7432] where two options existed for mapping broadcast domains (represented by VLAN IDs) to an EVI, in here there are also two options for mapping broadcast domains represented by VXLAN VNIs (or NVGRE VSIDs) to an EVI:”

    - The approach taken in the document is clearly applicable to multiple 
    tunneling technologies, and mentioning this is certainly appropriate, 
    but the document leaves some aspects unsaid (and open to interpretation) 
    for encapsulations other than VXLAN.  The scope of the document states 
    that vxlan, nvgre and MPLSoGRE encapsulation are fully supported by the 
    document, but full specification seems to only be present for the 
    first.  For example, section 5.1 references multiple encapsulation 
    technologies, but only defines mechanisms relative to VXLAN (VNIs).  
    Adding specific procedures for each encapsulation type would make the 
    required mechanisms unambiguous, but this is certainly not the only way 
    to ensure each is fully documented and multiple independent 
  interoperable implementations will be possible.

With regard to NVGRE and MPLS over GRE encaps, the last sentence of the 1st paragraph in section 5.1 covers the NVGRE encap (as below), and section 5.2 covers MPLS over GRE encap:
“In the remainder of this document we use VNI as the representation for NVO instance with the understanding that VSID can equally be used if the encapsulation is NVGRE unless it is stated otherwise.”

    
  - Section 5.1.2.1 should cover how 4 byte ASes are to be handled

The last paragraph of section 5.1.2.1 already covers it:

“It should be noted that RT auto-derivation is applicable for 2-octet AS numbers. For 4-octet AS numbers, RT needs to be manually configured since 3-octet VNI fields cannot be fit within 2-octet local administrator field.”
    
    Nits:
    
    - Lowercase "should" is used in a some places where it looks like 
    "SHOULD" be used.  In general it appears that lowercase was used when 
    referring to requirements defined in other documents.  Upper case is 
    still appropriate in such cases.
    
updated two instances as they were appropriate.

  - Some terms are used without references on their first use.

Expanded those terms in their first usage.

Cheers,
Ali