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

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 30 Jan 2002 12:48:36 +0100

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
_________________________________________________________