Skip to main content

IP Prefix Advertisement in Ethernet VPN (EVPN)
draft-ietf-bess-evpn-prefix-advertisement-11

Yes

(Alvaro Retana)

No Objection

(Deborah Brungard)
(Martin Vigoureux)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 10 and is now closed.

Warren Kumari
No Objection
Comment (2018-05-10 for -10) Unknown
NoObjection in the "I read the protocol action, and I trust the sponsoring AD so have no problem." / ran out of cycles sense.
Alvaro Retana Former IESG member
Yes
Yes (for -10) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2018-05-09 for -10) Unknown
The density of unexpanded acronyms makes this document particularly challenging
to read. Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - EVPN
 - NVO
 - MAC
 - VXLAN
 - nvGRE
 - PE
 - TOR
 - IP-VPN
 - VM
 - ESI
 - NLRI
 - VTEP
 - VSID
 - ES
 - AD
 - GPE
 - sBD
 - DA
 - ABR
 - CE
Alissa Cooper Former IESG member
No Objection
No Objection (2018-05-09 for -10) Unknown
The Gen-ART reviewer did an in-depth review and I have not seen any response yet: https://datatracker.ietf.org/doc/review-ietf-bess-evpn-prefix-advertisement-10-genart-lc-davies-2018-04-14/
Ben Campbell Former IESG member
No Objection
No Objection (2018-05-09 for -10) Unknown
I agree with Alissa that the GenART review should be addressed.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2018-05-21) Unknown
Thank you for addressing my comments!  I leave the original ballot text
below for reference.

DISCUSS

There are a lot of places where the actual requirements
seem (potentially) ambiguously written or incomplete, or the
document is internally inconsistent.  I expect that at least some of
these are just confusion on my part, so hopefully someone can clue
me in on where I'm going astray.

Not exactly a DISCUSS, but is there a plan for resolving the normative reference to the expired
draft-ietf-bess-evpn-inter-subnet-forwarding?

Does Section 3's
   [...] In case two or more NVEs are attached to
   different BDs of the same tenant, they MUST support RT-5 for the
   proper Inter-Subnet Forwarding operation of the tenant.
apply even when there is a SBD between them in the topology, or does
something in the SBD also need to support RT-5 in such cases?

Section 3.2's
   o The ESI and GW IP fields may both be zero, however they MUST NOT
     both be non-zero at the same time. A route containing a non-zero GW
     IP and a non-zero ESI (at the same time) SHOULD be treat-as-
     withdraw [RFC7606].
seems to say that ESI and GW IP cannot both be zero at the same
time, but there seem to be entires in Table 1 that have that be the
case.  There are also potential combinations not included in Table 1
-- are we supposed to infer that anything not listed is an error
condition (and thus treat-as-withdraw)?

Section 4.4.1's
   Each RT-5 will be sent with a route-target identifying the tenant
   (IP-VRF) and two BGP extended communities:
seems to say that there will always be these two extended
communities, but there seems to be other text later implying that
the "Router's MAC" extended community is not always present.

COMMENT

There seem to be a lot of different mechanisms listed to do the same
thing, and not much guidance on in what scenarios each one is
better/worse (i.e., some justification for including this much
flexibility instead of a smaller number of generally applicable
options).  Is that something the authors are interested in adding?


