The MPLS-OPS Archive

["Joe Lin" <jlin@doradosoftware.com>]

This thread mentioned some other vendors have implemented Kompella.

Does anyone know what other vendors has done so?

I heard there were 3... but no one knew the names..


-----Original Message-----
From: Christopher Lewis [mailto:chrlewis@cisco.com] 
Sent: Wednesday, May 15, 2002 11:42 AM
To: Jim Guichard
Cc: Irwin Lazar; mpls-ops@mplsrc.com
Subject: RE: [MPLS-OPS]: Fwd: Re: Why martini over kompella

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



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