A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)
draft-ietf-bess-evpn-overlay-12

The IPR declaration came through [1] and the WG was notified [2].  Except for pointing out that the disclosure lacked information about the terms, there were no other concerns.

[1] https://datatracker.ietf.org/ipr/3131/
[2] https://mailarchive.ietf.org/arch/msg/bess/vkpsarTPSDYOyeQ7MX5W_nhceEo/?qid=2921d21cd0c8fd1f7393f2011dddae96

During IESG Review, I was advised of a forthcoming IPR declaration.  I think the document is ready pending that declaration and time for the WG to consider it.

[Ballot comment]
Please expand the following acronyms upon first use; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- VXLAN
- NVGRE
- POD
- GRE - Generic Routing Encapsulation
- GENEVE
- NV
- ARP - Address Resolution Protocol
- RR - Resource Record
- ECMP - Equal-Cost Multipath
- PIM-SM - Protocol Independent Multicast
- PIM-SSM
- BIDIR-PIM
- IP-VRF
- LSP - Label Switched Path
- iBGP

Also, please be consistent about capitalization of "ToR" versus "TOR", "VxLAN" versus "VXLAN", and "NvGRE" versus "NVGRE".

[Ballot comment]
Please expand the following acronyms upon first use; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- VXLAN
- NVGRE
- POD
- GRE - Generic Routing Encapsulation
- GENEVE
- NV
- ARP - Address Resolution Protocol
- RR - Resource Record
- TOR
- ECMP - Equal-Cost Multipath
- PIM-SM - Protocol Independent Multicast
- PIM-SSM
- BIDIR-PIM
- IP-VRF
- LSP - Label Switched Path
- iBGP

[Ballot comment]
Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- VXLAN
- NVGRE
- GRE - Generic Routing Encapsulation
- GENEVE
- NV
- ARP - Address Resolution Protocol
- RR - Resource Record
- TOR
- ECMP - Equal-Cost Multipath
- PIM-SM - Protocol Independent Multicast
- PIM-SSM
- BIDIR-PIM
- IP-VRF
- LSP - Label Switched Path
- iBGP

[Ballot comment]
I prefer the comments about Geneve being left in the draft.
The other 2 encapsulations are ISE.  Geneve will be the Standards
Track encapsulation - so I find the framing useful.

[Ballot comment]
Both the Abstract and Introduction contain text like this:

  This specification is also applicable to GENEVE encapsulation;
  however, some incremental work is required which will be covered in a
  separate document.

and the Introduction references draft-boutros-bess-evpn-geneve-00.txt, which looks like an individual -00 draft. I wonder if it would be better to drop the promise from this document, and make the relationship clear in whatever version of draft-boutros-bess-evpn-geneve is published.

I'm fine with the working group publishing this draft with the promise included, but wanted to ask while we're reviewing it, rather than later.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Standard Track, as properly indicated on title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how Ethernet VPN (EVPN) [RFC7432] can be used
  as an Network Virtualization Overlay (NVO) solution and explores the
  various tunnel encapsulation options over IP  and their impact on the
  EVPN control-plane and procedures. In particular, the following
  encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.

Working Group Summary

  There was very large support for adopting this work.
  Nothing else particular worth highlighting.

Document Quality

  This specification is of very good technical quality and  are
  known to have multiple interoperable specifications.

Personnel

  Thomas Morin is the Document Shepherd.
  Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has done a thorough review that lead to a few
editorial fixes or improvements. The doc is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The shepherd believe that a document of such importance (given implementations
and deployments) could have ideally benefited from more in-depth reviews outside
the co-authors group, but will not raise this as a too serious issue since the
specification is known to have multiple interoperable implementations.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors confirmed that.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No disclosure made.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Very large consensus in the group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

All nits have been addressed in -08.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All clear.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Yes, normative references are made towards the following Informational
documents:
- RFC 7348
- RFC 7637

There is also a Normative reference to draft-ietf-nvo3-vxlan-gpe, but the authors
plan to replace it by an Informative reference in version -11.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change in existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section merely documents codepoints used
by these specs but not allocated in the context of the publication
of these specs.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-bess-evpn-overlay-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP Tunnel Encapsulation Attribute Tunnel Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the following, existing registrations will have their references changed to [ RFC-to-be ]:

