"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