Hi Giles,
could you point me to this second draft you mentioned (the one that suggest
LDP to setup L2-circuit-LSPs), or is the version 01 of l2-circuit?
I agree with you that label-stacking provides better scalability, this is
used in both rfc2547bis and mpls-l2vpn, also considering automation RSVP is
not really the way to go. Probably RSVP should be used in special cases
only.
I'm not sure I can agree with your reasoning on L2 over L3. I still do not
see why one should use an L3 backbone when L2 services are core business. I
think in the end the scaling issues are similar. There is of course the
advantage of extended reach with L3, and the ability to deliver L3 services
as well.
cheers,
Eduard
> -----Original Message-----
> From: Giles Heron [mailto:giles@level3.net]
> Sent: woensdag 31 januari 2001 12:44
> To: Metz, E.T.
> Cc: Darren Bolding; Nikolas Weidenbacher; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] CCC encapsulation standard?
>
>
> "Metz, E.T." wrote:
> >
> > >
> > > the encapsulation used by "remote interface switching" CCC is
> > > (as far as
> > > I can tell) just layer 2 in MPLS. No label stack, and
> nothing between
> > > the layer 2 frame and the MPLS header. I believe the
> FCS is stripped
> > > off. There's no plan AFAIK for this to be on the sandards track.
> > > Neither is it an implementation of Juniper's Layer 2 VPN draft.
> > >
> >
> > Could be seen as early implementation of concept ;-), I think the
> > encapsulations are similar.
>
> Not sure. I read the L2 draft a couple of months ago, but haven't
> looked at it lately.
>
> > > The problem with CCC is that it doesn't scale. Each CCC
> connection
> > > requires 2 RSVP-signalled LSPs. This leads to an
> "n-squared" label
> > > problem in the core. So while CCC is useful for tunneling
> > > infrastructural services (e.g. Multicast, internal networks,
> > > etc.) over
> > > an MPLS core it isn't much use, in my opinion, if you
> want to provide
> > > services to customers :(
> >
> > Since MPLS LSPs are uni-directional by definition, I would
> consider this
> > "scaling issue" an artefact of MPLS not CCC. But, you're
> right, it will kind
> > of a burden in large scale deployments. On the other hand,
> if you really
> > doing large scale L2 services ... why build an L3 network
> to provide this?
>
> Yes the unidirectional "pipe" issue is an artifact of MPLS.
>
> But then the n-squared problem isn't to do with being unidirectional,
> it's to do with using RSVP. Of course a point to point
> circuit needs a
> point to point LSP, so you can't really use LDP in the conventional
> sense for layer 2 over MPLS. But MPLS does have the concept
> of a label
> stack :-)
>
> The reason why one might build an L3 network to provide this is
> scaling. Not to mention the ability to provide L3 services
> on the same
> network without resorting to VC meshes :)
>
> > > A proposed "standard" for layer 2 over MPLS encapsulation is
> > > draft-martini-l2circuit-encap-mpls-00.txt (we are just
> putting 01.txt
> > > together now.) I would expect Juniper to implement this draft.
> > >
> >
> > I suppose this also requires two LSP per circuit?
>
> Yes, but the two LSPs are stacked inside IGP signaled LSPs.
> So there is
> no additional label state carried in the network (it is only known by
> the two PE devices in question.) The "VC" LSPs are signaled using
> targetted LDP from PE to PE.
>
> > Apologies for not being completely familiar with this
> draft, but how do you
> > see this relate to mpls-l2vpn?
>
> I don't see this as competitive with mpls-l2vpn at all. The
> L2VPN draft
> seems to be about how to build a mesh (or a partial mesh) of
> VCs between
> a set of edge devices.
>
> The encapsulation draft is just about how to encapsulate a single
> point-to-point L2 circuit.
>
> There is a second draft explaining the targetted LDP signaling used to
> set up the circuit, which could in some ways be considerd as
> competitive
> with mpls-l2vpn - but then I think signaling an arbitrary L2 (or L1)
> circuit over MPLS solves a different problem to building a whole VPN?
>
> Giles
>
> >
> > cheers,
> > Eduard
> >
> > > Giles
> > >
> > > Darren Bolding wrote:
> > > >
> > > > Nikolas,
> > > >
> > > > Thanks for your reply! I think I understand what you are
> > > saying, especially
> > > > as regards using CCC for layer 2 switching cross-connects,
> > > or even for LSP
> > > > stitching.
> > > >
> > > > However, I use the word encapsulation for a couple of reasons:
> > > >
> > > > (1) Its the way Juniper describes it in the only reference
> > > I can find about
> > > > Ethernet VLAN-CCC
> > > >
> > > (http://www.juniper.net/techpubs/software/junos42/swconfig-int
> > > erfaces42/html
> > > > /interfaces-ethernet-config8.html) which I can only find in
> > > 4.2 docs (by
> > > > searching)
> > > >
> > > > (2) I'm particularly interested in MPLS LSP Tunnel
> Cross-Connects
> > > >
> > > (http://www.juniper.net/techpubs/software/junos43/swconfig43-m
> > > pls-apps/html/
> > > > ccc-config7.html#1013872). In this case, I would use
> > > encapsulation to
> > > > describe what's happening- ingress traffic on the interface
> > > is encapsulated
> > > > and put in an LSP, which travels across one or more LSR's
> > > to an egress point
> > > > where it is deencapsulated (with CCC, this is largely just
> > > stuffing frames,
> > > > but some layer-2 munging may occur).
> > > >
> > > > Am I missing something? I'd like to know if I
> > > misunderstand something.
> > > >
> > > > It seems odd that the 4.3 docs don't mention VLAN-CCC at
> > > all (that I can
> > > > find), I presume the functionality has not been deprecated.
> > > >
> > > > I'm interested in finding out if the method by which
> layer-2 data is
> > > > encapsulated and placed into an LSP is publicly documented,
> > > and if it is
> > > > standards track.
> > > >
> > > > Greg Ketell's e-mail implies that CCC is an implementation
> > > of the MPLS
> > > > Layer-2 VPN I-D. Which makes sense given the number of
> > > Juniper names on the
> > > > I-D. (Thanks Greg!)
> > > >
> > > > --D
> > > >
> > > > -- Darren Bolding darren@bolding.org --
> > > > -- http://www.bolding.org/~darren --
> > > >
> > > > > -----Original Message-----
> > > > > From: Nikolas Weidenbacher [mailto:nikw@sgns.net]
> > > > > Sent: Tuesday, January 30, 2001 4:07 PM
> > > > > To: Darren Bolding
> > > > > Cc: juniper-nsp@puck.nether.net
> > > > > Subject: Re: [j-nsp] CCC encapsulation standard?
> > > > >
> > > > >
> > > > >
> > > > > Encapsulation? CCC happens within a single router, so
> > > there is no such
> > > > > thing as a CCC packet. CCC is a configuration within the
> > > router that maps
> > > > > two logical interfaces together, or maps a logical
> > > interface to an MPLS
> > > > > tunnel.
> > > > >
> > > > > Are you sure you're not wondering about MPLS?
> > > > >
> > > > > Nik Weidenbacher
> nikw@sgns.net
> > > > > Network Engineer
> 215-351-1067
> > > > > Sungard Network Solutions
> > > > >
> > > > > On Tue, 30 Jan 2001, Darren Bolding wrote:
> > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I'm wondering if anyone can point me to any published
> > > standards for CCC
> > > > > > (Circuit Cross-Connect) encapsulation?
> > > > > >
> > > > > > I'm pretty sure its not in the ietf, but perhaps I
> missed it.
> > > > > I'm wondering
> > > > > > if Juniper has ever released the spec for
> > > interoperability purposes.
> > > > > >
> > > > > > Curious, and thanks,
> > > > > >
> > > > > > --D
> > > > > >
> > > > > > -- Darren Bolding darren@bolding.org --
> > > > > > -- http://www.bolding.org/~darren --
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > > --
> > > ===================================================
> > > Giles Heron - IP Architect - Level 3 Communications
> > > phone: +44 20 7864 0719 mobile: +44 7880 506185
> > > ===================================================
> > >
>
> --
> ===================================================
> Giles Heron - IP Architect - Level 3 Communications
> phone: +44 20 7864 0719 mobile: +44 7880 506185
> ===================================================
>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:43 EDT