Subject: Re: nop response to diff-te-reqts

From: Jim Boyle <[email-masked]>
Date: Wed, 11 Jul 2001 12:18:35 -0400

nope, it was just a preview site.  The draft is now in the standard 
repository and can be found at:

http://search.ietf.org/internet-drafts/draft-boyle-tewg-ds-nop-00.txt

also, type in the abstract, comments should be sent to the list, but I 
forgot the hyphen in the address:

		[email-masked]

thanks,

Jim

> 
> is this link still working? I tried to download your technical proposal
> today but no success... Can you please check this out. Otherwise can you
> sent me directly (attachement) you note?
> 
> 
> On Wed, 4 Jul 2001, Jim Boyle wrote:
> -
> -I've posted a technical proposal in response to
> -draft-ietf-tewg-diff-te-reqts-01.txt
> -
> -A preview can be seen at:
> -
> -	http://www.tcb.net/meatloaf/draft-boyle-tewg-ds-nop-00.txt
> -
> -thanks,
> -
> -Jim
> -

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 13 Jul 2001 17:46:04 +0200

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.)
So I now think your proposal can address migration scenarios provided 
appropriate migration procedures are followed.

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.

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.

>>-       http://www.tcb.net/meatloaf/draft-boyle-tewg-ds-nop-00.txt

_______________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 89 108 159
Fax:                   +33 4 97 23 26 26
Email:                  [email-masked]
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
Bâtiment T3
06 410   BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________

---

From: Jim Boyle <[email-masked]>
Date: Sun, 15 Jul 2001 23:59:26 -0400 (EDT)

> 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.

> appropriate migration procedures are followed.

one must be careful, it's true.

> draft-lefaucheur-diff-te-proto-00.txt that we just posted. Feed-back is

I await its post to the repository.