Subject: [armd] ARMD problem space & existing standards

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 17 Aug 2011 18:27:12 -0500

The discussion on ARMD problem space seem to gravitate around the issues basic VLAN deployments had in the past with flood containment. Before starting new protocol work maybe we should pause and start from what is missing in the latest IEEE/IETF technologies when it comes to addressing these issues.

Here is a list of existing standards I am familiar with that are deployed in large Service Provider Ethernet Networks where we had to deal with similar issues:

-      IETF-L2VPN WG VPLS/PBB-VPLS - "core tunneling" can be MPLS or IP-only, VPN "shim" is the ISID and/or PW label.

-      IEEE 802.1ah PBB - "core tunneling" is based on native Ethernet switching; VPN "shim" is the ISID 24 bit tag; may be transported over the above VPLS tunnels (see IETF PBB-VPLS work).

Also there are additional initiatives in IEEE and IETF to add DC oriented features (e.g. Multi-pathing and control plane alternative to MAC learning) - see IETF L2VPN EVPN, PBB-EVPN drafts and IEEE 802.1aq SPBM (PBB).

This is not a comprehensive list, just an example of possible ways to address the issues without reinventing the wheel.

A basic function of these solutions is that any flooded packet is delivered through the core efficiently only to the edge switches and server blades that have at least an interested VPN endpoint (VM). The service auto-discovery component provides on demand service connectivity only between the interested endpoints (e.g. Server Blades/VMs) inside or across DCs. So these solutions have the potential to address in my opinion the DC wide flooding.

If further flood optimization inside an individual tenant domain is required, the procedures in draft-wkumari-dcops-l3-vmmobility-00.txt may be used also with these technologies: e.g. the mapping server approach can map VM MACs to the above shims + Tunnels as an alternative to regular IEEE MAC Learning.

The discussion in draft-wkumari on separation of VM addressing between tenants and from the DC internal addressing highlights also a very important requirement that needs to be addressed for true isolation between tenants. But this could be achieved by re-using the existing VPN standards - this is a fundamental principle that was addressed already in the existing encapsulations. In addition the core tunneling is based on Service Provider addressing.

Sorry for the long email. I am hoping people new to VPN work will benefit as much as we benefited from the good information on DC requirements.

Florin

---

From: Aldrin Isaac <[email-masked]>
Date: Wed, 17 Aug 2011 23:17:26 -0400

IMHO, the additional initiatives that Florin describes in his email if implemented at (or near) the access switch and coupled with evolving standards such as VEPA and SRIOV technology and existing control plane scaling options (ex: scalable route reflector design, ORF, etc) could provide a VM-to-VM/end-to-end solution that scale well and enable extremely flexible virtual topologies without the need for an additional overlay.  -- aldrin

On Aug 17, 2011, at 7:27 PM, Balus, Florin Stelian (Florin) wrote:

> -      IETF-L2VPN WG VPLS/PBB-VPLS – “core tunneling” can be MPLS or IP-only, VPN “shim” is the ISID and/or PW label.
> -      IEEE 802.1ah PBB – “core tunneling” is based on native Ethernet switching; VPN “shim” is the ISID 24 bit tag; may be transported over the above VPLS tunnels (see IETF PBB-VPLS work).
>  
> _______________________________________________
> armd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/armd

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 18 Aug 2011 15:07:09 +0000

Thanks Florin for pointing out L2VPN & IEEE802.1ah Overlay Network. There is also TRILL encapsulation. All of these encapsulation schemes, including the IP encapsulation introduced by "draft-wkumari-dcops-l3-vmmobility-00", achieve the goal of hiding individual hosts' (or VMs) addresses from the backbone network.

All of these encapsulation overlay mechanisms face the common challenge in Data Center: edge node of the overlay network has to maintain very large mapping for all remote hosts <-> their corresponding Edge nodes.
The more number of hosts attached to Overlay Network Edge nodes, the more mapping has to be maintained by the Edge nodes. The goal of ARMD is to identify those problems. ARMD is not to introduce another encapsulation scheme.