Value Name
----------+-----------------------------
8 VXLAN Encapsulation
9 NVGRE Encapsulation
10 MPLS Encapsulation
11 MPLS in GRE Encapsulation
12 VXLAN GPE Encapsulation

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-12-22):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-bess-evpn-overlay@ietf.org, Thomas Morin , thomas.morin@orange.com, bess-chairs@ietf.org, bess@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Network Virtualization Overlay Solution using EVPN) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'A Network Virtualization Overlay Solution
using EVPN'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-12-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies how Ethernet VPN (EVPN) can be used as a
  Network Virtualization Overlay (NVO) solution and explores the
  various tunnel encapsulation options over IP  and their impact on the
  EVPN control-plane and procedures. In particular, the following
  encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.
  This specification is also applicable to GENEVE encapsulation;
  however, some incremental work is required which will be covered in a
  separate document. This document also specifies new multi-homing
  procedures for split-horizon filtering and mass-withdraw. It also
  specifies EVPN route constructions for VxLAN/NvGRE encapsulations and
  ASBR procedures for multi-homing NV Edge devices.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-overlay/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7637: NVGRE: Network Virtualization Using Generic Routing Encapsulation (Informational - Independent Submission Editor stream)
    draft-ietf-idr-tunnel-encaps: The BGP Tunnel Encapsulation Attribute (None - IETF stream)
    rfc7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks (Informational - Independent Submission Editor stream)
    draft-ietf-nvo3-vxlan-gpe: Generic Protocol Extension for VXLAN (None - IETF stream)

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Standard Track, as properly indicated on title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how Ethernet VPN (EVPN) [RFC7432] can be used
  as an Network Virtualization Overlay (NVO) solution and explores the
  various tunnel encapsulation options over IP  and their impact on the
  EVPN control-plane and procedures. In particular, the following
  encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.

Working Group Summary

  There was very large support for adopting this work.
  Nothing else particular worth highlighting.

Document Quality

  This specification is of very good technical quality and  are
  known to have multiple interoperable specifications.

Personnel

  Thomas Morin is the Document Shepherd.
  Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has done a thorough review that lead to a few
editorial fixes or improvements. The doc is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The shepherd believe that a document of such importance (given implementations
and deployments) could have ideally benefited from more in-depth reviews outside
the co-authors group, but will not raise this as a too serious issue since the
specification is known to have multiple interoperable implementations.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors confirmed that.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No disclosure made.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Very large consensus in the group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

All nits have been addressed in -08.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All clear.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Yes, normative references are made towards the following Informational
documents:
- RFC 7348
- RFC 7637
- draft-ietf-nvo3-vxlan-gpe

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change in existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section merely documents codepoints used
by these specs but not allocated in the context of the publication
of these specs.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

=== AD Review of draft-ietf-bess-evpn-overlay-08 ===
https://mailarchive.ietf.org/arch/msg/bess/9x_rgwqxQYVXVGjC94YdIVBB9jk/?qid=1c63f54be1adbb67998e32918798cc1b

Dear Authors:

I just finished reading this document (finally!).  I have a some comments (see below) which I think should be easy to address.

I also have some bigger issues that we’ll need the Chairs’ help to solve:

(1) Coordination with nv03

For the Chairs:  Except for some clarification comments [1] related to the current version, I see no other traffic in the nvo3 list related to this document.  Was there some other coordination that I’m missing?  I am not questioning having this document in bess (that’s perfectly fine); I’m just raising the needed coordination with other WGs, from the Charter: "The working group will also coordinate with...NVO3 working group for coordination of protocols to support data center VPNs.”

What about Geneve (draft-ietf-nvo3-geneve)?  The nvo3 WG is focusing on Geneve as the Standard encapsulation, but this document doesn’t even mention it.


(2) Document Status

Why is this a Standards Track document?  The Abstract/Introduction say that “this document describes how Ethernet VPN (EVPN) can be used as an NVO solution and explores applicability of EVPN functions and procedures.”  -- if it’s just a description (as the text clearly is), and not a technical specification, then why it is not Informational? 

