RE: Question on DS-TE (solution) draft: How can I prevent preempt ion of a connection ?

[Francois Le Faucheur <flefauch@europe.cisco.com>]

Sanjay,

At 17:21 20/12/2001 -0500, Choudhury, Sanjaya wrote:

>Hi Francois,
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@europe.cisco.com]
> > Sent: Tuesday, December 18, 2001 10:41 AM
> > To: Choudhury, Sanjaya
> > Cc: 'Francois Le Faucheur'; 'te-wg@ops.ietf.org'
> > Subject: RE: Question on DS-TE (solution) draft: How can I prevent
> > preempt ion of a connection ?
> >
> >
> > Sanjay and all,
>
><snip ...Please refer to the last e-mail in this thread
>for context..>
>
> > 2.2.1 and 2.2.2 talk about preemption in the context of
> > DS-TE. They will
> > need to be updated to reflect our SLC agreement that we should allow
> > different CTs to use the same preemption.
> > The objective of the preemption section is to (i) not
> > redefine preemption
> > and (ii) just clarify how it plays in the context of DS-TE.
> > With this in
> > mind (and taking into account the update mentioned just
> > before), what would
> > you suggest we add?
>
>  Besides what we discussed (in previous e-mails), it may be helpful
>  to clarify:
>         1. The max number of setup priorities that can be supported
>         and its effect on the max number of classTypes.
>         2. Whether the number of preemption priorities supported for
>         each CT have to same ?
>         3. How does the holding priority fits in to the picture ?
>         4. An example that illustrates under what condition one
>         connection with Ctx,Py can preempt CTm, Pn

makes sense. I was working on the new draft Yesterday and I think I have 
some text addressing the above clarifications. Please check it out when we 
post the next version to see if that's good enough..

>  Since you are in the process of analyzing the updated DS-TE
>  approach, here are is another thought:
>
>         1. Currently, user has to configures, what gets adv. in IGP.
>           i.e  i--> [class-type, priority]
>         2.Should also be allowed to configure how the class-type
>         (bandwidth pool) gets identified from signaling messages ?
>
>           Choices:
>                         (a) Explicit signaling of ClassType (BW pool
>                         identifier) -if supported
>
>                         (b) Implicitly infer the ClassType from an
>                         existing construct. For example:
>                                 (i) setup priority (/holding priority ??)
>                                 (ii)PSC
>                         [Based on user's configuration]

After some thinking, I am leaning towards (a) because:
         - more "natural" : we now really need to signal both preemption + 
CT (can no longer infer CT from preemption). We have an existing way to 
signal preemption. Let's just add a way to signal CT.
         - compatible with setup + holding priority concepts which we are 
trying to keep
         - leaves existing signaling of preemption untouched

Again thanks for your thoughts.

Francois


>Thanks,
>sanjay
>
>
>
>
>
>
>
>
>
>
>
><snip ...>
> >

My Mobile Phone number has changed to +33 (0)6 19 98 50 90
_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone:          +33 4 97 23 26 19
Mobile :               +33 6 19 98 50 90
Fax:                   +33 4 97 23 26 26
Email:                 flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________