[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: More comments/questions on DS-TE solution draft
Sanjay,
At 17:37 06/02/2002 -0500, Choudhury, Sanjaya wrote:
>Hi Francois! In the second part of your response you
>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
>clarify whether you are still pursuing the latest
>approach you indicated in your previous e-mail (
yes.
>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.
yes. this is my personnal recommendation.
But we're still discussing it.
>
> 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
yes.
> User is expected to configure only few
> 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.
> Are you still perusing these approaches in
> your latest rev. of the draft ?
yes.
>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.
Cheers
Francois
>Thanks,
>sanjay
>
> > -----Original Message-----
> > From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> > Sent: Wednesday, January 30, 2002 6:49 AM
> > To: Choudhury, Sanjaya
> > Cc: 'te-wg@ops.ietf.org'
> > 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: flefauch@cisco.com
> > _________________________________________________________
> > 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.
_________________________________________________________
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
_________________________________________________________