BGP MPLS-Based Ethernet VPN
draft-ietf-l2vpn-evpn-11

[Ballot comment]
Ali has replied to my DISCUSS and promised fixes, so I'm moving the DISCUSS comments here, so Adrian can check them after the draft is updated:

-- Section 5 --

  In general, an Ethernet segment SHOULD have a non-reserved ESI that
  is unique network wide (i.e., across all EVPN instances on all the
  PEs).

Doesn't this SHOULD contradict the MUST in the definition of ESI in Section 3?

-- Section 23 (References) --

RFC2119 needs to be a normative reference, as it's required in order to understand the meaning of the MUST, SHOULD, and MAY key words.

Other non-blocking comments:

-- Section 1 --

  The procedures described here are intended to meet the
  requirements specified in [RFC7209].

But do they?  By the time we get to IESG approval, I should hope that it's more than an intent, but an assertion.  Please assert it.

-- Section 3 --

  Ethernet Segment Identifier (ESI):  If a CE is multi-homed to two or
  more PEs, the set of Ethernet links that attaches the CE to the PEs
  is an 'Ethernet segment'.  Ethernet segments MUST have a unique non-
  zero identifier, the 'Ethernet Segment Identifier'.

Aren't you defining two things here: Ethernet Segment and Ethernet Segment Identifier?  Shouldn't you make separate definitions for each?

Presuming that the segments don't all share the same ESI, the second sentence should say:

NEW
  Each Ethernet segment MUST have a unique non-
  zero identifier, the 'Ethernet Segment Identifier'.
END

  Single-Active Redundancy Mode: When only a single PE, among a group
  of PEs attached to an Ethernet segment, is allowed to forward traffic
  to/from that Ethernet Segment

I think the intent here is to refer to only one PE among *all* of the PEs attached... correct?  Or do I have that wrong?  As written, it doesn't say that.

-- Section 4 --

  An EVPN instance comprises
  CEs that are connected to PEs that form the edge of the MPLS
  infrastructure.

THANK YOU for a rare correct use of "comprises"!

-- Section 11.1 --

  The Originating Router's IP address MUST be set to an IP address of
  the PE.  This address SHOULD be common for all the EVIs on the PE

Why the SHOULD?  What are the effects to the protocol if the address is not common?  What are the considerations that have to be made in order to decide whether it's acceptable not to use a common address?

[Ballot comment]
As noted by Dan Romascanu in his OPS-DIR review:



Here are a few observations that do not affect directly, but may impact indirectly the implementation of the procedures described in this document.



1.      The definition of a Broadcast Domain in the Terminology section is unclear.



Ø  Broadcast Domain: in a bridged network, it corresponds to a Virtual

  LAN (VLAN); where a VLAN is typically represented by a single VLAN ID

  (VID), but can be represented by several  VIDs.





One wonders – what combination of VIDs cannot represent a VLAN according to this definition?



2.      In many places acronyms are not expanded at first occurrence and some of them are never expanded. Just two examples: NRLI and SAFI in section 7



3.      In section 8.5 I could find one of the few cases when there is information targeting the operators who will deploy this type of solutions.



Ø    2. The PE then starts a timer (default value = 3 seconds) to allow

Ø    the reception of Ethernet Segment routes from other PE nodes

Ø    connected to the same Ethernet Segment. This timer value MUST be same

Ø    across all PEs connected to the same Ethernet Segment.





What is the impact of mis-configuring the timers on the PEs connected to the same segment at different values? Can this be a security attack to protect against?





4.  The IANA Considerations section says that the registry for “EVPN Route Types” has no maximum value. But then the Route Type field as defined in section 7 has 1 octet – so there should be a maximum value.

[Ballot discuss]

