Subject: RE: Decreasing TE-LSP bandwidth, "interoperability issue" (fwd)

From: "David Allan" <[email-masked]>
Date: Wed, 6 Nov 2002 06:25:31 -0500

Der-Hwa/Eric:

Only scenario that comes to my mind is that some form of data plane probing
of the LSP is going on (be it LSP-PING, Y.1711 or whatever). Changing the ID
means there is a small window in which it may appear as a transient fault to
the probing system.

cheers
Dave

> -----Original Message-----
> From: Der-Hwa Gan [mailto:[email-masked]]
> Sent: Tuesday, November 05, 2002 7:04 PM
> To: Gray, Eric
> Cc: [email-masked]
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability 
> issue" (fwd)
> 
> 
> 
> 
> > Der-hwa,
> > 
> > 	Here we have a trade-off between a small potential for
> > simplification represented by using a symmetrical approach
> > (the same approach used for increasing or decreasing the 
> > TE-LSP bandwidth) and the potential risk of not being able
> > to make a new reservation with a lesser bandwidth in the
> > unusual use of FF reservation style.  
> 
> It is not a question of simplication. If FF reservation style is
> excluded from RSVP-TE spec, then we won't discuss it. But if 
> FF remains
> a potential option (perhaps a future application may make use of it?),
> then it is fair to consider it.
> 
> My response was mainly to the point that Curtis raised - 
> could there be
> a reason that changing ID is bad?
> 
> > 
> > 	Please tell me again why this is a hard choice?
> 
> There are other benefits to not changing the ID. It was those 
> considerations
> that drove the original choice - it is more optimal, less
> states, and less overhead to the network.
> 
> Do you see a easy choice?
> Der-Hwa
> 
> > 
> > 	Note that - if we were using the FF reservation style
> > and trying to increase the bandwidth - the problem would be
> > worse because it would be both more likely to cause trouble
> > and less likely to be remediable.
> > 
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > [email-masked]
> > 508 305 7214
> > 
> > 
> > > -----Original Message-----
> > > From: Der-Hwa Gan [mailto:[email-masked]]
> > > Sent: Tuesday, November 05, 2002 3:45 PM
> > > To: [email-masked]
> > > Cc: Kireeti Kompella; [email-masked]
> > > Subject: Re: Decreasing TE-LSP bandwidth, 
> "interoperability issue" (fwd)
> > > 
> > > 
> > > >
> > > > In message 
> <[email-masked]>, Kireeti
> > > Kompell
> > > a
> > > > writes:
> > > > > Hi All,
> > > > >
> > > > > I'd like to re-iterate Der-Hwa's question:
> > > > >
> > > > > On Thu, 31 Oct 2002, Der-Hwa Gan wrote:
> > > > >
> > > > > > It is perhaps more appropriate to ask what is the 
> technical reason
> > > that a
> > > > > > new ID is required to get bandwidth decrease?
> > > > >
> > > > > Is there a technical reason that someone can 
> articulate?  Along the
> > > > > same lines, is make-before-break needed on bandwidth 
> *decrease*?
> > > > >
> > > > > Thanks,
> > > > > Kireeti.
> > > >
> > > >
> > > > Does interoperating with a major router vendor (which is neither
> > > > Juniper or Avici) qualify as technical?  After all, 
> this is the IETF
> > > > so improving interoperability must count for something. 
>  Right?  If
> > > > not, then I can't think of any reason to increment the 
> LSP-ID and if
> > > > you don't change the LSP-ID, then you don't need to do
> > > > make-before-break.
> > > >
> > > > OTOH - Do you see any reason to NOT increment the ID and do
> > > > make-before-break.  If you do so you interoperate with the major
> > > > router vendors (Juniper, Avici, others which do either 
> one right, plus
> > > > one which seems to be in denial about their router not handling
> > > > bandwidth decrease reliably).
> > > 
> > > Suppose the reservation style is FF, then incrementing 
> the ID might
> > > cause b/w decrease action to fail, since make-before-break may run
> > > out of b/w at certain bottle-neck.
> > > 
> > > We can argue that FF style isn't in wide spread use, but it isn't
> > > precluded from RSVP-TE framework so far.
> > > 
> > > Thanks,
> > > Der-hwa
> > > 
> > > >
> > > > We do the latter (change the LSP-ID and do 
> make-before-break) and I
> > > > think it is a better strategy because no major router 
> can't handle
> > > > that case.
> > > >
> > > > The only thing besides improved interoperability that 
> borders on a
> > > > technical reason is that the same mechanism is then 
> used for both
> > > > bandwidth increase and decrease.
> > > >
> > > > Curtis
> > > >
> 
>

---

From: George Swallow <[email-masked]>
Date: Wed, 06 Nov 2002 08:37:24 -0500

> means there is a small window in which it may appear as a transient fault to

With LSP ping, you would ping the first LSP until the second is set
up.  Once that is complete you can start pinging it as well.  You can
even wait for a successful reply before ceasing pinging the first and
tearing it down.  (Though I think that's probably overkill.)  So you
don't have a gap, you actually have an overlap.

With Y.1711 I don't understand how you would map an RSVP tunnel/lsp-id
to a TTSI.  There are just enough bits to fit both RSVP fields into
the TTSI LSP-ID, but that doesn't leave anying for LDP, BGP, etc.
Maybe you can enlighten us.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824