Re: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Linda,

Sorry for the delayed in response. Please refer to my reply inline …

From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 28, 2013 5:28 PM
To: Lucy yong <[e-mail]<mailto:[e-mail]>>, Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01

Ali, et al,

I want to add a few more comments to the draft in addition to Lucy’s points:

When you say “connecting E-VPN NVEs within a DC” in Section 2.1,  do you mean allowing a NVE to route data frames among directly attached VMs that belong to different  E-VPN instances?

For inter-subnet,yes.

In Section 3 “Default Gateway Addressing”, you stated that “NVE behaves as an IP Gateway from the perspective of the attached end stations”.

However, the  default gateway specified in end stations usually won’t be any NVE. Therefore letting NVEs to route traffic among different E-VPN instances may violate the intention of traffic separation that L2VPN aims to provide.

We achieve isolation via EVPN instances. If forwarding between different subnets are not desired, then one can configure it as such. As the matter of fact, the default configuration is that unless one configures IRB functionality to allow forwarding among selected subnets.

Even though you only allow NVEs to route traffic among IP subnets belonging to one customers, those NVEs basically merge multiple virtual network instances to one, which might not be the desired behavior by the customer.

We have complete flexibility on inter-subnet switching among different VNs (represented by different VNIs). The operator can decide for what VNs to enable or disable (by default) IRB functions.

Cheers,
Ali

Linda



From: Lucy yong
Sent: Thursday, February 28, 2013 1:48 PM
To: '[e-mail]<mailto:'[e-mail]>'
Subject: comment on draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-01

Hello Ali and All,

I have read this draft and have some comments. As you may know or not, I have been thinking and working on this topics since writing nvo3 use case draft (draft-ietf-nvo3-use-case) and nvo3 framework and data plane addition (draft-yong-nvo3-frwk-dpreq); glad to see you have drafted the solution document now and wish to work with you all on this draft as a co-author.

Here are some major comments:


·        Case 2 is about interconnecting DC infrastructure via WAN, where DC operator can build one IP VPN that contain multiple IP subnets. I think this is the carrier’s carrier case in section 9 in rfc4364, not inter-as case specified in current document. In addition, there are two options for this case, one is used of routing aggregation, anther one is without routing aggregation. Both let PE not maintain host/vm specific addresses in forwarding path and DC operator to build an IP VPN over WAN without WAN SP awareness.

·        Case3 may also implemented in following way, which should be documented too.

            NVE1            GW1             GW2            NVE2
      +------------+  +------------+  +------------+  +------------+
      | ...   ...  |  | ...   ...  |  |    ...     |  | ...   ...  |
      |(EVI)-(VRF) |  |(EVI)-(VRF) |  |   [LS ]    |  |(VRF)-(EVI) |
      | .|.|       |  | .|.   .|.  |  |   |...|    |  | ...   |..| |
      +------------+  +------------+  +------------+  +------------+
         ^ v             ^     V          ^   V               ^  V
         | |             |     |          |   |               |  |
   VM1->-+ +------>------+     +----------+   +---------------+  +->-VM2

  Figure 4b: Inter-Subnet Forwarding Among E-VPN NVEs in Different DCs
   with Route Aggregation


·        Case 4 may also implemented in following way, which should be documented too.

            NVE1            GW1             ASBR           NVE2
      +------------+  +------------+  +------------+  +------------+
      | ...   ...  |  | ...   ...  |  |    ...     |  |        ... |
      |(EVI)-(VRF) |  |(EVI)-(VRF) |  |   [LS ]    |  |       (VRF)|
      | .|.|.      |  | |.    .|   |  |   |...|    |  |       |..| |
      +------------+  +------------+  +------------+  +------------+
         ^ v            ^      V          ^   V               ^  V
         | |            |      |          |   |               |  |
   VM1->-+ +------>-----+      +----------+   +---------------+  +->-H1
  Figure 5b: Inter-Subnet Forwarding Among IP-VPN Sites and E-VPN NVEs
   with Route Aggregation


·        Document assume that host/vm send inter subnet packet to the MAC address of IRB. But does not mention how that may happen, i.e. via configuration the gateway MAC address on host/vm or via the protocol such as ARP or DHCP.  IMO: it need to describe it.

·        It is not clear to me if the VNID is per EVPN instances or per IP VPN? If it is former, each subnet, i.e. EVPN instance has its own VNID, NVE may also need to convert the VNID for inter subnet forwarding.

·        The term “EVPN site” is used in this document, the site has been used in VPN technology a lot and has some notion to link the physical location. But I don’t know that this document has that notion, it is virtual site, i.e. EVPN site may spread among many servers. Is that right?

Like to hear from you on these.

Regards/Thanks,
Lucy