"draft-wkumari-dcops-l3-vmmobility-00" introduces "Mapping Server" to solve this problem. http://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-edge/ introduces the Directory Server to solve the problem for TRILL.
Then there is a need for directory assistance for IEEE802.1ah, or other encapsulation schemes in Data Center because the massive number of hosts. It may be better for the industry to have a common approach on how Edge node can get assistance from directory servers.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Aldrin Isaac
Sent: Wednesday, August 17, 2011 10:17 PM
To: Balus, Florin Stelian (Florin)
Cc: [email-masked]
Subject: Re: [armd] ARMD problem space & existing standards

Florin

_______________________________________________
armd mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/armd

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Thu, 18 Aug 2011 11:30:45 -0500

What I listed in my email is a list of standards that were developed to work together in L2VPN and in sync with IEEE specification (encapsulation/tunneling/VPN shim). This is valuable development especially for inter-DC/VPN-tenant connect since it interoperates with what is already deployed.

Any new encapsulations for DC space should to go through the same kind of L2VPN interop discussion/scrutiny since the requirements at least for DC interconnect are similar with what we saw in L2VPN in the past. We need to ensure there is a good reason to introduce new VPN shims. I would say the same thing applies to the native Ethernet space - IEEE 802.1 Task Force should get a liaison every time we try to invent new Ethernet VPN shim - see discussion we had in TRILL on two VLAN tags as VPN shim. IEEE already provided ~ 4 years ago an evolution of the 12 bit VLAN tag to 24 bit PBB ISID tag and the appropriate encapsulation hierarchy to hide the (VM) MACs from the backbone nodes.

New control planes/server driven networking should re-use as much as possible the existing encaps to simplify at least the forwarding options.

See also in-line...

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, August 18, 2011 8:07 AM
To: Aldrin Isaac; Balus, Florin Stelian (Florin)
Cc: [email-masked]
Subject: RE: [armd] ARMD problem space & existing standards

FB> I assume that by Edge nodes you mean the place where the overlay tunnel starts... When I wrote the initial email I had in mind what the overlay solutions are generally trying to address: allow a L2 tenant domain (ELAN) with hosts distributed across a large backbone domain with scalable tunneling, usually using routing protocols in the control plane. In DC talk that means related hosts can be distributed anywhere inside or across DCs while containing the amount of flooding/solving DC wide flooding. Implicitly this means server blades are not bombarded with ARP/ND requests from any unrelated server blade (from outside their tenant domain).

If the issue is the number of hosts per VPN - i.e. a server blade has 32 VMs every one with its own L2 tenant domain and every domain with X hosts - there are different issues one might try to solve:

-      Further optimize flooding per tenant domain and processing of ARP/ND requests at the receiving end by cutting the initiation of flooded traffic at the source: i.e. eliminate ARP transmission/MAC learning through Mapping server/Directory etc...

-      X*32 >> host entries the server blade can handle - not sure what can be done about this in the network? One either needs to add memory in the server blade or just don't do it as the DC guys said in the ARMD session. The solution is proper planning of the average number of hosts per L2 domain (i.e. one may allow a large number for some L2 domains but not for all)/drop a VRF (routing) instance when needed. Same discussion applies at a different scale if your edge node is the ToR. Most of the VPLS/PBB implementations I am aware of have per VPN/tenant and per interface enforcement of the number of hosts (MAC addresses, flooded/mcast traffic) to ensure the proper engineering.

Linda

Florin

---

From: Phil Bedard <[email-masked]>
Date: Thu, 18 Aug 2011 13:45:28 -0400

I think the issue thus far is implementing this in access switches
close to the hosts...

These are all technologies used to enhance the scale of L2 topologies.
 The Google case in one where I believe there is a L3 IP hop between
the two VM hosts which necessitates tunneling.  In order for VMs to
retain their connectivity the L2 has to be dynamically tunneled over
L3 from server to server and gateway to server.  In a L2 network you
need  to reconfigure the upstream switch port when a VM moves or
preconfigure ports.   I see extensions to LLDP like VEPA/multichannel
which may allow more dynamic reconfiguration without a management tool
having to reconfigure the upstream network device.

With regards to ARP scale, whether emulated via VPLS or native, there
are probably multiple solutions.  ARP snooping is probably not a
difficult operation since most do it today for IGMP and/or PIM and
many devices perform proxy-arp.

