RE: Interest in IS-IS VPLS

[Lucy yong <[e-mail]>]

Hi Aldrin,

I got it. Thanks a lot.

Interconnecting private LANs and Community LAN is the application for E-Tree, where private LAN set as leaf AC and Community LAN set as root AC. Of course, policy based-topology can support other more sophisticated scenarios.

Lucy



-----Original Message-----
From: Aldrin Isaac [mailto:[e-mail]] 
Sent: Monday, May 07, 2012 11:00 PM
To: Lucy yong
Cc: sajassi; Giles Heron; Nabil Bitar; [e-mail]
Subject: Re: Interest in IS-IS VPLS

Hi Lucy, see in line.


On May 7, 2012, at 11:19 AM, Lucy yong wrote:

> Hi Aldrin,
> 
> Thank you very for sharing your insight. It is great and very helpful. It is fine to add new service features on existing services. In fact, that is what we are working on in IETF.  
> 
> From customer perspective, E-VPN supports all existing VPLS capability and add active-active mode and some policy based-topology control. It is useful extension. SPT based LAN is the history technology. LAG, MSTP, TRILL, SPB etc are all the replacement solutions. 
> 
> One thing that I am not clear from your reply is that the policy for L2VPN is to be against VLAN or MAC?
> The latter will be very complex and not scale. The former will have some additional challenges and complex because VLAN ID may not be global based ID like IP addresses and L2VPN forwarding is based on MAC address while policy control is based on VLAN. Do I understand this right?

Policy is applied to the EVI (VRF) table which applies to all route types in the table.  An EVI can have a single link or be shared by multiple links.  The tag with which a packet arrives into the network does not have to be the tag with which it leaves the network.  I.e. destination tag and ingress tag are decoupled in EVPN.

> IMO: simplification is also important work for IETF and benefit to businesses as silicon technology improving. Without it, we have some limited room for adding new useful features and the system will be overly complex so nobody can afford operating it. This does not say E-VPN.

For operators who want simplicity, they can get this easily by moving compute/storage to hypervisors and buying an overlay solution -- it's available today commercial or free.  It's the cheapest and easiest to implement out of the box with little to no knowledge of networking protocols.  I'm observing sysadmin and security guys set this up today (literally).

