The MPLS WG Archive

[Der-Hwa Gan <dhg@juniper.net>]

> 
> In message <20021104110215.J10006-100000@kummer.juniper.net>, 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
>