RE: Interest in IS-IS VPLS

[Linda Dunbar <[e-mail]>]

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
> >>>>
> >>>
> >