Re: Interest in IS-IS VPLS

[Aldrin Isaac <[e-mail]>]

Linda,

Let me give a simple example.  If you have a DMZ with a public /24 address and you want to share that DMZ (one pair of firewalls to the Internet) with multiple different classes of applications that you want to keep isolated from each other.  Within each class the computers can communicate with each other and out to the Internet, but computers that are of different classes cannot communicate with one another.

-- aldrin


On May 7, 2012, at 5:29 PM, Linda Dunbar wrote:

> Adrin, 
> 
> You mentioned that " private vlan and community vlans which are very common for DMZs in Data Center". 
> 
> I can totally understand why "private vlan" being used. But what scenario will you need "community vlans" but can't be simply achieved by traditional VLANs? 
> 
> Thanks, Linda 
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Aldrin Isaac
>> Sent: Friday, May 04, 2012 7:20 PM
>> To: Lucy yong
>> Cc: [e-mail]; sajassi
>> 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
>>>> 
>>> 
>