The MPLS-OPS Archive

[Christopher Lewis <chrlewis@cisco.com>]

I'd just like to add some further comment :-)

Connecting enterprise CEs in a full mesh of L2 connections proves 
burdensome to the enterprise IGP for anything other than small L2 VPNs, my 
belief is that this is what stops enterprises from deploying full meshes at 
L2 as much as the cost for those full meshes of VCs. 50 sub-interfaces on 
the WAN side of a CE all running OSPF and flooding the one physical link is 
a challenge for typical deployments, particularly if the hello timers are 
tuned down to improve convergence.

VPLS on the other hand could potentially simplify this by making the WAN 
interfaces on all a given VPN CEs be on the same subnet and the burden of 
packet replication is moved to the PE (using bridged encap between the CE 
and PE).

I am familiar with the one implementation of Kompella auto-provisioning L2 
VPNs that Kireeti mentions below and agree that this is a valid service 
offering. It is not a replacement for all existing F/R network services 
(and the provider in question did not market it as such), it is a class of 
service that does not offer differential QoS on the attachment VCs. The 
provider saw it as a lower cost F/R service to offer to customers that were 
willing to go with no QoS guarantees.

Cheers

Chris

At 11:06 AM 5/15/2002, Jim Guichard wrote:
>One point to add below ..
>
> > >-----Original Message-----
> > >From: Irwin Lazar [mailto:ilazar@mplsrc.com]
> > >Sent: Wednesday, May 15, 2002 10:00 AM
> > >To: mpls-ops@mplsrc.com
> > >Subject: [MPLS-OPS]: Fwd: Re: Why martini over kompella
> > >
> > >
> > >FYI - From Kireeti Kompella himself:
> > >
> > >-------------
> > >
> > >>If one of the Kompellas may be allowed to answer ...
> > >>
> > >>Several of you got it right (nearly), which is very comforting.
> > >>Mark's point re building p2p circuits vs. building VPNs is a good
> > >>high-level answer.
> > >>
> > >>As Robert indicated, the bottom line is, do you want to signal your
> > >>VPNs with targeted LDP or with BGP?  Many vendors think BGP is really
> > >>hard to implement and LDP is a breeze, and thus go for implementing
> > >>martini.  One can question the validity of this argument, but the
> > >>results are what you see.
> > >>
> > >>However, there are a few vendors besides the company I work for who
> > >>aren't afraid of implementing BGP-based solutions; one of them
> > >>recently demonstrated interoperability with Juniper.
> > >>
> > >>So, why BGP instead of LDP?  BGP does auto-discovery; LDP doesn't.
> > >>This makes a huge difference to the task of provisioning VPNs.
> > >>
> > >>BGP is also better suited to building largish VPNs -- with LDP, the
> > >>protocol state maintained in the network, the number of targeted LDP
> > >>sessions, etc. all get pretty large pretty quickly [O(N**2)].  With
> > >>BGP, the protocol state in the network is O(N); and one can use route
> > >>reflectors and/or confeds to keep the number of sessions at O(N).
> > >>Finally, if one is interested in building inter-AS/inter-provider
> > >>VPNs, BGP is a clear winner.
>
>I do not think that this is comparing apples to apples - directed LDP has to
>distribute information to a particular endpoint for a given attachment VC
>whereas BGP wants, by default, to distribute the information to everyone. So
>although there will be a larger number of directed LDP sessions than BGP
>sessions (with RRs), the amount of information that must be carried by the
>directed LDP sessions is by no means the same as BGP sessions. This means
>that the scaling implications are not the same as with BGP. Jim
>
> > >>
> > >>(Yes, I've heard people propose LDP route reflectors; also to endow LDP
> > >>with communities.  What next? eLDP and iLDP?  LDP path attributes?)
> > >>
> > >>Finally, if "network convergence" isn't just a pipe dream, and one
> > >>was to offer both 2547 VPNs and L2 VPNs, it makes sense to use one
> > >>methodology -- and BGP-based L2 VPNs are fairly close to 2547 VPNs,
> > >>simplifying provisioning, monitoring and maintenance.
> > >>
> > >>Christopher is probably right that "over 80% of todays L2 networks
> > >>that use frame relay or ATM connections, the SP provided connectivity
> > >>is not full mesh", but from what I've heard, this is primarily because
> > >>it is so expensive to provision a full mesh ATM or FR VPN.  BGP
> > >>makes provisioning a full mesh simple, and a hub-and-spoke almost
> > >>as simple.  So, the real question is, what do VPN customers want?
> > >>Or does that not matter any more?
> > >>
> > >>One of the SPs that has deployed BGP based L2 VPNs offers their
> > >>customers full mesh VPNs.  The customer is then free to define their
> > >>own topology on top of this.  What this means is that the customer
> > >>can change their VPN topology without any changes on the part of
> > >>the SP -- pretty neat feature at a fairly low cost!
> > >>
> > >>To respond to Daniel's comment:
> > >>
> > >>"To answer the original question - vendors have chosen to implement
> > >>  Martini because it's more or less finished and everyone can agree on
> > >>  what Martini VPN is and you get cross-vendor interoperability.
> > >>  Multipoint VPNs are still in quite a bit of flus.  In fact, if you
> > >>  look at the web page for the ppvpn group, you'll see that none of the
> > >>  various "Kompella drafts" are current."
> > >>
> > >>it's worthwhile considering what the "finished" and "current" states
> > >>of a draft mean.  The martini drafts are very much in a state of flux --
> > >>they were to be published as Informational RFCs, then as Proposed
> > >>Standards, then as Experimental.  Finally, they were pulled out of the
> > >>standards process, and are again *individual submissions* (i.e., not
> > >>WG documents in any WG).  What Daniel probably meant is that the
> > >>drafts' *content* is stable, which is true.
> > >>
> > >>The kompella drafts are current Internet Drafts, but are not PPVPN WG
> > >>documents (nor any other WG documents).  The contents have been
> > >>stable for a while now, and there are interoperable implementations,
> > >>but not nearly as many as for martini.
> > >>
> > >>Hope that helps,
> > >>Kireeti.
> > >
> > >-------
> > >The MPLS-OPS Mailing List
> > >Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> > >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
>
>-------
>The MPLS-OPS Mailing List
>Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
>Archive: http://www.mplsrc.com/mpls-ops_archive.shtml

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml