Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

["Henderickx, Wim (Wim)" <[e-mail]>]

In-line

From: Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Monday 11 November 2013 08:43
To: Wim Henderickx <[e-mail]<mailto:[e-mail]>>, Lucy yong <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

Wim,

I read the draft and still think that all the use cases work well with RT2.  Here are my views how these use cases in section 5 can be implemented without RT5

Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN.
The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation “L3VN plus a gateway” Why do you want to use an L2 VN overlay here?

WH> you don’t have a GW IP in the L3VPN AFI/SAFI, so you will need to define a new route to do this efficiently

Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE are co-located; in the case 4, TS and NVE are physically separated.  First of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 with multi-homing. Thus, it can be implemented by “L3VN plus a gateway” w/ VRRP.

WH> there is no VRRP in these cases since the appliance is a bump in the wire for use case 4 so they don’t even speak IP, so you have an undefined NH, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH possible

In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the packet dMAC address will be the MAC address for the distributed gateway that is the same for all the NVEs. When NVE sees this address, it will perform the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 receives a packet from IP1 and the packet has the destination in the WAN network, the dMAC on the packet is also the MAC address for the distributed gateway. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the outer IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior sending it out. When DGW1 receives the packet, it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform the packet treatment before sending to the WAN.

WH> it depends how you want to do this, you can either go route from ingress w/o IP lookup on ingress or do a lookup on egress. Both options are possible and required for some HW in the market. EVPN supports both already, what this draft is doing is how prefixes should be used in this environment

L2/L3 NVE service type described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addresses but may advertise both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type is used, NVE just maintains TS MAC addresses. Both cases can be implemented by EVPN solution.

WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB case

There are places we need to use L2 VNs. For example, all TSes in a VN have the same IP address but different MAC addresses;  there is broadcast/multicast traffic in a VN; non-IP packet. However, we don’t want to make a complex EVPN solution to solve the case that L3VN can easily address.

WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it all. As I said not all use case can be done with L3VPN and this is required.

Regards,
Lucy







From: HenderickxHi Win,, Wim (Wim) [mailto:[e-mail]]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

Lucy, did you read the draft and is explained in section 6.
Show an example on how you do the scenario’s with RT2 and you will see why this is less efficient/scalable + does not support all scenario’s in the draft like ESI NH.

E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an interface e.g. And prefixes can exists behind them.

From: Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Friday 8 November 2013 22:10
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

Hi Authors,

I am not convinced if RT 5 is necessary for the use cases you specified in the draft (or presentation). IMO: RT2 is sufficient to support all the cases.
There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, which can be implemented by EVPN with RT2.

One question, why EVPN service allow to VAP being an IP interface?

Thanks,
Lucy