I mentioned Ethernet VPN earlier as a solution which can be
implemented with a scalable protocol like BGP to push MAC information
or one could alternatively use a directory lookup instead.   EVPN I
believe has a provision to perform ARP snooping.

Phil

On 8/17/11, Balus, Florin Stelian (Florin)
<[email-masked]> wrote:
> The discussion on ARMD problem space seem to gravitate around the issues
> basic VLAN deployments had in the past with flood containment. Before
> starting new protocol work maybe we should pause and start from what is
> missing in the latest IEEE/IETF technologies when it comes to addressing
> these issues.
>
> Here is a list of existing standards I am familiar with that are deployed in
> large Service Provider Ethernet Networks where we had to deal with similar
> issues:
>
> -      IETF-L2VPN WG VPLS/PBB-VPLS - "core tunneling" can be MPLS or
> IP-only, VPN "shim" is the ISID and/or PW label.
>
> -      IEEE 802.1ah PBB - "core tunneling" is based on native Ethernet
> switching; VPN "shim" is the ISID 24 bit tag; may be transported over the
> above VPLS tunnels (see IETF PBB-VPLS work).
>
> Also there are additional initiatives in IEEE and IETF to add DC oriented
> features (e.g. Multi-pathing and control plane alternative to MAC learning)
> - see IETF L2VPN EVPN, PBB-EVPN drafts and IEEE 802.1aq SPBM (PBB).
>
> This is not a comprehensive list, just an example of possible ways to
> address the issues without reinventing the wheel.
>
> A basic function of these solutions is that any flooded packet is delivered
> through the core efficiently only to the edge switches and server blades
> that have at least an interested VPN endpoint (VM). The service
> auto-discovery component provides on demand service connectivity only
> between the interested endpoints (e.g. Server Blades/VMs) inside or across
> DCs. So these solutions have the potential to address in my opinion the DC
> wide flooding.
>
> If further flood optimization inside an individual tenant domain is
> required, the procedures in draft-wkumari-dcops-l3-vmmobility-00.txt may be
> used also with these technologies: e.g. the mapping server approach can map
> VM MACs to the above shims + Tunnels as an alternative to regular IEEE MAC
> Learning.
>
> The discussion in draft-wkumari on separation of VM addressing between
> tenants and from the DC internal addressing highlights also a very important
> requirement that needs to be addressed for true isolation between tenants.
> But this could be achieved by re-using the existing VPN standards - this is
> a fundamental principle that was addressed already in the existing
> encapsulations. In addition the core tunneling is based on Service Provider
> addressing.
>
> Sorry for the long email. I am hoping people new to VPN work will benefit as
> much as we benefited from the good information on DC requirements.
>
> Florin
>
>

-- 
Sent from my mobile device

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Thu, 18 Aug 2011 15:43:03 -0500

Thanks Phil for the comments. See in-line...

-----Original Message-----
From: Phil Bedard [mailto:[email-masked]] 
Sent: Thursday, August 18, 2011 10:45 AM
To: Balus, Florin Stelian (Florin); [email-masked]
Subject: Re: [armd] ARMD problem space & existing standards

FB> When it comes to internal DC network I understand VLANs/Ethernet switching are usually used in access switches (ToRs). Backbone Ethernet tunneling was developed by IEEE to maintain the same basic procedures and as far as I know the chipsets built for these kind of devices support both TRILL and PBB.

FB> maybe a better way to put it is these technologies allow related L2 switching instances to be located far away from each other, across one or a combination of L2 or L3 (IP/MPLS) backbones. There are metro, national and even intercontinental deployments of these technologies.

 The Google case in one where I believe there is a L3 IP hop between
the two VM hosts which necessitates tunneling.  In order for VMs to
retain their connectivity the L2 has to be dynamically tunneled over
L3 from server to server and gateway to server.  

FB> I understand there is value in re-using the VLAN + IP routing environment. That was the whole point of PBB-VPLS model and interop work in L2VPN: to allow a similar (Backbone) VLAN + (IP or MPLS) tunnel combination. 

