The MPLS-OPS Archive

[Irwin Lazar <ilazar@mplsrc.com>]

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