Subject: RE: More comments/questions on DS-TE solution draft

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Wed, 6 Feb 2002 17:37:55 -0500

Hi Francois! In the second part of your response you
eluded to the "initial" DS-TE solution. I just want
clarify whether you are still pursuing the latest
approach you indicated in your previous e-mail (
around the time of IETF conf). i.e.

	1. In the last e-mail you indicated that you
	are leaning towards the explicit signaling 
	of the ClassType.
	
	2. The e-mail also indicated that the user
	has to explicitly configure the mapping to
	identify the bandwidth to be advertised:
	[ClassType][SetupPriority] 	index-in-available
						adv. TLV
	User is expected to configure only few 
	priorities per ClassType.

	Are you still perusing these approaches in
	your latest rev. of the draft ?

Another unrelated question: As far I understand, the 
available bandwidth will get advertised periodically. 
Do you think this approach will be sufficient for a 
DS-TE network, with lot of LSPs being created and 
deleted?

Thanks,
sanjay

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2002 6:49 AM
> To: Choudhury, Sanjaya
> Cc: [email-masked]'
> Subject: Re: More comments/questions on DS-TE solution draft
> 
> 
> Sanjay,
> 
> thanks again for these comments. It's great to have them 
> ahead of time.
> 
> thoughts on 3 & 4:
> 
> >3. It will be helpful, if the draft spells out any domain 
> level restrictions
> >     /recommendations that the user should keep in mind. For example:
> >         a) Is it necessary for the number of CTs to be same in
> >         all the links of all LSRs in the DS-TE domain ?
> >         b) Does the CT identifier have to be consecutive in nature ?
> >         c) Is it necessary that _all_ the LSRs in the domain MUST
> >         support DS-TE.
> >             if it is not necessary then :
> >                 i) What should be the behavior if a LSR that
> >                 does not support the signaled (or inferred) CT ?
> >
> >4. How can a LSR distinguish between the DS-TE and non DS-TE
> >     bandwidth advertisement (DS-TE re-uses the existing constructs
> >     to advertise the available bw in a CT+priority basis) ?
> 
> The working version of the draft indicates that:
>          - to use more than one CT anywhere in the network, 
> all LSRs must 
> support DS-TE (an LSR can not distinguish through signaling 
> whether an IGP 
> advertisement is for TE or DS-TE)
>          - all LSRs must support the same BAndwidth Constraint Model
>          - all LSRs must be configured with the same 
> CT/Preemption mapping 
> (this is defined more precisely in the draft, but basically 
> it indicates 
> which CT/Preemption is advertised in each Bw value of IGP).
> 
> This approach results from earlier discussion. You would 
> remember that our 
> initial "solution" proposed that we advertise  a Bw value for 
> up to (8 
> preemption) times (8 CTs). One of the main motivations for 
> doing so was so 
> that an LSR can automatically detect which other LSR is 
> TE-only or DS-TE 
> capable and so that you could set-up LSPs from other CTs than 
> CT0 around 
> TE-only LSRs.  Another motivation was that no consistent 
> mapping needed to 
> be configured since each value was explicitely associated 
> with a given 
> preemption and CT inside the IGP advertisement . After a lot 
> of discussion 
> (including input from SPs), the conclusion was that these 
> operational/configuration benefits did NOT justify extra IGP 
> signaling and 
> associated scalability impacts. So the decision to advertise 
> only 8 bw 
> values included the assumption that things need to be upgraded and 
> configured in a consistent fashion. Note that this is 
> generally in line 
> with Diff-Serv anyway where things must be configured 
> consistently on all 
> boxes.
> 
> Cheers
> 
> Francois
> 
> >Thanks,
> >sanjay
> >
> >
> >
> >
> 
> 
> _________________________________________________________
> 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
> _________________________________________________________ 
> 
> 

This e-mail and any attachments are confidential. If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachment, use the contents for any purposes, or disclose the contents to
any other person: to do so could be a breach of confidence.

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 11 Feb 2002 14:35:07 +0100

