Some nits/questions/comments:
Abstract
EVPN provides a flexible control plane that allows intra-subnet
connectivity in an IP/MPLS and/or an NVO-based network. In NVO
networks, there is also a need for a dynamic and efficient inter-
subnet connectivity across Tenant Systems and End Devices that can be
physical or virtual and may not support their own routing protocols.
Why is that "need for ..." only in NVO networks?
Overlay index: object used in the IP Prefix route, as described in
this document. It can be an IP address in the tenant space or an ESI,
and identifies a pointer yielded by the IP route lookup at the
routing context importing the route. An overlay index always needs a
recursive route resolution on the NVE receiving the IP Prefix route,
so that the NVE knows to which egress NVE it needs to forward the
packets.
Given that there is an "underlay next-hop", perhaps rename "overlay index" to
"overlay next-hop" and define it after the "underlay next-hop"? It could also
be a MAC address (as described in 5.4.3) as well; in fact I really don't see
the need of using ESI (more below).
Suggested text for "overlay next-hop":
Overlay next-hop: an IP/MAC address in the tenant space or an ESI.
It is included in the IP Prefix route to specify that the destination
prefix is reached through the overlay next-hop, which requires a
recursive lookup of the next-hop in the tenant's space.
--------------------------------
o Clean identification, operation of troubleshooting of IP
Prefixes, not subject to interpretation and independent 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.
I had trouble understanding the "independent of" part; then I realized that it
reads better if it is moved to the beginning of the clause: "independent of and
not subject to the interpretation of ...".
Section 4 should be folded into section 2.2. In fact, much of section 6 can be
removed as well.
5.3 ESI overlay index ("Bump in the wire") use-case
How does multicast work, for traffic sourced from SN1?
. Destination inner MAC = M2 (this MAC will be obtained
from the Router's MAC Extended Community received along
with the RT-5 for SN1).
Because the RT-5 has M2 mac attached, the overlay index could be the mac
address itself - no need to use the ESI. This has advantage when there is no
multihoming (no ESI need to be defined) and can also work with multihoming. In
fact, that is what section 5.4.3 does.
5.4 IP-VRF-to-IP-VRF model
.. EVPN provides connectivity for:
1. Traffic destined to the IRB IP interfaces as well as
2. Traffic destined to IP subnets seating behind the TS, e.g. SN1 or
SN2.
In order to provide connectivity for (1), MAC/IP routes (RT-2) are
needed so that IRB MACs and IPs can be distributed. Connectivity type
(2) is accomplished by the exchange of IP Prefix routes (RT-5) for
IPs and subnets seating behind certain overlay indexes, e.g. GW IP or
ESI.
I have trouble understanding #1 above (even with the explanation). #2 is about
destinations behind the TS; is #1 about TS themselves? Why is "IRB IP" singled
out?
Additionally, I think 5.4 should be promoted to its own section (section 5 is
about three use cases of the "overlay index" or "underlay next-hop" and section
6 is about implementing IPVPN using type-5 instead of SAFI 128).
5.4.1 Interface-less IP-VRF-to-IP-VRF model
I suppose this is basically using type-5 vs. SAFI 128 routes to do IPVPN. It's
better to point that out.
b) The IP-VRF instances in the NVE/DGWs are directly connected
through NVO tunnels, and no IRBs and/or MAC-VRF instances are
defined at the core.
"at the core" is a little bit confusing. Perhaps 5.4.2/5.4.3 can be discussed
first, and then come to this new model where no dedicated mac-VRF is used for
the purpose of forwarding IPVPN traffic through this mac-VRF.
Additionally, it is not really "interface-less" vs. "interface-full". It's
really if a dedicated mac-VRF is used or not. If you organize it that way, then
5.4.2 and 5.4.3 can be easily merged (the only difference between 5.4.2 and
5.4.3 is whether IRB IP or mac address is used as the overlay-index).
BTW - in an upcoming revision of draft-lin-bess-evpn-irb-multicast, a dedicated
mac-VRF (or BD) is also used. It is called PBD (Pseudo Bridge Domain). It would
be good to synchronize the two. Will follow up on that separately.
c) The solution must provide layer-3 connectivity among the IP-VRFs
for Ethernet NVO tunnels, for instance, VXLAN or nvGRE.
d) The solution may provide layer-3 connectivity among the IP-VRFs
for IP NVO tunnels, for example, VXLAN GPE (with IP payload).
Why is c) MUST while d) MAY?
o RD as per [RFC7432].
o Eth-Tag ID=0 assuming VLAN-based service.
I suppose no matter how many BDs you have, the type-5 is not tied to any
particular BD. In case of VLAN-based service, there would be many EVIs, so
saying "RD as per [RFC7432]" is not enough; in case of vlan-aware bundle, what
Eth-Tag ID do you use? So the second bullet is not good either? My
understanding: RD is not really tied to any of the EVPN EVIs; it's really the
RD for the IP-VRF; the Eth-Tag would always be 0 as well, even for vlan-aware
bundle?
(2) DGW1 imports the received routes from NVE1:
...
o Since GW IP=0 and the VNI is a valid value, DGW1 will use the
VNI and next-hop of the RT-5, as well as the MAC address
conveyed in the Router's MAC Extended Community (as inner
destination MAC address) to encapsulate the routed IP packets.
s/encapsulate the routed IP packets/set up relevant forwarding state/? This
bullet is about what to do when receiving the route (not when receiving the
packet).
o The IP packet destined to IPx is encapsulated with: Source
inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer
IP (source VTEP) = DGW1 IP, Destination outer IP (destination
VTEP) = NVE1 IP.
Same comment as in the inter-sbunet-forwarding draft: setting of the inner
src/dst mac address to the specific value seems to be tied to certain hardware
- in theory they are not needed at all (if not were for certain hardware
implementation). If that's the case, the spec should point that out.
5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB
...
In this model, the requirements are the following:
Those do not seem to be requirements. Rather they just describe the scenario.
Same comment for 5.4.1.
o RD as per [RFC7432].
o Eth-Tag ID=0 assuming VLAN-based service.
In this case, I suppose type-5 routes are tied to the core mac-VRF, and the RD
is tied to that as wel; for Eth-Tag ID, it's tied to that mac-VRF as well. It's
better to spell that out instead of just saying "assuming VLAN-based service".
o MPLS label or VNI corresponding to the IP-VRF. Note that the
value SHOULD be zero since the RT-5 route requires a recursive
lookup resolution to an RT-2 route. The MPLS label or VNI to
be used when forwarding packets will be derived from the RT-
2's MPLS Label1 field.
Delete "corresponding to the IP-VRF. Note that the value" so that it reads as
following?
o MPLS label or VNI SHOULD be zero since the RT-5 route requires a
recursive
lookup resolution to an RT-2 route.
For the following:
o Route type 2 (MAC/IP route for the core-facing IRB)
containing:
. Route-target identifying the tenant. This route-target MAY
be the same as the one used with the RT-5.
The Route-target should really identify the mac-VRF. It is true that the
mac-VRF must be present on every NVE for the tenant, but since we're talking
about type-2 route it is better to say route target for the mac-VRF.
Similar comments for 5.4.3. However, I suggest to fold 5.4.3 into 5.4.2 - there
is really no need to repeat w/ little difference.
Jeffrey
> -----Original Message-----
> From: BESS [mailto:[email protected]] On Behalf Of Martin Vigoureux
> Sent: Monday, February 13, 2017 5:08 PM
> To: BESS <[email protected]>
> Subject: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
>
> Hello Working Group,
>
> This email starts a Working Group Last Call on
> draft-ietf-bess-evpn-prefix-advertisement-04 [1] which is considered
> mature and ready for a final working group review.
> Note that this call is longer than usual because we are pushing two
> correlated documents together.
>
> Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *5th of March*.
> Note that this is *not only* a call for comments on the document; it is
> also a call for support (or not) to publish this document as a Proposed
> Standard RFC.
>
> *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-bess-evpn-prefix-advertisement, to ensure that IPR
> has been disclosed in compliance with IETF IPR rules (see RFCs 3979,
> 4879, 3669 and 5378 for more details).
>
> *If* you are listed as a document author or contributor of
> draft-ietf-bess-evpn-prefix-advertisement-04 please respond to this
> email and indicate whether or not you are aware of any relevant IPR.
>
> Note that, as of today, no IPR has been disclosed against this document
> or its earlier versions.
>
> We are also polling for knowledge of implementations of part or all of
> what this document specifies. This information is expected as per [2].
> Please inform the mailing list, or the chairs, or only one of the chairs.
>
> Thank you,
> M&T
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>
> _______________________________________________
> BESS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