I can see how we could call it an Applicability Statement (rfc2026) and still publish it in the Standards Track.  If we want to go that way, we would need some minor updates to make it clear that this is an Applicability Statement and is not intended to stand in for a Technical Specification.  I am not clear on the process as it related to possible DownRefs (see below), but I’m willing to Last Call an Applicability Statement in the Standards Track…if that is what you want.


Thanks!

Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/nvo3/cd0hOfb966ROcL4t8JCrBD28bBg/?qid=c9f632dc5d6aab5e4b22972bb242baf0



Major:

M1. Section 5.1.2.1 (Auto Derivation of RT) shows a “packet format” to illustrate how the RT can be auto-derived.  Without any context, the description doesn’t make much sense: the fields are not described in order, the reader is expected to know about global and local administrative fields, the “A-bit” (or the Type field) are not mentioned in the description, people could probably guess that “D-ID” means “domain-id”, there’s no indication of what to do with that “packet format”, etc.  Please clean the description up, include clearer explanations and some references can’t hurt.

M1.2. What about 4-byte ASNs?


M2. From 5.1.3 (Constructing EVPN BGP Routes): “...routes MAY be advertised with multiple encapsulation types as long as they use the same EVPN multi-homing procedures (section 8.3.1, Split Horizon)…”. Is Split Horizon an example, or the only multi-homing procedure that should be considered?  Please be clear.


M3. From 5.2 (MPLS over GRE):

M3.1. “...when it is used in conjunction with EVPN the GRE key field SHOULD be present, and SHOULD be used to provide a 32-bit entropy field.”  What are the cases when it is ok not to include the field, or use it for that purpose?  IOW, why are these SHOULDs not MUSTs?  Or maybe, when is the key field needed?

M3.2. "The Checksum and Sequence Number fields are not needed and their corresponding C and S bits MUST be set to zero.”  This is different than what rfc4023 specifies (not a problem).  If you’re specifying the setting of the bits, then you should be more prescriptive with whether the fields are included of not; suggestion: "The Checksum and Sequence Number fields MUST NOT be included and the corresponding C and S bits in the GRE Packet Header MUST be set to zero.”


M4. In 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulation)

M4.1. These 2 MUSTs seem out of place as they are used to explain, and not in a Normative way: “ ..the RD must be a unique value per EVI or per NVE as described in [RFC7432]. In other words, whenever there is more than one administrative domain for global VNI, then a unique RD MUST be used, or whenever the VNI value have local significance, then a unique RD MUST be used.”  s/MUST/must

M4.2. This SHOULD is also out of place because the standardization was already done in rfc7432 (this document is just mentioning it): “...as noted in section 8.6 of [RFC7432]...the single-homing ingress NVE SHOULD be able to…”. s/SHOULD/should

M4.3. Section 10.2.1 then points back at the text in 7.1 using another SHOULD…again, s/SHOULD/should


M5. 7.2 (Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation) also includes a superfluous SHOULD: “...as noted in section 8.6 of [RFC7432]...a single-homing ingress NVE SHOULD implement…”.  s/SHOULD/should


M6. The introductory paragraph in Section 8.1 (EVPN Multi-Homing Features) says that it is used to "recap the multi-homing features of EVPN to highlight the encapsulation dependencies. The section only describes the features and functions at a high-level. For more details, the reader is to refer to [RFC7432].”  However some of the 8.1.* sub-sections contain Normative language.  Is that Normative language specifying new behavior introduced in this document, or highlighting the recap from rfc7432?  If there’s no new behavior, then please use lower cases.  If there is new behavior, then it would be nice to clarify that in 8.1.


M7. In 8.3.1 (Split Horizon), this MUST is out of place because it is not specifying anything: “...other means of performing the split-horizon filtering function MUST be devised.” s/MUST/must


M8. References

M8.1. TUNNEL-ENCAP (aka draft-ietf-idr-tunnel-encaps) should be Normative, which btw is marked to Obsolete rfc5512; I mention this because both are listed in several parts, so you should take rfc5512 out.

M8.2. These should also be Normative: RFC7348, NVGRE, VXLAN-GPE, RFC4023



Minor:

P1. Please use the new Normative Language boilerplate (rfc8174).