The security considerations here say: "Note that [RFC5925]
will not help in keeping MPLS labels private -- knowing the
labels, one can eavesdrop on EVPN traffic. However, this
requires access to the data path within an SP network, which
is assumed to be composed of trusted nodes/links." The last
clause there seems to me to be one that reality has trumped,
e.g. with Belgacom/GCHQ.  I think a direct consequence is that
TCP-AO isn't really sufficient here for the P in VPN to be
meaningful.  Now, I'm not really expecting that you'll all
suddenly agree with me about that, so I'm not expecting that
you'll immediately want to encrypt all traffic, but I'd like
to better understand what security considerations apply here
when not all infrastructure nodes can be trusted, as perhaps
there's at least a bit more documentation needed to cover
that. (We can chat separately about a plan to try fix this
longer term, but while I'd be delighted to have that chat, I'm
not trying to require it as part of this discuss.)

[Ballot comment]
I gave the document a *very* quick read. Nothing jumping out at me as either apps related or  worrisome. No objection unless someone thinks I should go through this more thoroughly.

[Ballot discuss]
Just a couple of easy points:

-- Section 5 --

  In general, an Ethernet segment SHOULD have a non-reserved ESI that
  is unique network wide (i.e., across all EVPN instances on all the
  PEs).

Doesn't this SHOULD contradict the MUST in the definition of ESI in Section 3?

-- Section 23 (References) --

RFC2119 needs to be a normative reference, as it's required in order to understand the meaning of the MUST, SHOULD, and MAY key words.

[Ballot comment]
-- Section 1 --

  The procedures described here are intended to meet the
  requirements specified in [RFC7209].

But do they?  By the time we get to IESG approval, I should hope that it's more than an intent, but an assertion.  Please assert it.

-- Section 3 --

  Ethernet Segment Identifier (ESI):  If a CE is multi-homed to two or
  more PEs, the set of Ethernet links that attaches the CE to the PEs
  is an 'Ethernet segment'.  Ethernet segments MUST have a unique non-
  zero identifier, the 'Ethernet Segment Identifier'.

Aren't you defining two things here: Ethernet Segment and Ethernet Segment Identifier?  Shouldn't you make separate definitions for each?

Presuming that the segments don't all share the same ESI, the second sentence should say:

NEW
  Each Ethernet segment MUST have a unique non-
  zero identifier, the 'Ethernet Segment Identifier'.
END

  Single-Active Redundancy Mode: When only a single PE, among a group
  of PEs attached to an Ethernet segment, is allowed to forward traffic
  to/from that Ethernet Segment

I think the intent here is to refer to only one PE among *all* of the PEs attached... correct?  Or do I have that wrong?  As written, it doesn't say that.

-- Section 4 --

  An EVPN instance comprises
  CEs that are connected to PEs that form the edge of the MPLS
  infrastructure.

THANK YOU for a rare correct use of "comprises"!

-- Section 11.1 --

  The Originating Router's IP address MUST be set to an IP address of
  the PE.  This address SHOULD be common for all the EVIs on the PE

Why the SHOULD?  What are the effects to the protocol if the address is not common?  What are the considerations that have to be made in order to decide whether it's acceptable not to use a common address?

[Ballot comment]
Please add some BGP security references, Adrian suggested the following:
RFC 4271 itself
RFC 4272 for a vulnerabilities analysis
RFC 2385 (ye olde MD5 for BGP)
RFC 6952 for an overview of security mechanisms

RFC 6480 doesn't really seem applicable

Thanks for addressing the SecDir review comments!
https://www.ietf.org/mail-archive/web/secdir/current/msg05120.html

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-l2vpn-evpn-08 and has questions about two of the actions. One question involves replacing references for and changing the names of  existing registrations. 

Upon approval, IANA understands that there are three actions that must be completed.

First, using the First Come, First Served registration process as defined in RFC 5226, IANA has already registered a value of 70 for "BGP EVPNs" in the SAFI Values registry at

https://www.iana.org/assignments/safi-namespace

IANA will update the reference for this registration when the IESG approves this document.


Second, using the First Come, First Served registration process as defined in RFC 5226, IANA has registered the following values in the EVPN Extended Community Sub-Types registry under the Border Gateway Protocol (BGP) Extended Communities heading at

https://www.iana.org/assignments/bgp-extended-communities/

0x00 EVPN MAC Mobility Extended Community
0x01 EVPN ESI Label Extended Community
0x02 EVPN ESI Label Extended Community

