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

["Andrew McLachlan (amclachl)" <[e-mail]>]

just to emphasise  ….they are clearly described in the draft

On 12 Nov 2013, at 18:21, Henderickx, Wim (Wim) <[e-mail]<mailto:[e-mail]>> wrote:

They are described in the draft.

Cheers,
Wim
_________________
sent from blackberry

From: Lucy yong [mailto:[e-mail]]
Sent: Tuesday, November 12, 2013 07:14 PM
To: Henderickx, Wim (Wim); [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

Wim,

Please clarify your real use case.  In your real use case, when using a firewall, does it use with a gateway together or not. If not, the firewall is a just middle box (wired) and does not participate in the L2VN routing. If it works with the gateway, only gateway participates in the L2VN,  not the firewall. The configuration between gateway and firewall is local, not related to the L2VN.

Lucy

From: Henderickx, Wim (Wim) [mailto:[e-mail]]
Sent: Tuesday, November 12, 2013 11:11 AM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

In-line

From: Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 12 November 2013 19:05
To: Wim Henderickx <[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, Please see below.

From: Henderickx, Wim (Wim) [mailto:[e-mail]]
Sent: Tuesday, November 12, 2013 1:22 AM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement



From: Lucy yong <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 12 November 2013 05:11
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,

When using a (centralized) gateway to provide external network connection for an L2 VN, I agree, it is necessary for the gateway to advertise its IP host address and MAC to all the NVEs in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will know the gateway IP host and MAC address and perform the proxy ARP function, i.e. terminate the ARP requests if the requested tenant systems (including gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant system will send an L2 frame with designation tenant system or gateway MAC in dMAC to attached NVE, the NVE just performs the table lookup to obtain the outer address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why need to use RT5 to convey the GW IP/MAC info?  Please explain, I may miss some part in nutshell.

WH> if you look to the drawings in the slides the NVE(s) can also have IP prefixes behind them. E.g. A firewall, etc. this is what we are referring to in the draft.
See fig 1/2/3/4/5.
[Lucy] OK, this is how to deal with network appliances. Do we want to treat it as a middle box, or a tenant system that has multiple addresses? I guess, you want to address it as the latter. Even it is the latter, IMO, such tenant system should not advertise the prefix in an L2 VN at all because it serves middle box function only. If a tenant system is a gateway, it needs to advertise itself as gateway (not the prefix from other VN). Then it will be the same case as the following description. Does this make sense?

WH2> there are real use cases as we describe which are required to be supported and hence this is what the draft is proposing and as we said before L3VPN AFI/SAFI does not do the job.

When using a gateway to provide external network connection for an L3 VN, NVEs use their MAC address in ARP reply if VAP is L2 access interface. The L2 frame from a tenant system will be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have all the IP routes in the VN. When NVE performs a lookup and is not able to find the matching one, it means the packet for the external.  Since the gateway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going to external to the gateway.  In this case, the NVE acts as the first-hop router, the gateway is the last-hop in the VN.  You are right, it is necessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve the protocol.

Regarding the IRB capability, this is my view about IRB implementation in virtual overlay environment.
<image001.png>


Figure shows two L2VNs, VNx and VNz.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2 implement L3 distributed gateway functions and have the same MAC address for the L3dGW. When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenant systems in both VNs. NVEs still terminates the ARP requests and provide the MAC for the remote tenant system in the same VN. NVEs returns L3dGW addresses for the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2.  Will this make sense to you?

WH> yes but the prefix draft is orthogonal to this. So lets not mix these things. The draft describing IRB is the following for which you are a co-author and we are submitting an update to show the 2 architectures supporting this:

https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02
[Lucy] yes, we provide a lot of inputs on evpn overlay and interworking drafts. Glad to continually work on these drafts. However, these drafts are still individual drafts. As we are more and more clear on the network virtualization overlay for the cloud applications, we need update the descriptions (an implementation) in these drafts to make it clear. As you aware, neither of us works on these drafts recently.

WH2> we did in the last IETF and the updates will be reflected before the end of the year


Thanks,
Lucy







From: Henderickx, Wim (Wim) [mailto:[e-mail]]
Sent: Monday, November 11, 2013 2:22 AM
To: Lucy yong; [e-mail]<mailto:[e-mail]>
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

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