Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)
draft-ietf-bess-evpn-na-flags-09

[Ballot comment]
[ Update: Thank you for addressing my DISCUSS concern. ]

Other than my DISUCSSes, I found this document to be well written and easy to understand - thank you for writing it...

[Ballot discuss]
Be ye not afraid! This DISCUSS should be fairly trivial to address...

This allows for more information to be carried with MAC/IP Advertisements. It seems to me that this gives a DoS-style attacker more opportunities to exhaust state on routers - I could sit on a wire and create lots of ARP/ND states (make up new IP and MAC combinations), causing this to be propagated and burning memory / state / etc.

This is somewhat discussed in RFC 7432, but the technique in this document seems like it makes this issue somewhat worse - a single sentence in the Security Considerations noting it would satisfy me (as would an explanation that I'm mistaken :-)).

I also support EK & Rob's DISCUSSes

[Ballot discuss]
[ general ]

* ND in IPv6 is more than just its analogous ARP function (as immediately
  evidenced by the need to support passing the NA flags).  I'm concerned that
  this approach isn't actually satisfactory for IPv6, and could end up
  constraining existing and future ND extensions and uses.

  [1] New flags

  As new flags are defined in the NA message, they will not be deployable
  in these environments until this standard (and possibly others) is updated.

  A more forward-compatible option might be to just include the whole NA
  "flags plus reserved" word (there is room for it in the format in
  section 2).

  [2] Current and new NA ND Options

  This approach doesn't support sending additional ND Options in the NA, and
  therefore things like Secure Neighbor Discovery (SeND, RFC 3971) cannot
  be supported (nor can any future NA option).

  Arguably, ND proxying might best be disabled when a node is attempting to
  use SeND and/or whenever a Nonce Option is present an NA.  Nevertheless,
  new ND options might be specified that can be carried in NS/NA messages.

  RFC 4861 sections 4.2 and 4.3 say that "[f]uture versions of this protocol
  may define new option types", and while it also says that "[r]eceivers
  MUST silently ignore any options they do not recognize and continue
  processing the message", in this case it would be the infrastructure that
  would prevent two nodes from attempting to use a newer ND option on either
  side of this PE/CE proxying boundary and not necessarily a limitation of the
  nodes themselves.

  There is no space for these options in the current section 2 format.
  Can it be extended to optionally carry the ND options that a PE has
  observed to be sent by the node?

  Alternatively, I think we'll need some text that ND proxying MUST be
  disabled if NSes contain any options other things like TLLAO or if NAs are
  observed to have anything other than SLLAO.

  Basically, I think we should take care to not impede the deployment of any
  extensions to ND.

[Ballot comment]
Should we say anything about how the ARP/ND Extended Community is
ignored in the absence of a sibling MAC/IP Advertisement Extended
Community?

Should we remind the reader how the recipient knows that a given ARP/ND
Extended Community is associated to the coresponding MAC/IP
Advertisement Extended Community?

There seems to be some latent risk in defining an "immutable" flag with
no defined way of clearing or unsetting it (e.g., having it time out).
We should either document what the operator should do when a formerly
immutable mapping needs to change or document the risk in the security
considerations section.  (This is, I think, related to Rob's Discuss.)

Section 1

  procedure.  However, the information conveyed in the EVPN MAC/IP
  Advertisement route may not be enough for the remote PE to reply to
  local ARP or ND requests.  For example, if a PE learns an IPv6->MAC

This makes it sound like we're rectifying a deficiency of the core spec,
and therefore might want to have an Updates: (or rather, "see also")
relationship to it.

  Advertisement routes.  Similarly, other information relevant to the
  host advertised in the MAC/IP Advertisement route may be needed.

(editorial) either we know what this "other information" is and could
list it explicitly (or by section reference), or we don't, and the
solution is incomplete.

Section 1.1

  Proxy-ARP/ND: function on the EVPN PEs by which received Address
  Resolution Protocol (ARP) Requests or Neighbor Solicitation (NS)
  messages are replied locally by the PE, without the need to flood the

nit: "replied to"

Section 2

Should we explicitly say that this is a transitive extended community?

  O - Override Flag (corresponds to Bit 22 of the Extended Community)
  Bit 6 of the Flags field is defined as the "Override Flag".  An
  egress PE will normally advertise IPv6->MAC pairs with the O Flag
  set, and only when IPv6 "anycast" is enabled in the BD or interface,
  the PE will send an IPv6->MAC pair with the O Flag = 0.  The ingress
  PE will install the ND entry with the received O Flag and will use
  this information when replying to a Neighbor Solicitation for the
  IPv6 address.  [...]

I'm not 100% sure I understand what this is saying.
My current understanding is that: at present (in the absence of this
extended community), a PE has to use heuristics to set the O flag in NA
messages, with the heuristic being "normally set the O flag, but when
the BD/interface has anycast enabled, clear the O flag".  The new
behavior when the information in this extended community is available,
is then to "always send the value received from the extended community".

However, if my understanding (above) is correct, that doesn't seem quite
right, since it's generally not safe to set the O flag in such an
"anycast" scenario.  Am I missing something?

  Community) is a configured ARP/ND entry.  The IP address in the EVPN
  MAC/IP Advertisement route can only be bound together with the MAC
  address specified in the same route.

nit: I'm not sure I understand what "can only be bound together with"
means here.  (What would the other option be?)

Section 3.1

Just to check my understanding: the dynamic learning here only applies
to NA messages received from the CE directly, not those received from
other EVPN routers?  (Do we need to say that explicitly?)

  o  This Extended Community does not change the procedures described
      in [RFC7432].  Specifically the procedures for advertising the MAC
      Mobility Extended Community along with the MAC/IP Advertisement
      route are not changed.

(side note) I'm not entirely sure how one might expect the MAC Mobility
processing to have changed as a result of the addition of the ARP/ND
Extended Community, but there doesn't seem to be any real harm in
mentioning it like this.

Section 3.2

      *  If the EVPN MAC/IP Advertisement route contains an IPv6 address
        and the EVPN ARP/ND Extended Community, the PE MUST add the R
        and O Flags to the ND entry in the ND or proxy-ND table and use
        that information in Neighbor Advertisements when replying to a
        Solicitation for the IPv6 address.

editorial: "add the R and O Flags" could sound like they are always set
to 1; perhaps "propagate the value of the R and O flags from the ARP/ND
Extended Community to the ND entry"?

        move as well.  Even so, if an update for the same IP1->MAC1
        immutable and static, is received from a different PE, one of
        the two routes will be selected, as in the [RFC7432] case where
        two MAC/IP routes with Static bit are received for the same MAC
        from different PEs.

I couldn't find much discussion of this scenario in RFC 7432 by
searching for "static" or "sticky"; could you help point me in the right
direction?

  destination to PE2.  If for some reason, PE3 originates an EVPN MAC/
  IP Advertisement route for IP1->MAC2 (even with a higher sequence
  number), then the EVPN PEs in the BD SHOULD NOT update their
  IP1->MAC1 ARP/ND bindings, since IP1 is bound to MAC1 (MAC2 SHOULD
  still be programmed in the layer-2 BDs).  This is considered a
  misconfiguration in PE3.

I don't really understand the motivation for SHOULD NOT, here.  It seems
like a PE would need to violate some other part of the spec in order to
do so, so just "will not" would be workable.
(I'm also left to assume that the route from PE3 sets I=0, which might
be worth making explicit.)

  The use of the Flag I=1 assumes that a given IP is always bound to
  the same MAC address, and therefore the mobility procedures described
  in [I-D.ietf-bess-evpn-irb-extended-mobility] for "Host IP move to a
  new MAC" will not apply.

Do we want to say anything about how things should behave if the
assumption is violated?

Section 4

It seems like this mechanism (or rather, RFC 7432's MAC/IP
Advertisement) doesn't really affect the spoofability of ND; the same
information (actually the same, now that this mechanism exists to send
the R/O flags) is being conveyed just over a different protocol, and
DAD/mobility should still work the same way.  There's an extra
translation step at the PEs the introduces an opportunity for
translation errors but that's not very noteworthy.

The I flag is somewhat different, as I mentioned at the top of my
comments.

  Similarly, the receiver of a NA message with the wrong R flag, may
  update its Default Router List incorrectly adding or removing an
  entry.

I suggest adding at the end of the sentence ", which could for example
lead to sending traffic to a node that is not a router, causing the
traffic to be dropped".

Section 5

Given the email discussion regarding the use of flag position 5, should
a note be left in the registry about that informal usage?

[Ballot discuss]
Hi,

Hopefully a relatively easy discuss to resolve and this might just be my ignorance here:

Section 2 states that I flag is used for an immutable ARP/ND Binding which is for a configured ARP/ND entry.

Section 3.2 Reception of the EVPN ARP/ND Extended Community, has the following text:

      *  Receiving multiple EVPN MAC/IP Advertisement routes with I=1
        for the same IP but different MAC is considered a
        misconfiguration.

But wouldn't this scenario occur if the configured ARP/ND entry was changed to point to a new MAC address?

Regards,
Rob

[Ballot comment]
Thank you for the work put into this document. Even if I mainly rely on the int-dir review (see below), I quickly reviewed the document and found it very useful and readable.

Thanks to Ralf Weber who did the INT directory review, at https://datatracker.ietf.org/doc/review-ietf-bess-evpn-na-flags-05-intdir-lc-weber-2020-08-28/

Please find below a couple of non-blocking COMMENT and NIT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 2  --
For my curiosity sake, why bit 5 of the 'Flags field' is not described? I would have naively assumed that all flags would be contiguous.

== NITS ==

-- Section 2 --
While it is specified that the reserved fields are set to 0, the usual 'and ignored by the receiver' is not present.

When describing the 'Router Flag', I suggest s/belongs to a router. /belongs to an IPv6 router./ even if fairly obvious

[Ballot comment]
Only minor comments here; please consider them, but there’s no need for a detailed reply.

A number of abbreviations need to be expanded on first use, including EVPN, PE, ND, IRB, and CE.

— Abstract —
The Abstract is exactly, word for word, the same as the first two paragraphs of the Introduction, except that the Introduction helpfully splits it into two paragraphs.  I have comments about the text below, but for the Abstract I suggest shortening it by removing the explanatory stuff and just leaving the summay of what this document is doing — just the final sentence looks fine, I think.

— Section 1 —

  An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
  IPv6 addresses associated with a MAC address.

Nit: Change “an IPv4” to just “IPv4”, I think, yes?

  the PE would not know if that
  particular IPv6->MAC pair belongs to a host, a router or a host with
  an anycast address

Two things here:  This is a case where a comma after “router” will really help readability.  And isn’t “a host with an anycast address” also “a host”?  Can you rephrase this to make the distinction between the first and third list items clearer?

— Section 1.1 —
Shouldn’t “ND” also have a reference citation (RFC4861)?

— Section 2 —

  Bits 0-3 and 5 are not assigned by this document.

Shouldn’t this have the customary “MUST be set to zero, and ignored on receipt” text?

— Section 4 —

  This will cause all the PEs in the BD
  to reply Neighbor Solicitations for the IPv6 with Neighbor
  Advertisement messages containing the wrong R and O Flags.

There’s a word missing here after “reply”: I presume the missing word is “to”.

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

The IANA Functions Operator has completed its review of draft-ietf-bess-evpn-na-flags-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the EVPN Extended Community Sub-Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

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

the existing early registration for Sub-Type value 0x08:

Sub-Type Value: 0x08
Name: ND Extended Community

will have the name changed to:

Sub-Type Value: 0x08
Name: ARP/ND Extended Community

and its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the ARP/ND Extended Community Flags registry. The new registry is to be created on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

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

The new registry will be managed via Standards Action as defined in RFC8126. There are initial registrations in the new registry as follows:
+---------------+---------------------------------+-----------------+
| Flag position | Name | Reference | +---------------+---------------------------------+-----------------+
| 0-3 | Unassigned | - |
| 4 | Immutable ARP/ND Binding Flag (I) | [ RFC-to-be ] |
| 5 | Unassigned | - |
| 6 | Override Flag (O) | [ RFC-to-be ] |
| 7 | Router Flag (R) | [ RFC-to-be ] |
+---------------+---------------------------------+-----------------+

The IANA Functions Operator 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-08-28):

