[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: More comments/questions on DS-TE solution draft
Hi Sanjaya,
back to work on the solution draft...
please see below:
At 00:16 23/04/2002 -0400, Choudhury, Sanjaya wrote:
>Hi Francois! Now that the DS-TE-REQTS, draft requires
>the DS-TE solution to be deployable in a part of the
>topology
>(which is a realistic requirement);
agreed.
> one of
>the basic assumption behind the DS-TE-PROTO appears to
>be broken i.e the TE-Class Mapping is not same across
>the network.
actually, the assumption of DS-TE-PROTO is that the TE-Class mapping is the
same across the whole "DS-TE domain" , not necessarily the whole domain
(i.e. not where DS-TE is not deployed and regular TE is used). So I think
we are not violating the assumption.
>How your are planning to address situations where one
>of the interface in the LSR, connects to a legacy TE
>LSR and the other to a LSR that supports DS-TE ?
I think this could work under the following assumption:
the TE-Class mapping in the DS-TE domain must be such that:
- a TE-class exist for CT0 for every preemption priority actually
used in the TE domain
- the index for each of these TE-classes is equal to the
preemption priority
For example, imagine the TE domain uses preemption 2 and 3. Then, DS-TE can
be deployed in the same network if the TE-class mapping contains the
following TE-classes:
i <---> CT preemption
====================================
2 CT0 2
3 CT0 3
Another way to look at this is to say that, even if the whole TE-class
mapping does not have to be consistent with the TE domain, the subset of
this TE-Class mapping applicable to CT0 must effectively be consistent with
the TE domain.
I think this is a reasonable assumption to allow heterogeous operations
between TE domain and DS-TE domain in the same network. Do you agree it is
a reasonable asumption?
Coming back in more details to your "hybrid" LSR case (lets' call it LSR1)
- there is a single TE-class mapping (it is a LSR-level
parameter), say for example
i CT Premp
========================
0 <--> 1 0
1 <--> 1 1
2 <--> 0 2
3 <--> 0 3
rest <--> unused
- interface 1 to DS-TE LSR (LSR2) is configured with say BC0 and
BC1 (those are link-level parameters)
- interface 2 to legacy TE LSR (LSR0) is configured with BC0 only
LSR0 will only initiates regular TE tunnels with preemption 2 and 3, therefore:
- for interface 1 and interface 2, it needs to get the correct
unreserved bw for CT0/premption 2 (resp 3) in the 3rd (resp. 4th) position
in the "Unreserved Bw" sub-TLV of the IGP. This will be the case since this
corresponds to the TE-Class mapping of LSR1.
- it will do nothing with all the other values advertised by the
IGP in the Unreserved Bw sub-TLV. So the fact that , for example, the first
value advertised by LSR1 for interface 2 actually relates to CT1 will not
adversely affect LSR0.
LSR0 needs to get the old "Max Reservable bw" for all links. Currently the
DS-TE-PROTO draft says that if multiple CTs are used, only the new
"Bandwidth Constraint" sub-TLV is used. I guess we should change that text
to optionnaly allow advertisement of both the new Bandwidth Constraints"
sub-TLV and the old "Max Reservable Bw" in case there may be some
non-DSTE-capable LSR in the network. right?
LSR0 will advertise the old "Max Reservable Bw" sub-TLV for all its links ,
so LSR1 will know that only CT0 is currently used on all these links. Now,
even if only 2 preemptiopn priorities are used by LSR0, LSR0 will obviously
advertise 8 unreserved bw values in the IGP for what it thinks are 8
preemption priorities of regular TE. However, LSR1 will not be fooled by
the values corresponding to other CTs than CT0 (eg. 1st and 2nd value in
our example) because it knows that only CT0 is used on these links (again
because of the absence of the new Bandwidth Constraints sub-TLV). So LSR1
will not be tempted to route CT1 LSPs via LSR0.
I guess we may add some text saying that a DS-TE LSR should only make use
of Unreserved Bw [i] if there is a BC advertsied for the CT of that
TE-class on the corresponding link. right ?
If you agree with these few changes to ensure interoperability, they could
be incorporated in the next rev.
Thanks for raising this point.
Francois
>Thanks,
>sanjay
>
>-----Original Message-----
>From: Francois Le Faucheur
>To: Choudhury, Sanjaya
>Cc: 'te-wg@ops.ietf.org'
>Sent: 1/30/02 6:48 AM
>Subject: Re: More comments/questions on DS-TE solution draft
>
><snip....>
>
> >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
><snip ...>