Sanjay,

At 17:37 06/02/2002 -0500, Choudhury, Sanjaya wrote:

>eluded to the "initial" DS-TE solution.

I only refred to the "initial" solution to clarify the differnces with the 
"unified approach". We are NOT reverting to the "initial" solution. We are 
describing the "unified approach", simply adjusting it to allow multiple 
CTs to use the same preemption level (and thus not preempt each other) as 
agreed.

>  I just want

yes.

>         are leaning towards the explicit signaling

yes. this is my personnal recommendation.
But we're still discussing it.

>         [ClassType][SetupPriority]      index-in-available

yes.

>         priorities per ClassType.

users only has one constraint: that the number of pairs 
[ClassType][SetupPriority] is limited by 8.
Under that constraint, user can use few or more priorities in a given CT.

>         your latest rev. of the draft ?

yes.

>DS-TE network, with lot of LSPs being created and

Available bandwidth are certainly advertised periodically. But they can 
also be advertised on various triggers. There has been lots of useful work 
done in teh context of PNNI in particular about what are teh godd triggers 
and the benefits that this extra advertisement offer.
Yes, I think combination of periodic and triggered advertisement of 
available bandwidth will be sufficient for DSTE as it is today with regular TE.

Cheers

Francois

---

From: "Naidu, Venkata" <[email-masked]>
Date: Sun, 17 Feb 2002 12:36:21 -0500

Francois:

-> >Another unrelated question: As far I understand, the
-> >available bandwidth will get advertised periodically.
-> >Do you think this approach will be sufficient for a
-> >DS-TE network, with lot of LSPs being created and
-> >deleted?
-> 
-> Available bandwidth are certainly advertised periodically. 
-> But they can 
-> also be advertised on various triggers. There has been lots 
-> of useful work 
-> done in teh context of PNNI in particular about what are teh 
-> godd triggers 
-> and the benefits that this extra advertisement offer.
-> Yes, I think combination of periodic and triggered advertisement of 
-> available bandwidth will be sufficient for DSTE as it is 
-> today with regular TE.

   But this periodic advertisements are based on some 
   thresholds (either configurable on per router/interface basis).
   I didn't see any interoperable thresholds defined in
   TE drafts. If routers are configured with different threshold
   values (in between 5% to 10%) then there might be some 
   path setup problems in multi-vendor networks (I can think off)

   One more concern is - "Network/Resource re-optimization". RFC2702 
   Section 5.6.4 Adaptivity Attribute - clearly specifies
   requirements to do re-optimization. But *when and what* to
   re-optimize is left as a local decision. I can think of many
   example scenarios where to re-optimize resources. But I don't
   know the implications in the multi-vendor networks.
 
   Though not related to present discussion, there are just 
   some concerns lurking in my mind for long...
   
Venkata Naidu

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 19 Feb 2002 19:12:47 +0100

Venkata,

>    some concerns lurking in my mind for long...

Right, those are really not DS-TE questions. There are more like questions 
about using a Link State for path computation. They are equally applicable 
to TE, DSTE and PNNI.

On the first point, I don't see an issue if routers are configured with 
different thresholds (or even if they were to implement different threshold 
mechanisms like one having 5 thresholds and the other 10 thresholds). It 
seems quite fine to handle that as a local matter outside standardisation. 
You may just end up doing more or less acurate path computation  (and have 
lower/higher CAC rejection rate) depending on actual link thresholding, but 
that's all. Also, I am not aware of any issues on that front raised in 
production networks using multi-vendor TE implementations today.
Have you identified specific scenarios where this would be a problem?

On the second point, same thing really. This seems quite fine as a local 
matter. Can't think of scenarios where this is a problem . Can you?

Cheers

Francois

PS: I posted both the DS-TE Requirements and DS-TE Protocol drafts today so 
they should appear on the IETF server soon.