From: The IESG
To: IETF-Announce
CC: matthew.bocci@nokia.com, bess@ietf.org, Matthew Bocci , draft-ietf-bess-evpn-na-flags@ietf.org, bess-chairs@ietf.org, martin.vigoureux@nokia.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Propagation of ARP/ND Flags in EVPN) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Propagation of ARP/ND Flags in 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
last-call@ietf.org mailing lists by 2020-08-28. 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


  An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
  IPv6 addresses associated with a MAC address.  Remote PEs can use
  this information to populate their ARP/ND tables on IRB interfaces or
  their proxy-ARP/ND tables in Broadcast Domains (BD).  PEs can then
  reply locally (act as an ARP/ND proxy) to IPv4 ARP requests and IPv6
  Neighbor Solicitation messages and reduce/suppress the flooding
  produced by the Address Resolution procedure.  However, the
  information conveyed in the MAC/IP route may not be enough for the
  remote PE to reply to local ARP or ND requests.  For example, if a PE
  learns an IPv6->MAC ND entry via EVPN, the PE would not know if that
  particular IPv6->MAC pair belongs to a host, a router or a host with
  an anycast address, as this information is not carried in the EVPN
  MAC/IP Advertisement routes.  Similarly, other information relevant
  to the IP->MAC ARP/ND entries may be needed.  This document defines
  an Extended Community that is advertised along with an EVPN MAC/IP
  Advertisement route and carries information relevant to the ARP/ND
  resolution, so that an EVPN PE implementing a proxy-ARP/ND function
  can reply to ARP Requests or Neighbor Solicitations with the correct
  information.




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



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

