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 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.
- Section 5.1.2.1 should cover how 4 byte ASes are to be handled
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.
- Some terms are used without references on their first use.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