In a L2 network you need  to reconfigure the upstream switch port when a VM moves or
preconfigure ports.   I see extensions to LLDP like VEPA/multichannel
which may allow more dynamic reconfiguration without a management tool
having to reconfigure the upstream network device.

FB> Yes there is some discussion on ARP containment in EVPN draft - see section 13 in http://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-01 ...

Phil

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 19 Aug 2011 07:12:23 +0200

Sorry, to join the discussion a bit later. 

Below is also a draft (written by Rahul and a little bit of me) which can also be referenced in this discussion. It is identifying some solution for potential issues in the DC.
http://tools.ietf.org/html/draft-raggarwa-data-center-mobility-00

-----Original Message-----
From: Phil Bedard [mailto:[email-masked]] 
Sent: Thursday, August 18, 2011 10:45 AM
To: Balus, Florin Stelian (Florin); [email-masked]
Subject: Re: [armd] ARMD problem space & existing standards

Phil

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 19 Aug 2011 11:43:27 -0400

> I think the issue thus far is implementing this in access switches

This seems correct to me, though there's likely some pain on the first
L3 hop in the DC as well. It seems that once you step out of the
immediate L2 domain, normal backbone routing things are still fine in
v4/v6. You MAY have issues wrt routing scale, but of course you have
those anyway.

The particular problem(s) that ARMD was/is looking at are the scaling
properties of the edge nodes (access-switch, TOR, first L3 hop,
server-side), and how those interact in a much larger potential L2
domain. Today, for instance, in a normal DC, a single rack is
potentially it's own L2 domain (there are lots of architectures, let
us keep it simple though). That domain, in v4, is contained and
relatively small (/24 or smaller). In v6 though, that domain is
potentially much larger (/64 default deployments for lots of reasons).

Hosts on the /24-equivalent can only make so many ARP requests, the
network gear has only to cache a limited number of entries, and things
'just work'.

Hosts on a /64 though, or a larger flat L2 deployment, see much more
ARP traffic, the associated network gear has to maintain larger
queues/caches and deal with a larger flow of ARP/etc requests. The
pathway from line-port to routing-engine/route-processor/smarts in a
network device are severely constrained (as compared with the
line-port -> line-port speeds/pathways). As gear gets toward the
less-expensive range, it also gets less capable in this respect.
Scaling up to multiple /24's of space across a distributed L2 is ....
much harder to deal with, traffic-to-cpu wise. Additionally, less
expensive devices are generally not fortified with faster/more-capable
cpus.

