The MPLS-OPS Archive

["Jim Guichard" <jguichar@cisco.com>]

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