> Thanks again.
> 
> Lucy
> 
> 
> 
> 
> -----Original Message-----
> From: Aldrin Isaac [mailto:[e-mail]] 
> Sent: Friday, May 04, 2012 7:20 PM
> To: Lucy yong
> Cc: sajassi; Giles Heron; Nabil Bitar; [e-mail]
> Subject: Re: Interest in IS-IS VPLS
> 
> Hi Lucy,
> 
> Please see inline
> 
> On May 4, 2012, at 11:07 AM, Lucy yong wrote:
> 
>> Hi Isaac,
>> 
>> Thank you for the reply. Please see inline.
>> 
>> Regards,
>> Lucy
>> 
>> -----Original Message-----
>> From: Aldrin Isaac [mailto:[e-mail]] 
>> Sent: Thursday, May 03, 2012 10:50 PM
>> To: Lucy yong
>> Cc: sajassi; Giles Heron; Nabil Bitar; [e-mail]
>> Subject: Re: Interest in IS-IS VPLS
>> 
> 
> ... 
> 
>> E-VPN also supports policy based-topologies versus simple point-to-point, flat or tree VLANs.  It can support point-to-point, tree, mesh, one-way, or pretty much any other "complex" or overlapped topologies (depending on how you like to see it).  An example is ability to natively recreate private vlan, community vlan topologies (which happen to be quite common in DC networks) and any number of combinations of these simultaneously to a single port.  A BGP E-VPN VPN is also decoupled from the edge EVI/ESI such that it is not limited to a single tenant/vlan but can span tenants/vlans (l2 extranet) if so required.  This is native to E-VPN.
>> [[LY]] Such policy based-topologies are useful for service provider network, but may too complex for intra DCs. One reason that customers often want to choose with L2VPN service is "it is simple". However, L3VPN have its applications although some operators often complain the complexities to configure these policies. Typical example is the a firewall only placed at a location. Could you share why operator want such policy based-topology for L2VPN?
> 
> Policy-based topologies are generally complex when used to interconnect IP networks because there are generally multiple prefixes in a vrf, and often different prefixes need to be associated to different VPNs or routing behavior.  In the DC, L2VPN role is to interconnect host ports so the policies for basic are very simple --- list of import route targets and list of export route targets where each import/export pair correspond to a VPN (tenant, service, ...).  An example of how a DC operator might use this for example is to meet a requirement for private vlan and community vlans which are very common for DMZs.  Hopefully you are familiar with these very common use cases.  It is even possible to recreate more complex switch "features" like MVR (in addition to private VLANs which are also considered "features") using E-VPN.  It took me three years to get the MVR feature into a particular vendor's switch to meet a business need.  I'll sacrifice plug-and-play simplicity for business agility.  I'm sure my peers are with me on this one.
> 
> If simple "plug-and-play" is important, one could imagine RRs sending out an "RR TLV" such that RRs in an IGP area auto-connect with each other and RR-clients connect to the closest RR based on SPF (some details like peer-group, etc would need to be factored in to make it more powerful).  Other BGP/MPLS configuration is, IMHO, trivial unless you CHOOSE to use more advanced capabilities (i.e. not locked in).  
> 
> Maybe the reason why MPLS comes across as complex is because of how IETF deals with requirements lately by creating point solutions.  E-VPN tries to put new capabilities on the table while trying not to take existing value off the table.  There is no reason why a solution can't bring more value than what the standards body calls for.
> 
>> E-VPN supports interconnecting end-stations or interconnecting L2 networks.  Procedures to easily span STP based networks across an E-VPN network without loops comes with the base spec.  Extensions to E-VPN, such as PBB-EVPN, simplify the fully functional spanning of non-EVPN networks across an E-VPN network.
>> [[LY]] current L2VPN support all these except active-active mode which causes the loop.
> 
> Base E-VPN spec will natively deal with the STP case through an active/standby mode and BPDU-snooping -- detect root bridge and use that as ESI (ethernet segment id) to indicate unique STP network with active/standby bit set to ensure only one forwarding link among links with same ESI.  Tags (vlans) can potentially each have a different active link within the member links of an ESI allowing for automatic tag(tenant)/vlan level load-balancing into an STP network.  Edge networks that don't have mac-move issue will be able to take full advantage of active-active load-balancing without need for LAG/MLAG.
> 
>> An SVI/IRB interface can also be a member of both an E-VPN EVI and an IP VRF allowing for easily bringing together virtual L2 and L3 topologies anywhere in the network without a physical port.
>> [[LY]] Could you please share how operator plan to use this? Which service will you sell to customer in this case?
> 
> The service will be where a customer wants to communicate to a destination network that is not in his subnet.  Operators most interested in EVPN already have IPVPN services on their network.  This is the gateway point between the EVPN virtual networks and [existing] IPVPN virtual networks.  No physical port required.
> 
>> E-VPN builds on top of years of work in the IETF; traffic engineering, scaling with route reflectors and RT constrain, multicast via NG-MVPN, etc.
>> [[LY]] Agree. These are useful features for service provider network. However, these functions may not necessary within DC although they had been proved works well. 
> 
> I'm not sure how eventually re-inventing these capabilities (yes it will happen) on behalf of a new protocol will be better than simply leveraging proven technology.  Vendors don't need to implement every MPLS RFC ever written to be able to implement the basic E-VPN.
> 
>> Can also use IP for transport tunnel.  But my understanding is that popular merchant silicon has support for MPLS push/pop/swap these days (?).  This was captured by EVPN at it's inception, which is why the PE is referred to as MES (MPLS-enabled switch) in E-VPN.
>> [[LY]] Yes, current draft aims on MPLS solution only. But it states the potential to extend to the use of IP tunnel. 
>> The way I see it, a major reason why STP-based LANS are fickle and don't scale well is on account of insufficient decoupling of core from edge created by requirement for plug-and-play and how that played out over time.  Conversely the reason (among other things) why IP networks are more stable is because they are not inherently plug-and-play, and with MPLS/BGP allows excellent decoupling of core and edge.  I don't know enough about TRILL or PBB to comment on those -- I just know that I'm not interested for enough good reasons.  E-VPN enables a dynamic edge over a stable decoupled core while giving each operator room for service differentiation.  It is especially interesting to operators that have invested in MPLS technology and operations.  I can find a lot of folks that understand BGP/MPLS IPVPN and in short order have them know the ins and outs of basic E-VPN.  It's quite hard for me to find non-vendor folk who really actually understand the other technologies used to span Ethernet aside from basic STP. 
> 
>> [[LY]] Thank you to share this in the mailing list. 
>> 
>> This is an operator perspective.
>> [[LY]]  This is great!
>> 
>> 
>> On May 3, 2012, at 4:31 PM, Lucy yong wrote:
>> 
>>> Hi Ali,
>>> 
>>> 
>>> "5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that
>>> emulates an Ethernet (V)LAN across a PSN. E-VPN supports
>>> load-sharing across multiple connections from a Layer-2 site
>>> to an L2VPN service. E-VPN is primarily targeted to support
>>> large-scale L2VPNs with resiliency requirements not satisfied
>>> by other L2VPN solutions"
>>> 
>>> [[LY]] IMO, E-VPN enhancement is to support multi-homing with active-active mode. Load-sharing across multiple connections from a layer-2 site is desired when this mode is used. Current VPLS can provide resiliency requirement when the multi-homing site configured with active-standby mode.
>>> 
>>> Regards,
>>> Lucy
>>> 
>>> Cheers,
>>> Ali  
>>> 
>> 
>