The MPLS-OPS Archive

["Patrick Murphy" <pjm@nfld.net>]

Which vendors currently support Martini? I know Nortel does.

Any want to share any experience about them and any OSS requirements.
----- Original Message -----
From: "Joe Lin" <jlin@doradosoftware.com>
To: "'Christopher Lewis'" <chrlewis@cisco.com>; "'Jim Guichard'"
<jguichar@cisco.com>
Cc: "'Irwin Lazar'" <ilazar@mplsrc.com>; <mpls-ops@mplsrc.com>
Sent: Wednesday, May 15, 2002 5:51 PM
Subject: RE: [MPLS-OPS]: Fwd: Re: Why martini over kompella


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

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