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

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Thu, 13 Dec 2001 09:00:01 -0500

Hi Francois!

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2001 1:47 PM
> To: Choudhury, Sanjaya
> Cc: [email-masked]'
> Subject: Re: Question on DS-TE (solution) draft: How can I prevent
> preemption of a connection ?
> 
> 
> Sanjay,
> 
> At 09:54 12/12/2001 -0500, Choudhury, Sanjaya wrote:
> 
> >         Hi! According to the latest DS-TE solution, the 
> signaled (setup)
> >         preemption priority is used to infer the bandwidth 
> constraint
> >         associated with a LSP.
> >
> >         By doing this, are we losing the ability to prevent 
> the preemption
> >         of a LSP (of a set of LSPs) , in a network using the DS-TE ?
> >
> >         [For example, an administrator may want to deploy 
> DS-TE in his
> >         network, but may not want (automatic) preemption of existing
> >         LSPs in response to the creation a new LSP.]
> >
> >         Thanks,
> >         sanjay
> >
> 
> I think you've raised a very valid point:
> As currently specified, the solution would not allow LSPs in 
> different CTs 
> to use the same preemption level.
> 
> I believe this can be fixed by making the solution a little 
> more flexible. 
> In essence what we would do is :
>          - consider that the 8 Bw values included in the IGP 
> advertisments 
> are no longer tied to preemption. The position of the Bw 
> value in the IGP 
> advertisement is considered purely as an index i,  0<=i<=7
>          - a mapping is defined on all the LSRs: i ---> 
> (preemption_level, CT)
>          - this mapping must be consistent throughout the DSTE domain
> 
> For example, I could use the above to ensure each CT has a differnet 
> preemption level (ie CT0 can preempt CT1, CT1 can preempt CT2) by 
> configuring the following mapping:
>          - BW value 0 is used for CT0/Preemption0
>          - BW value 1 is used for CT1/Preemption1
>          - BW value 2 is used for CT2/Preemption2
> 
> Alternatively, I could use the above to ensure all CTs have the same 
> preemption level by configuring the following mapping:
>          - BW value 0 is used for CT0/Preemption0
>          - BW value 1 is used for CT1/Preemption0
>          - BW value 2 is used for CT2/Preemption0
> 
> I had a chat with some of the co-authors about this and they 
> were fine with it.
> 
> Does that work for you too?
> 
> Thanks
> 
> Francois
> 
> >
> >
> >

	Can you explain the solution again ?
	
	IGP: 
		1. 8 available bw are advertised, using existing 
		constructs. ->Okay
		2. How do I compute these ? 
			a) Based on setup priority
			b) Based on setup priority + class type (/BC)
			c) Based on class type(/BC)
	CAC:
		1. How do I get the BW pool with which I need
		to compare the requested BW with ?
			a) From the setup priority ?
			b) New signaled TLV ?
			c) Combination of both ?
	PCM:
		1. When I need to compute a PATH for a connection
		what approach do I use ?
		[Related to CAC]

	Preemption:
		1. How do I determine which connection to preempt ?
			a) Based on the standard setup/holding 
			priority ?
			b) Based on a new signalled entity ?
			c) combination of both ?
		2. How can I say don't preempt a specific connection ?

	Thanks,
	sanjay

---

From: "Iren, Sami" <[email-masked]>
Date: Thu, 13 Dec 2001 09:09:07 -0500

Francois:
As much as I like the idea of having the capability
to prevent preemption, I am not clear about what
you are proposing. Furthermore, I am surprised that
you are seeing this as a problem now. I thought
from the draft it was very clear that we would loose
the ability to prevent preemption. The whole scheme
was based on that.
Anyways here are the points that I am not clear about:

* The draft states that each preemption priority is only
  used by a single CT. In this new proposal you are removing
  this restriction.
* Because of the above, we are loosing the ability to
  deduct the CT from the setup preemption priority of
  an LSP. Therefore, we need to signal CT as well as
  preemption priority for LSPs. Previously, we did not
  need to signal CT.
* What is the exact relation between CT and preemption priority?
  By assigning all the CTs to preemption priority 0 as
  in your example are we saying that no other preemption
  priorities will be allowed in the system?
  What are the changes required for this proposal in the
  signaling of LSPs?

In general I like the idea but I would like to get the 
details of the proposal.

Thanks,
--Sami

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 13 Dec 2001 16:05:49 +0100

Sanjay,

>         Can you explain the solution again ?

will try. I haven't thought it through properly yet. Needs more thinking 
but seems doable.

>                 1. 8 available bw are advertised, using existing