The drive to lower costs in the DC (cheaper network deployments, more
vm-guests's per vm-host, etc is exacerbating this problem, or so it
would seem, in a large flat L2 network.

> These are all technologies used to enhance the scale of L2 topologies.

the breadth, they aren't really necessary for 'scale'... you can just
connect lots of L2 switches into a large SCALE LAN, but making it work
across the wide-area is where the above comes into play. (work WELL at
least)

> FB> maybe a better way to put it is these technologies allow related L2 switching instances to be located far away from each other, across one or a combination of L2 or L3 (IP/MPLS) backbones. Ther…

right, breadth, not 'scale' (distance not numbers)

> many devices perform proxy-arp.

arp snooping and the like work today on smaller deployments
(numbers-wise) they probably have severe challenges when you attempt
to scale up the number of arping nodes downstream from a port on a
switch though. You get to some of that (florin) in the discussion of
numbers three messages previous.

-chris

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 19 Aug 2011 10:58:42 -0500

Florin,

See my comments inserted below:

On Thu, Aug 18, 2011 at 11:30 AM, Balus, Florin Stelian (Florin) <
[email-masked]> wrote:

>  What I listed in my email is a list of standards that were developed to
> work together in L2VPN and in sync with IEEE specification
> (encapsulation/tunneling/VPN shim). This is valuable development especially
> for inter-DC/VPN-tenant connect since it interoperates with what is already
> deployed.
>
[Linda] Agree with you 100%.

>  ****
>
> ** **
>
> Any new encapsulations for DC space should to go through the same kind of
> L2VPN interop discussion/scrutiny since the requirements at least for DC
> interconnect are similar with what we saw in L2VPN in the past. We need to
> ensure there is a good reason to introduce new VPN shims.
>

[Linda] Thank you for pointing this out. I agree with you. There are so many
enapsulation schemes already (802.1h's MACinMAC, VPLS, TRILL. etc).

>  I would say the same thing applies to the native Ethernet space - IEEE
> 802.1 Task Force should get a liaison every time we try to invent new
> Ethernet VPN shim – see discussion we had in TRILL on two VLAN tags as VPN
> shim. IEEE already provided ~ 4 years ago an evolution of the 12 bit VLAN
> tag to 24 bit PBB ISID tag and the appropriate encapsulation hierarchy to
> hide the (VM) MACs from the backbone nodes.****
>
> ** **
>
> New control planes/server driven networking should re-use as much as
> possible the existing encaps to simplify at least the forwarding options.*
> ***
>
> ** **
>
> See also in-line…****
>
> ** **
>
> *From:* Linda Dunbar [mailto:[email-masked]]
> *Sent:* Thursday, August 18, 2011 8:07 AM
> *To:* Aldrin Isaac; Balus, Florin Stelian (Florin)
> *Cc:* [email-masked]
> *Subject:* RE: [armd] ARMD problem space & existing standards****
>
> ** **
>
> Thanks Florin for pointing out L2VPN & IEEE802.1ah Overlay Network. There
> is also TRILL encapsulation. All of these encapsulation schemes, including
> the IP encapsulation introduced by “draft-wkumari-dcops-l3-vmmobility-00”,
> achieve the goal of hiding individual hosts’ (or VMs) addresses from the
> backbone network. ****
>
> ** **
>
> All of these encapsulation overlay mechanisms face the common challenge in
> Data Center: edge node of the overlay network has to maintain very large
> mapping for all remote hosts <-> their corresponding Edge nodes. ****
>
> ** **
>
> The more number of hosts attached to Overlay Network Edge nodes, the more
> mapping has to be maintained by the Edge nodes. The goal of ARMD is to
> identify those problems. ARMD is not to introduce another encapsulation
> scheme. ****
>
> ** **
>
> “draft-wkumari-dcops-l3-vmmobility-00” introduces “Mapping Server” to solve
> this problem.
> http://datatracker.ietf.org/doc/draft-dunbar-trill-directory-assisted-edge/introduces the Directory Server to solve the problem for TRILL.
> ****
>
> Then there is a need for directory assistance for IEEE802.1ah, or other
> encapsulation schemes in Data Center because the massive number of hosts. It
> may be better for the industry to have a common approach on how Edge node
> can get assistance from directory servers.  ****
>
> ** **
>
> FB> I assume that by Edge nodes you mean the place where the overlay tunnel
> starts…
>

[Linda] Correct!

>  When I wrote the initial email I had in mind what the overlay solutions
> are generally trying to address: allow a L2 tenant domain (ELAN) with hosts
> distributed across a large backbone domain with scalable tunneling, usually
> using routing protocols in the control plane. In DC talk that means related
> hosts can be distributed anywhere inside or across DCs while containing the
> amount of flooding/solving DC wide flooding. Implicitly this means server
> blades are not bombarded with ARP/ND requests from any unrelated server
> blade (from outside their tenant domain).
>

[Linda] That was the initial intent of ARMD. But the statistics from Merit
Networks shows that the biggest pain is L2/L3 boundary router. IMO, both
ARP/ND caching and "Mapping Server" can alleviate this problem.

>  ****
>
> ** **
>
> If the issue is the number of hosts per VPN – i.e. a server blade has 32
> VMs every one with its own L2 tenant domain and every domain with X hosts –
> there are different issues one might try to solve:
>

[Linda] If there are 40 server blades per chassis, then there are 40*32 =
1280 VMs connected to one Blade switch. If the ToR has 40 downstream ports
connected to Blade Switch, then there are 40*1280 = 51200 VMs attached to
the ToR.

>  ****
>
> **-      **Further optimize flooding per tenant domain and processing of
> ARP/ND requests at the receiving end by cutting the initiation of flooded
> traffic at the source: i.e. eliminate ARP transmission/MAC learning through
> Mapping server/Directory etc…****
>
>
>
[Linda] Very good suggestion. draft-shah-armd-arp-reduction-01 and
draft-wkumari-dcops-l3-vmmobility-00 can achieve some of this. SEATTLE
proposes a Distributed Hashing scheme, which may scale better.

>  ****
>
> **-      **X*32 >> host entries the server blade can handle – not sure
> what can be done about this in the network? One either needs to add memory
> in the server blade or just don’t do it as the DC guys said in the ARMD
> session.
>
[Linda] I think the "mapping server" proposed by Warren's draft and SEATTLE
approach can solve this problem.

>  The solution is proper planning of the average number of hosts per L2
> domain (i.e. one may allow a large number for some L2 domains but not for
> all)/drop a VRF (routing) instance when needed. Same discussion applies at a
> different scale if your edge node is the ToR. Most of the VPLS/PBB
> implementations I am aware of have per VPN/tenant and per interface
> enforcement of the number of hosts (MAC addresses, flooded/mcast traffic) to
> ensure the proper engineering.****
>
> ** **
>
> ** **
>
> Linda****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Aldrin Isaac
> *Sent:* Wednesday, August 17, 2011 10:17 PM
> *To:* Balus, Florin Stelian (Florin)
> *Cc:* [email-masked]
> *Subject:* Re: [armd] ARMD problem space & existing standards****
>
> ** **
>
> IMHO, the additional initiatives that Florin describes in his email if
> implemented at (or near) the access switch and coupled with evolving
> standards such as VEPA and SRIOV technology and existing control plane
> scaling options (ex: scalable route reflector design, ORF, etc) could
> provide a VM-to-VM/end-to-end solution that scale well and enable extremely
> flexible virtual topologies without the need for an additional overlay.  --
> aldrin****
>
> ** **
>
> ** **
>
> On Aug 17, 2011, at 7:27 PM, Balus, Florin Stelian (Florin) wrote:****
>
> ** **
>
> these issues.****
>  ****
> Here is a list of existing standards I am familiar with that are deployed
> in large Service Provider Ethernet Networks where we had to deal with
> similar issues:****
>
> -      IETF-L2VPN WG VPLS/PBB-VPLS – “core tunneling” can be MPLS or
> IP-only, VPN “shim” is the ISID and/or PW label.****
>
> -      IEEE 802.1ah PBB – “core tunneling” is based on native Ethernet
> switching; VPN “shim” is the ISID 24 bit tag; may be transported over the
> above VPLS tunnels (see IETF PBB-VPLS work).****
>
>  ****
>
> - see IETF L2VPN EVPN, PBB-EVPN drafts and IEEE 802.1aq SPBM (PBB).  ****
>
>  ****
>
> address the issues without reinventing the wheel.****
>
>  ****
>
> wide flooding.****
>  ****
> Learning.****
>  ****
> addressing.****
>  ****
> Sorry for the long email. I am hoping people new to VPN work will benefit
> as much as we benefited from the good information on DC requirements.****
>
>  ****
>
> Florin****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/armd****
>
> ** **
>

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 19 Aug 2011 16:16:41 +0000

Chris, 

Thank you very much for the good description on pain points in DC networks. ARMD's first goal is to document all those pain points. 

Linda

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Friday, August 19, 2011 10:43 AM
> > FB> When it comes to internal DC network I understand VLANs/Ethernet
> switching are usually used in access switches (ToRs). Backbone Ethernet
> tunneling was developed by IEEE to maintain the same basic procedures
> and as far as I know the chipsets built for these kind of devices
> support both TRILL and PBB.
> >
> > FB> maybe a better way to put it is these technologies allow related
> L2 switching instances to be located far away from each other, across
> one or a combination of L2 or L3 (IP/MPLS) backbones. There are metro,
> national and even intercontinental deployments of these technologies.
> >
> 
> > FB> I understand there is value in re-using the VLAN + IP routing
> environment. That was the whole point of PBB-VPLS model and interop
> work in L2VPN: to allow a similar (Backbone) VLAN + (IP or MPLS) tunnel
> combination.
> >
> > FB> Yes there is some discussion on ARP containment in EVPN draft -
> see section 13 in http://tools.ietf.org/html/draft-raggarwa-sajassi-
> l2vpn-evpn-01 ...
> >
> > Phil
> >