It might be worth sorting the definitions in Section 1 to help
readers find specific definitions as they refer back.
(Also, "EVPN" is not marked as well-known on the RFC Editor's list
(https://www.rfc-editor.org/materials/abbrev.expansion.txt) and thus
would be expected to be defined as well.)
Nitpicking, but is "GARP message" or "gratuitous ARP message" the
more common usage?  "GARP" is only used once other than the
definition...
"TOR" (actually "ToR"?) is not defined here.
"NLRI", "VTEP", "ESI", "ES", "AD" as well.


Section 2.1

        o Note that the same IP address could exist behind two of these
          TS.

It sounds like this is "same IP address and endpoint" as opposed to
"same IP address due to multiple endpoints being assigned the same
(e.g., private) IP address in different domains"?  Should that be
specifically clarified?


In Section 3.1, when adapting to other reviews and noting how the
IPv4/IPv6 distinction is made, perhaps it would also be good to note
that the IP Prefix and GW IP Address must represent the same family.
Also, maybe "The GW IP field MUST be zero" should say "all bytes
zero".

Does the recursive resolution requirement represent a risk of
DoS via resource consumption?  (Is the recursion depth limited to
one additional resolution?)

Still in Section 3.1, please say something about the other 4 bits,
even if it's "zero on send, ignore on receive".


Section 4.1

The parenthetical about "(ND-snooping if IPv6)" does not make much
sense in the context of an example that explictly uses IPv4.
(Additionally, there should probably be some IPv6 examples.)


In Section 4.4.2, does the "GS IP address=IRB-IP" refer to the IP of
the SBD?


Section 4.4.2
   (1) NVE1 advertises the following BGP routes:

        o Route type 5 (IP Prefix route) containing:

          . IPL=24, IP=SN1, Label= SHOULD be set to 0.

          . GW IP=IP1 (sBD IRB's IP)

          . Route-target identifying the tenant (IP-VRF).

        o Route type 2 (MAC/IP route for the SBD IRB) containing:

          . ML=48, M=M1, IPL=32, IP=IP1, Label=10.

          . A [RFC5512] BGP Encapsulation Extended Community.

          . Route-target identifying the SBD. This route-target may be
            the same as the one used with the RT-5.

I don't understand how the route-target can be the same for the RT-5
and RT-2 routes -- aren't they identifying different things (tenant
and SBD)?
Also, "NVE1 IP" is used in the body text, but in the figure I think
this would just be "IP1"?
I am less sure what "NVE1 IP" is supposed to be in Section 4.4.3.


The Security Considerations talk of a security advantage from
blocking dynamic routing protocols on the NVE/PE ACs; this would
seem more relevant if phrased as "not allowing the tenant to
interact with the infrastructure's dynamic routing protocols".  (The
customer could of course tunnel whatever sort of dynamic routing
protocol they want over the EVPN.)
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-05-09 for -10) Unknown
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4698

I found this document pretty dense and only gave it a light read.


COMMENTS
S 2.2
>        independent of and not subject to the interpretation of the IPL and
>        the IP value. E.g.: a default IP route 0.0.0.0/0 must always be
>        easily and clearly distinguished from the absence of IP
>        information.
>   
>      o In MAC/IP routes, the MAC information is part of the NLRI, so if IP

You need to define NLRI on first use.


S 3.1
>   
>      o The total route length will indicate the type of prefix (IPv4 or
>        IPv6) and the type of GW IP address (IPv4 or IPv6). Note that the
>        IP Prefix + the GW IP should have a length of either 64 or 256
>        bits, but never 160 bits (IPv4 and IPv6 mixed values are not
>        allowed).

Really shaving the bits tight here, I see.


S 3.2
>      Table 1 shows the different RT-5 field combinations allowed by this
>      specification and what Overlay Index must be used by the receiving
>      NVE/PE in each case. Those cases where there is no Overlay Index, are
>      indicated as "None" in Table 1. If there is no Overlay Index the
>      receiving NVE/PE will not perform any recursive resolution, and the
>      actual next-hop is given by the RT-5's BGP next-hop.

How do I behave if something appears that is not on this table


S 6.
>         overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc.
>   
>      d) An EVPN implementation not requiring IP Prefixes can simply
>         discard them by looking at the route type value.
>   
>   6. Security Considerations

I'm not sure that this is a security consideration, but does the
ability to specify an IP as the next hop mean that you could route
packets somewhere totally off EVPN?
Ignas Bagdonas Former IESG member
No Objection
No Objection (2018-05-08 for -10) Unknown
NVGRE and VXLAN-GPE references throughout the document – would be better to replace with Geneve, as NVGRE is historic, and GPE will wait until Geneve progresses. This does not change the logic of operation for non-Ethernet NVO tunnels. 

s2.1, last bullet: TS4 connectivity is not required to be physical, it is just connectivity. 

s3.2: s/fail to install/MUST not install

s4.3, steps 1 and 2: what if MAC address is both signaled and learned by policy? How would such conflict be resolved? Which one would take precedence? 

s2: s/program/propagate


A few assorted nits: 

Document would benefit from reduction of hyphenation of common terms and normalizing the spelling of the terms throughout the document (as an example, there are forms of route type, route-type, and Route Type intermixed). Re-advertise, stripped-off, mass-withdrawal, ip-lookup, mac-lookup, re-used, inter-subnet-forwarding, next-hop.

s/route-target/Route Target

s/layer-2/layer 2

s/layer-3/layer 3

RT-2, RT-5: please consider unifying the terminology and use route type 2/route type 5, RFC7432 does not use RT-x notation. 

S4.4.2: s/IP10/IP1
Martin Vigoureux Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -10) Unknown