Re: Interest in IS-IS VPLS

[Aldrin Isaac <[e-mail]>]

Hi Linda, in my rush I didn't explain it properly.  A better explanation can be found here http://en.wikipedia.org/wiki/Private_VLAN.  Best -- aldrin


On May 8, 2012, at 10:54 AM, Linda Dunbar wrote:

> Isaac, 
> 
> I thought that is why "Private VLAN" is introduced. 
> You can put the pair of firewalls in "private VLAN" and create a group of regular VLANs (with each VLAN mapped to /xx, and  xx >24). 
> This group of VLANs can access the "private VLAN". Is it correct?
> 
> Thanks for the example.
> 
> Linda
> 
>> -----Original Message-----
>> From: Aldrin Isaac [mailto:[e-mail]]
>> Sent: Monday, May 07, 2012 11:05 PM
>> To: Linda Dunbar
>> Cc: Lucy yong; [e-mail]; sajassi
>> Subject: Re: Interest in IS-IS VPLS
>> 
>> 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
>>>>>> 
>>>>> 
>>> 
>