[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on DS-TE (solution) draft: How can I prevent preempt ion of a connection ?
Sanjay and all,
At 13:32 17/12/2001 -0500, Choudhury, Sanjaya wrote:
>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) ?
Yep, that's the plan.
>It will also be helpful,
>if you can give us rough time frame for the next
>rev.
I'd like to post something first half of January.
>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.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?
>2. Where does holding priority fit in this scheme ? Is this
> 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.
>3. TE-Class: Should the term be "Bandwidth Class/Pool" (
> 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
> constraint), redundant ?
I don't think CT is redundant. we'll see when the TE-class definition firms up.
Thanks for your probing and input.
Francois
>Thanks,
>sanjay
>
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@europe.cisco.com]
> > Sent: Thursday, December 13, 2001 10:06 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,
> >
> > 13/12/2001 -0500, Choudhury, Sanjaya wrote:
> >
> > >Hi Francois!
> > >
> > > > -----Original Message-----
> > > > From: Francois Le Faucheur [mailto:flefauch@europe.cisco.com]
> > > > Sent: Wednesday, December 12, 2001 1:47 PM
> > > > To: Choudhury, Sanjaya
> > > > Cc: 'te-wg@ops.ietf.org'
> > > > 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 ?
> >
> > will try. I haven't thought it through properly yet. Needs
> > more thinking
> > but seems doable.
> >
> > >
> > > IGP:
> > > 1. 8 available bw are advertised, using existing
> > > constructs. ->Okay
> >
> > yep.
> >
> > > 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)
> >
> > 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.
> >
> > > 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 ?
> >
> > This is open. I think either would work. We woudl need to
> > evaluate them and
> > pick one.
> >
> > > PCM:
> > > 1. When I need to compute a PATH for a connection
> > > what approach do I use ?
> > > [Related to CAC]
> >
> > 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.
> >
> > > 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 ?
> >
> > 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
> >
> > > Thanks,
> > > sanjay
> > >
> > > >
> > > >
> >
> >
> >