Re: nop response to diff-te-reqts

[Jim Boyle <jimpb@nc.rr.com>]

On Fri, 13 Jul 2001, Francois Le Faucheur wrote:

> Jim,
>
> As you know I initially had strong concerns about migration issues with
> your proposal (eg. from TE to DS-TE , when changing the mapping between
> preemption priorities and Class-Types,...). After thinking harder about it,
> I think it is possible to work out operational procedures for each
> migration scenario to ensure it goes OK.
> For instance when migrating from TE to DS-TE, I think your proposal
> requires that all LSRs be upgraded before TE-LSPs of another CT than CT0 be
> established - otherwise a new LSR may be fooled by misinterpretation of an
> advertisment from an old LSR and route CT1 LSPs on an onld LSR which only
> support CT0. (By contrast, with our proposal, LSRs can be upgraded
> gradually and the new CT will automatically be able to make use of all
> upgraded LSRs as they get upgraded.)

If we assume a network has two classes, and currently these are active
in a network on distinct LSPs at different priorities, as most of the
scenarios suggested, then one should indeed be able to update the code
in a router and reboot it.  It will either advertise something that is
exactly the same as the "legacy" code or (upon some configuration)
something that is within spec.  As for signalling, nothing new on the
wire.  So, if we add a new variable of evaluation, I'd propose that
the nop approach is not only more scalable (as you grant), but also
more stable.

One potential problem where yours would lend itself well is in the
introduction of a new class (a third class in this example), as it can
be treated predictibly in terms of scope and orthogonally to the other
classes.  The flipside is that in the above, were one to only stick
with two classes, one set of the LSPs (those that assign to what was a
priority in classtype 0 and is now classtype 1) will have to be
migrated (e.g. removed and reconfigured).  I suppose not a horrible
deal, though in meshes this will involve two passes (code, then
lsps) with scope of whole network.

> So I now think your proposal can address migration scenarios provided
> appropriate migration procedures are followed.

one must be careful, it's true.

>
> We also did more investigations on the scalability impact of our proposal
> and we concluded that the difference between the two approaches is fairly
> marginal (even if the difference in terms of nb of octets advertised is
> significant). We detailed the reasoning behind that in
> draft-lefaucheur-diff-te-proto-00.txt that we just posted. Feed-back is
> welcome.

I await its post to the repository.

>
> So our current perception is that:
>          - your proposal has a slight edge in terms of scalability,
>          - our proposal has an edge in terms of flexibility and ease of
> migration
>          - benefits in flexibility/ease outweighs scalability delta
>
> More input from Service Provider on this specific trade-off between the
> scalability delta and the flexibility/ease of migration (as we tried to
> detail in our draft) would be helpful for going ahead.
>
> Cheers
>
> Francois
>
> PS: I will be out of the office for a while so may not be able to discuss
> this much before we meet in London.
>