hi
if i was using say an M5 router would it be possible to do something similar
to that of CBWFQ/CAR/RED.
i understand that RED is supported and looking at the config (without any
juniper config experience) it seems i can perhaps gaurantee bandwidth for
say a gold service and then do aggressive RED (to simulate CAR) for silver
and bronze services.
Also is this done at line speed since at the moment an STM4 on a GSR will
cause a big performance impact if i do CAR and this seems similar on a 7500
with CBWFQ/CAR (although i havnt confirmed this) plus only ATM STM4 is
available on cisco 7500 and not a pos STM4 which is supported on the M5
(looking at the features it say rate-limiting on inbound and outbound)
anyone any experience of doing this kind of QOS with juniper boxes. Also
pointers to some documentation config/overview if its possible.
thanks
rgrds
faz
-----Original Message-----
From: giles@puck.nether.net [mailto:giles@puck.nether.net]On Behalf Of
Giles Heron
Sent: Wednesday, January 31, 2001 1:21 PM
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:
>
> 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?
http://search.ietf.org/internet-drafts/draft-martini-l2circuit-trans-mpls-04
.txt
> 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.
Agreed.
> 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.
Yes, both of those are good arguments for L3. Another advantage is the
ability to used mixed physical media in the core (ATM, POS, GigE etc.)
Giles
>
> 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
> > ===================================================
> >
-- =================================================== 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:40 EDT