P2. From 7.1 (Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulation): “...reduces the required routes and attributes to the following subset of four out of eight”.  Please either list the attributes that are not needed, or put in a reference to where those can be found. (rfc7432 ??)


P3. From 8.3.1 (Split Horizon): "In order to prevent unhealthy interactions…”. I would really like to see more here: what does “unhealthy interactions” mean?  Can it result in loops or lost traffic or some other “bad” thing?  I note that even through you “prohibit” the configuration, you don’t go as far as mandating that it not to be used (MUST NOT), which makes me want to understand more the potential effects…if it happens, what are the risks?


P4. In 8.3.3 (Unknown Unicast Traffic Designation): “...the ingress PE MAY use a flag-bit in the VxLAN header to indicate BUM traffic type. Bit 6 of flag field in the VxLAN header is used for this purpose per section 3.1 of [VXLAN-GPE].”  Suggestion: “…the ingress PE MAY set the BUM Traffic Bit (B bit) [VXLAN-GPE] to indicate BUM traffic.”


P5. Security Considerations:  I find that the suggestion of IPSec may be out of place in this document; this document pretty much just talks about how to use EVPN, it doesn’t really introduce new capabilities, so unless IPSec is mentioned in rfc7432 (which is not — and not even mentioned in this section), or recommended in rfc4271 (which is not) then I would refrain from including such recommendation here.  In fact, I think that pointing at the Security Considerations of existing RFCs should be enough.

P5.1. The reference to rfc4301 (beyond what VXLAN/NVGRE) mention seems like you’re trying too hard.  I would just put explicit references to the encapsulations since they should be dealing with security themselves.


P6. References: [KEYWORDS] shows up twice.  I think that the reference to rfc4271 can be made Informative.




Nits:

N1. Section 3 (Terminology) literally transcribes several definitions from rfc7432/rfc7365 — while it is ok, I personally prefer just pointing at the definitions: it’s just easier to have the other RFCs be the authoritative source and not rely on maintaining the definitions in sync should they ever change.  Suggestion: “The reader is expected to be familiar with the terminology in …”.

N2. s/the VNI value have local significance/the VNI value has local significance

N3. s/it is recommend/it is recommended

N4. Please be consistent in naming references, some list the RFC number, while others a name...

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Standard Track, as properly indicated on title page header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how Ethernet VPN (EVPN) [RFC7432] can be used
  as an Network Virtualization Overlay (NVO) solution and explores the
  various tunnel encapsulation options over IP  and their impact on the
  EVPN control-plane and procedures. In particular, the following
  encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.

Working Group Summary

  There was very large support for adopting this work.
  Nothing else particular worth highlighting.

Document Quality

  This specification is of very good technical quality and  are
  known to have multiple interoperable specifications.

Personnel

  Thomas Morin is the Document Shepherd.
  Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has done a thorough review that lead to a few
editorial fixes or improvements. The doc is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The shepherd believe that a document of such importance (given implementations
and deployments) could have ideally benefited from more in-depth reviews outside
the co-authors group, but will not raise this as a too serious issue since the
specification is known to have multiple interoperable implementations.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors confirmed that.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No disclosure made.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Very large consensus in the group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

All nits have been addressed in -08.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All clear.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change in existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section merely documents codepoints used
by these specs but not allocated in the context of the publication
of these specs.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

Request for posting confirmation emailed to previous authors: Wim Henderickx , Ravi Shekhar , John Drake , Jim Uttaro , bess-chairs@ietf.org, Ali Sajassi , Nabil Bitar

Request for posting confirmation emailed to previous authors: "Ravi Shekhar" , "Jim Uttaro" , "Nabil Bitar" , "John Drake" , "Ali Sajassi" , bess-chairs@ietf.org, "Wim Henderickx"

Request for posting confirmation emailed to previous authors: "Ravi Shekhar" , "Jim Uttaro" , "Nabil Bitar" , "John Drake" , "Ali Sajassi" , bess-chairs@ietf.org, "Wim Henderickx"

Request for posting confirmation emailed to previous authors: "Ravi Shekhar" , "Jim Uttaro" , "Nabil Bitar" , "John Drake" , "Ali Sajassi" , bess-chairs@ietf.org, "Wim Henderickx"