IANA Questions --> These have all been registered with different names ("MAC Mobility," "ESI MPLS Label," and "ES Import") than the names used in the document (listed above). Should we change the names in the registry?

Also, values 0x00 and 0x02 were registered with draft-ietf-l2vpn-pbb-evpn and draft-sajassi-l2vpn-evpn-segment-route, respectively, as their references (although neither draft mentions the registration in its IANA Considerations section). Is this document replacing those references, or should it be listed as an additional reference?

(Note:all three registrations were made in July 2012 in accordance with a request from Keyur Patel.)


Third, the authors write,  "For EVPN NLRI (with AFI%, SAFI = 70), the following route types are requested from IANA:    1 - Ethernet Auto-Discovery (A-D) route 2 - MAC/IP advertisement route    3 - Inclusive Multicast Ethernet Tag Route    4 - Ethernet Segment Route"

IANA Question --> In which registry are these new route types being requested?


IANA understands that these are the only actions 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 what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Best regards,

Amanda Baber
IANA Request Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BGP MPLS Based Ethernet VPN) to Proposed Standard

The IESG has received a request from the Layer 2 Virtual Private Networks
WG (l2vpn) to consider the following document:
- 'BGP MPLS Based Ethernet VPN'
  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 2014-09-29. 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 describes procedures for BGP MPLS based Ethernet VPNs
  (EVPN). The procedures described here are intended to meet the
  requirements specified in [EVPN-REQ].

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-l2vpn-evpn/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2362/
  http://datatracker.ietf.org/ipr/2363/
  http://datatracker.ietf.org/ipr/2420/
  http://datatracker.ietf.org/ipr/1910/
  http://datatracker.ietf.org/ipr/1751/

AD review
========

Goodness, but there's a long and complicated document. But I think
you have made it as clear and concise as it could possibly have been.
Good job!

I have done my AD review and found no substantive issues. I do,
however, have a little pile of nits. Actually, quite a large heap.
Nothing to worry about, but if you could clean them up i think it
would improve the document still further.

The only topics that need real attention are those related to IANA.

Let me know how you get on, and please object if my comments are wrong.

Thanks,
Adrian

===

It would be best to move the Introduction to be the first section in
the document.

---

Section 5

  Ethernet segments have an
  identifier, called the "Ethernet Segment Identifier" (ESI) which is
  encoded as a ten octets integer.

It would help if you said "...in line format with the most significant
octet sent first."

---

Section 5

  In general, an Ethernet segment MUST have a non-reserved ESI that is
  unique network wide

"In general" is not really consistent with "MUST"

---

Do you want an IANA registry to track the values of the Type field of
the ESI?                                   

---                                         

There is some mixing of "octet" and "byte" in the document. This creates
the impression that you mean something different by the two words.

---

Could you expand DF on first use. You have it in 8.3.

---

Section 6

You use "Ethernet Tag ID", "Ethernet Tag", and "Ethernet Tag Identifier"
interchangeably. It would be helpful to use just one term and to check
usage in the rest of the document.

---

Section 6.1

  In such
  scenarios, the Ethernet frames transported over MPLS/IP network
  SHOULD remain tagged with the originating VID and a VID translation
  MUST be supported in the data path and MUST be performed on the
  disposition PE.

I think you should add under what circumstances the frames MAY be re-
tagged with a different VID (or s/SHOULD/MUST). You don't need a
detailed explanation, but a guide to the implementer/operator.

---

Do you want IANA to create a registry and track the Route Types defined
for the EVPN NLRI in Section 7?

---

Section 7.1 and onwards...

I know "RD" is a term of art in the context of BGP, but could you
please expand RD it on first use rather than leaving that to 8.2.1.

(All the forward references to later sections are good, thanks.)

---

A small inconsistency between sections 7 and 8. In the figures in
Section 7 you have "MPLS Label" and "MPLS Label1" etc. In the text
in Section 8 you have "MPLS label" etc. When you refer to the fields
you need to match the case. When you refer to the concept of an MPLS
label, you can (of course) use normal case.

---

Are you sure that the ESI Label extended community and subtypes don't
need IANA intervention here?

---

It would be nice if 7.5 included a hint as to what an "ESI label" is.