draft-ietf-bess-evpn-na-flags-04

Document Shepherd Write-Up

(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.
 
  This is appropriate as the draft describes a new BGP extended community for EVPN
  that contains some flags, which the draft specifies how to use to reduce or
  suppress flooding during address resolution. It therefore contains specific
  protocol details that must be followed for flooding to be reduced in EVPN.

  The intended status is properly indicated.

(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

An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
  IPv6 addresses associated with a MAC address. Remote PEs can use this
  information to reply locally (act as proxy) to IPv4 ARP requests and
  IPv6 Neighbor Solicitation messages and reduce/suppress the flooding
  produced by the Address Resolution procedure. The information
  conveyed in the MAC/IP route may not be enough for the remote PE to
  reply to local ARP or ND requests. For example, if a PE learns an
  IPv6->MAC ND entry via EVPN, the PE would not know if that particular
  IPv6->MAC pair belongs to a host, a router or a host with an anycast
  address, as this information is not carried in the MAC/IP route
  advertisements. Similarly, other information relevant to the IP->MAC
  ARP/ND entries may be needed. This document proposes an OPTIONAL
  extended community that is advertised along with an EVPN MAC/IP
  Advertisement route and carries information relevant to the ARP/ND
  resolution, so that an EVPN PE implementing a proxy-ARP/ND function
  can reply to ARP Requests or Neighbor Solicitations with the correct
  information.

Working Group Summary

  The document was developed to address the desire to minimise flooding of traffic
  associated with address resolution in EVPN. It is particularly important due to the
  large size that EVPN networks can grow to, partucularly in terms of the numbers of CEs
  and hosts. It makes use of some flags in a new BGP extended community to do this.

  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years.
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(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 reviewed v03 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 04.

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

  No concerns. The document has received adequate review. The document has
  been developed within the WG and reviewed over a
  period of a number of IETFs.

(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 further review required.

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

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants.
    There were no objections during last call.
   

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

  None indicated.

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

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as informative or normative.

(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

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

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

  This document does not change the status of any 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 document requests the registration of a new EVPN Extended Community:
  ARP/ND Extended Community. This is already registered by IANA (type 0x08) from
  the EVPN Extended Community registry. However, the name appears to be incorrect in the
  registry (it is named just "ND Extended Community"). This needs to be corrected.
 
  The draft also requests that a registry (ARP/ND Extended Community Flags Octet) be
  created for the flags contained in the ARP/ND Extended Community. The allocation
  procedure requested is standards action.
 
 

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

  There are no IANA registries requiring expert review.

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

  There are no sections containing formal language that needs reviewing.

draft-ietf-bess-evpn-na-flags-04

Document Shepherd Write-Up

(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.
 
  This is appropriate as the draft describes a new BGP extended community for EVPN
  that contains some flags, which the draft specifies how to use to reduce or
  suppress flooding during address resolution. It therefore contains specific
  protocol details that must be followed for flooding to be reduced in EVPN.

  The intended status is properly indicated.

(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

An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
  IPv6 addresses associated with a MAC address. Remote PEs can use this
  information to reply locally (act as proxy) to IPv4 ARP requests and
  IPv6 Neighbor Solicitation messages and reduce/suppress the flooding
  produced by the Address Resolution procedure. The information
  conveyed in the MAC/IP route may not be enough for the remote PE to
  reply to local ARP or ND requests. For example, if a PE learns an
  IPv6->MAC ND entry via EVPN, the PE would not know if that particular
  IPv6->MAC pair belongs to a host, a router or a host with an anycast
  address, as this information is not carried in the MAC/IP route
  advertisements. Similarly, other information relevant to the IP->MAC
  ARP/ND entries may be needed. This document proposes an OPTIONAL
  extended community that is advertised along with an EVPN MAC/IP
  Advertisement route and carries information relevant to the ARP/ND
  resolution, so that an EVPN PE implementing a proxy-ARP/ND function
  can reply to ARP Requests or Neighbor Solicitations with the correct
  information.

Working Group Summary

  The document was developed to address the desire to minimise flooding of traffic
  associated with address resolution in EVPN. It is particularly important due to the
  large size that EVPN networks can grow to, partucularly in terms of the numbers of CEs
  and hosts. It makes use of some flags in a new BGP extended community to do this.

  There are no IPR declarations on the draft .

     
Document Quality
   
  I have no concerns about the quality of the document. I believe it represents
  WG consensus, and it has been widely reviewed and discussed on the list over a
  number of years.
 
  The document does not specify any MIB changes or additions which would need
  review.

   
Personnel

  The document shepherd is Matthew Bocci (matthew.bocci@nokia.com).
  The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com).

(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 reviewed v03 of the document. I had no significant technical
  comments, but I did make some editorial comments that were resolved in
  version 04.

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

  No concerns. The document has received adequate review. The document has
  been developed within the WG and reviewed over a
  period of a number of IETFs.

(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 further review required.

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

  Each author listed in the Authors Addresses section has personally indicated that
  they are not aware of any IPR that has not already been declared in accordance
  with BCP 78 and 79.

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

  There are no IPR declarations on the draft.


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

    I am comfortable that the document represents WG consensus and has
    been reviewed by a reasonable number of active WG participants.
    There were no objections during last call.
   

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

  None indicated.

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

      ID-Nits passes.


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

  There are no relevant formal review criteria.

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

  Yes. All references are explicitly identified as informative or normative.

(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

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

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

  This document does not change the status of any 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 document requests the registration of a new EVPN Extended Community:
  ARP/ND Extended Community. This is already registered by IANA (type 0x08) from
  the EVPN Extended Community registry. However, the name appears to be incorrect in the
  registry (it is named just "ND Extended Community"). This needs to be corrected.
 
  The draft also requests that a registry (ARP/ND Extended Community Flags Octet) be
  created for the flags contained in the ARP/ND Extended Community. The allocation
  procedure requested is standards action.
 
 

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

  There are no IANA registries requiring expert review.

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

  There are no sections containing formal language that needs reviewing.