yep.

>                         c) Based on class type(/BC)

c).
let's say that the i-th bandwidth value is mapped to CT c and preemption p.
the i-th bandwidth value is computed to indicate the "available" bandwidth 
for the set of LSPs of preemtion p and CT c. It reflects the Bandwidth 
Constraint(s) associated with CT c and ignores all the LSPs of preemption >p.

>                         a) From the setup priority ?

This is open. I think either would work. We woudl need to evaluate them and 
pick one.

>                 1. When I need to compute a PATH for a connection

when you need to compute a path for an LSP, you woudl know the preemption 
of the LSP and the CT of the LSP. Using the mapping index <-->CT/preemption 
you know the index in Bw values.  This tells ytou what available bw to 
consider on all the links.

>                         b) Based on a new signalled entity ?

through the mechanisms above you always know for every LSP both its 
preemption and CT.
if an existing LSP has lower or equal numerical preemption value than the 
new one , you can preempt the existing one.
If existing LSP has numerically higher preemption value, then you may 
preempt it. You woudl preempt it iff you are competing for its bw. This can 
happen if teh existing LSP is in teh same CT butr it can also happen if the 
LSP is inanther CT (eg. in the case where a given Bandwdith Constraint 
applies to more than one CT).

>                 2. How can I say don't preempt a specific connection ?

The overal constraint is that the number of <CT/Preemption> pairs is 
limited to 8.
(BTW , we are thinking of add a definition to call the <CT/preemption> pair 
something like TE-Class)
Once you have selected 8 <CT/preemption> pairs, you can ensure that some 
LSPs don't preempt each other by using the same preemption level for those.

Cheers

Francois

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Mon, 17 Dec 2001 13:32:21 -0500

Hi Francois! After you think through the problem (and
possible solutions), will it be possible for you to 
post another revision of the DS-TE draft (including
the examples in Appendix) ? It will also be helpful,
if you can give us rough time frame for the next
rev.

Some more thoughts on the next rev. of DS-TE ...
1. It will be nice to include a section on the Preemption
   in the context of DS-TE .
2. Where does holding priority fit in this scheme ? Is this
   still a useful construct ?	
3. TE-Class: Should the term be "Bandwidth Class/Pool" (
   defined by a set of BW constraints & priority )? 
4. Is the term ClassType (== identifies a set of bandwidth
   constraint), redundant ?

Thanks,
sanjay

> Sent: Thursday, December 13, 2001 10:06 AM
> To: Choudhury, Sanjaya
> Cc: 'Francois Le Faucheur'; [email-masked]'
> Subject: RE: Question on DS-TE (solution) draft: How can I prevent
> preempt ion of a connection ?
> 
> 
> Sanjay,
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 18 Dec 2001 16:40:59 +0100

Sanjay and all,

At 13:32 17/12/2001 -0500, Choudhury, Sanjaya wrote:

>the examples in Appendix) ?

Yep, that's the plan.

>It will also be helpful,

I'd like to post something first half of January.

>    in the context of DS-TE .

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?

>    still a useful construct ?

Could we keep holding priority?:
I believe it is possible to maintain the concept of hold vs setup priority 
when extending TE to DSTE. In the case od DS-TE, network administrator 
could use different setup and hold priorities for a given LSP, but both of 
those cannot just be any 8 values: they can only be one of the values 
allowed for the LSP's CT.
Will need to write it down to make sure it can indeed all work fine.

Is holding priority useful?:
I've done some very initial probing about that. My first impression is that 
while use of a different hold priority from setup priority is not very 
commonly used in current TE deployments, it is something that SPs quite 
like because it could help stabilise the network if this turns out to be 
useful.
So my first impression is that it would be premature to dismiss the concept 
of hold priority altogether.

>    defined by a set of BW constraints & priority )?

need to rethink about "TE-class" in light of hold priority discussion above.

>4. Is the term ClassType (== identifies a set of bandwidth

I don't think CT is redundant. we'll see when the TE-class definition firms up.

Thanks for your probing and input.

Francois

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Thu, 20 Dec 2001 17:21:08 -0500

Hi Francois,

> Sent: Tuesday, December 18, 2001 10:41 AM
> To: Choudhury, Sanjaya

<snip ...Please refer to the last e-mail in this thread 
for context..>

> mind (and taking into account the update mentioned just 
	
 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

 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]
Thanks,
sanjay

	

<snip ...>

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 21 Dec 2001 11:16:43 +0100

Sanjay,

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

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

><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:                 [email-masked]
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410  Biot - Sophia Antipolis
FRANCE
_________________________________________________________