---

In 7.10

  If a PE uses RT-Constrain, the PE SHOULD advertise all such RTs using
  RT Constraints.

Is this a general restatement of RFC 4684 (if so add "As described in
[RFC4684]...") or new guidance for implementers of this spec (if so,
what is the reason for SHOULD? is there a MAY to counter it?)

---

8.1.1

  The Ethernet Segment Identifier MUST be set to the ten octet ESI
  identifier described in section 5.

Would that be the ESII? :-)

---

8.2.1 has "MANDATORY" I guess you are inventing a 2119 term to counter-
point "OPTIONAL". Please use "REQUIRED."

---

In Section 13.1

  In certain
  environments the source MAC address MAY be used to authenticate the
  CE and determine that traffic from the host can be allowed into the
  network.

Want to hint which environments they would be. Possibly more important,
want to say in which environments this would be a damn fool idea?

---

14.1.2

  The MPLS label stack to send the packets to PE1 is the MPLS LSP stack
  to get to PE1 and the EVPN label advertised by PE1 for CE1's MAC.

and

  The MPLS label stack to send packets to PE2 is the MPLS LSP stack to
  get to PE2 and the MPLS label in the Ethernet A-D route advertised by
  PE2 for , if PE2 has not advertised MAC1 in BGP.

It *should* be perfectly obvious to the implementer, but perhaps you
should say what order the labels appear on the stack since "and" is non-
specific.

---

Section 18

I wish you would add a reference to 4385 and use that control word with
the various fields set to zero. This would keep us from increasing the
number of different control word definitions in the wild. I think that
the impact on your spec would be zero.

---

Section 21 should be renamed "Contributors"

---

I think RFC 2119 is a normative reference.

Draft Title: BGP MPLS Based Ethernet VPN
Draft Name: draft-ietf-l2vpn-evpn-07

