Jesper,
> Much harder to control on a per-LSP basis, especially when talking about
> LDP/TDP controlled LSP's.
Let's don't mix different things here :). I was assuming that the entire
conversation is reg the TE-LSPs only. The LDP/TDP LSPs have quite
different characteritics reg exp/imp-null treatment of received labels
at PHP (at least in cisco's) comparing to TE-LSPs.
Anyhow I agree in LDP LSPs (or prefix based LSPs) the knob would be
usefull per int.
R.
From serge@ivmg.net ¬óÅ; A
Received: from someone claiming to be
pefw00.ivmg.net (mail.ivmg.net [64.209.84.66])
by puck.nether¬óÅ; (
for <juniper-nsp@puck.nether.net>; Wed, 4 Apr 2001 16:06:31 -0400
(envelope-fro¬óÅ;rg
Received-Date: Wed, 4 Apr 2001 16:06:31 -0400
Received: from pimx00.ivmg.net (pimx00.ivmg.net [192.168.0.10])
¬óÅ;pe
Wed, 4 Apr 2001 20:06:30 GMT
Received: (from serge@localhost)
by pimx00¬óÅ;g.
Wed, 4 Apr 2001 13:06:30 -0700
Date: Wed, 4 Apr 2001 13:06:29 -0700
From: Serge Maskalik <ser¬óÅ;vm
To: Jesper Skriver <jesper@skriver.dk>
Cc: Kireeti Kompella <kireeti@juniper.net>, raszuk@cisco.com,
juniper-nsp¬óÅ;k.
Subject: Re: Juniper as egress LSR: to penultimate hop pop, or not?
Message-ID: <20010404130629.O19265@ivmg.net¬óÅ;fe
Content-Type: text/plain; charset=us-ascii
X-Mai¬óÅ; M
In-Reply-To: <20010404204730.I50601@skriver.dk>; from jesper@skriver.dk on Wed, Apr 04, 2001 at 08:47:31PM +020¬óÅ;<t
> > Can you explain why it would be useful per interface?
>
> We have a specific application where we on ¬óÅ;mb
> originate default route, for use of the routers in the network not
> carrying fu
> will use the LSP formed by LDP/T
> bo¬óÅ;,
> packets as ordinary IP packets, do NetFlow accounting on the¬óÅ;nd
>
I can see the ease-of-configuration benefits with¬óÅ;r
case scenario. In your special case, per-interface control is
useful. However, with RSVP-TE deployments in lacéÅ;NS
often a mid-point, head-end and tail-end fo¬óÅ;ny
> > I think it makes sense to do on per-LSP basis.
>
> Much harder to control on a per-LSP basis, especially ¬óÅ; t
> LDP/TDP controlled LSP's.
I'm more interested about the underlying RSVP-TE LSPs.
Imagine a RSVP-TE co¬óÅ;/
LDP LSPs. If I can configure exlicit-null behavior for
just the underlying TE LSPs, I can¬óÅ;er
policies from the EXP field all the way down to the tail.
- Serge
>
> > > So a knob would be nic¬óÅ; h
> >
> > > > What if the label stack has depth > 1? PHP in that case? Bit yucky,
> > > > but doable.
> > >
> > >¬óÅ; 3
> > >
> > > i. A value of 0 represents the "IPv4 Explicit NULL Label".
> > > This label value ¬óÅ;nl
> > > stack. It indicates that the label stack must be popped,
> > > and the f¬óÅ;rd
> > > IPv4 header.
> > >
> > > So yes, for label stacks with a depth > 1 ¬óÅ;mu
> >
> > I also realize the 3032 recommendation, but would
> > you not want to maintain the EXP s¬óÅ;ng
> > regardless whether LSP hierarchy is involved or not?
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:41 EDT