(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?

Standards Track.

This is the proper type of RFC as this is the base protocol draft for EVPN, which is at
the core of most of the new L2VPN work.  The type of RFC is indicated in the 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 procedures for BGP MPLS based Ethernet VPNs (EVPN),
  which are intended to meet the requirements specified in RFC7209.  EVPN requires
  extensions to existing IP/MPLS protocols as described in this document, but also
  uses several building blocks from existing MPLS technologies.

Working Group Summary:

  This document is an L2VPN Working Group document, and has been reviewed in
  the working group through multiple iterations of the draft.

Document Quality:

  The document is long (50 pages) and detailed, however this is due to the inherent
  complexity of the problem which EVPN solves - namely the provision of scalable
  E-LAN services with support for active/active attachment (i.e. the ability for CE
  devices to load balance across multiple PEs).  The document has been through
  multiple revisions and is now sufficiently stable to progress to RFC, and more
  importantly to be used as a reference for creating interoperable implementations.

Personnel:

  Document Shepherd: Giles Heron (giheron@cisco.com)
  Area Director: Adrian Farrell (adrian@olddog.co.uk)

(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 did a thorough review of the text of version -06 of the draft,
leading to the authors issuing version -07 with a large number of fixes.  The Document
Shepherd did a scan through the mail archives and previous IETF meeting minutes to
review debates on the draft.

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

No.

(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.

No.  From a security perspective the solution inherits the characteristics of VPLS
(RFC4761/RFC4762) and of IP-VPN (RFC4364).  Additional considerations are
addressed in the security section - and will no doubt be reviewed as part of the IESG
process.  From an operational complexity perspective the document shepherd has
actively sought comments from service providers, and indeed there are service
providers amongst the author list for the draft.  Again no doubt this aspect will be
discussed as part of the IESG process.

(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 specific concerns.

(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?

Yes.

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

Yes, IPR has been filed by Juniper, Cisco and Alcatel-Lucent (ID #1751, 1910, 2362
and 2363).

The IPR issue was raised by the chairs on the WG list, specifically due to the Alcatel-
Lucent IPR having been disclosed rather late in the process (due to having initially
been disclosed against the individual ID that preceded the WG draft).  There was no
comment by anyone on the list relating to this late IPR - the only "discussion"
consisted of authors indicating that they were unware of any undisclosed IPR.

(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?

WG consensus is extremely solid.  over 20 individuals supported the draft during WG
LC, with nobody giving a differing opinion.

(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
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks
are not enough; this check needs to be thorough.

There are multiple nits due to references to drafts which have become RFCs during
the authoring of the document, and which were fixed at the end of the document but
not in the text.  These can be resolved as part of the publication process.  the
copyright year also needs to be fixed to 2014.

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

No formal review required.

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

Yes.  The Document Shepherd checked all this as part of the document review.

(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?

No - all normative references are to RFCs.

(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.

No - all normative references are upward.

(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 - no impact on status of 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 notes that IANA has already assigned a SAFI of 70, within
the L2VPN AFI or 25, to be used for the EVPN NLRI and carried in BGP using
multiprotocol extensions.  This SAFI assignment can be found at
http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml.

(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.

No new registries.

(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.

No sections written in a formal language.

Draft Title: BGP MPLS Based Ethernet VPN
Draft Name: draft-ietf-l2vpn-evpn-07

(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?

Standards Track.

This is the proper type of RFC as this is the base protocol draft for EVPN, which is at the core of most of the new L2VPN work.  The type of RFC is indicated in the 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 procedures for BGP MPLS based Ethernet VPNs (EVPN), which are intended to meet the requirements specified in RFC7209.  EVPN requires extensions to existing IP/MPLS protocols as described in this document, but also uses several building blocks from existing MPLS technologies.

    Working Group Summary:

    This document is an L2VPN Working Group document, and has been reviewed in the working group through multiple iterations of the draft.

    Document Quality:

    The document is long (50 pages) and detailed, however this is due to the inherent complexity of the problem which EVPN solves - namely the provision of scalable E-LAN services with support for active/active attachment (i.e. the ability for CE devices to load balance across multiple PEs).  The document has been through multiple revisions and is now sufficiently stable to progress to RFC, and more importantly to be used as a reference for creating interoperable implementations.

    Personnel:

    Document Shepherd: Giles Heron (giheron@cisco.com)
    Area Director: Adrian Farrell (adrian@olddog.co.uk)

(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 did a thorough review of the text of version -06 of the draft, leading to the authors issuing version -07 with a large number of fixes.  The Document Shepherd did a scan through the mail archives and previous IETF meeting minutes to review debates on the draft.

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

No.

(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.

No.  From a security perspective the solution inherits the characteristics of VPLS (RFC4761/RFC4762) and of IP-VPN (RFC4364).  Additional considerations are addressed in the security section - and will no doubt be reviewed as part of the IESG process.  From an operational complexity perspective the document shepherd has actively sought comments from service providers, and indeed there are service providers amongst the author list for the draft.  Again no doubt this aspect will be discussed as part of the IESG process.

(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 specific concerns.

(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?

Yes.

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

Yes, IPR has been filed by Juniper, Cisco and Alcatel-Lucent (ID #1751, 1910, 2362 and 2363).

The IPR issue was raised by the chairs on the WG list, specifically due to the Alcatel-Lucent IPR having been disclosed rather late in the process (due to having initially been disclosed against the individual ID that preceded the WG draft).  There was no comment by anyone on the list relating to this late IPR - the only "discussion" consisted of authors indicating that they were unware of any undisclosed IPR.

(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?

WG consensus is extremely solid.  over 20 individuals supported the draft during WG LC, with nobody giving a differing opinion.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

there are multiple nits due to references to drafts which have become RFCs during the authoring of the document, and which were fixed at the end of the document but not in the text.  These can be resolved as part of the publication process.  the copyright year also needs to be fixed to 2014.

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

No formal review required.

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

Yes.  The Document Shepherd checked all this as part of the document review.

(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?

No - all normative references are to RFCs.

(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.

No - all normative references are upward.

(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 - no impact on status of 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 notes that IANA has already assigned a SAFI of 70, within the L2VPN AFI or 25, to be used for the EVPN NLRI and carried in BGP using multiprotocol extensions.  This SAFI assignment can be found at http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml.

(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.

No new registries.

(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.

No sections written in a formal language.