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

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 10 Jun 2002 16:21:19 +0200

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: [email-masked]'
>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 ...>

---

From: Jim Boyle <[email-masked]>
Date: Sat, 15 Jun 2002 22:19:39 -0400 (EDT)

> Hi Sanjaya,
....
>          - the index for each of these TE-classes is equal to the

sounds good.

...

> parameter), say for example

well, it doesn't quite say that, but it seems to be heading in that
direction.  That object is supposed to be optional, for those that
prefer efficiency over verbosity.  We should revisit the text to make
the optionality clear.  E.g. the line "When DS-TE is deployed and
multiple CTs are used, the new Bandwidth Constraints sub-TLV is
used" should read "may be used".  (in fact no reason it can't be used
when there is only BC0 - though I suppose that's totally pointless.

> non-DSTE-capable LSR in the network. right?

.....

> TE-class on the corresponding link. right ?

Hmmm.  I think we're heading towards option (2) of the thread in:

http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00017.html

The BC sub-object should remain optional.  I like the philosophy of
just checking the reservable bandwidth at the appropriate priority or
te-class (for standard and dste routers respectively), w/o *having* to
do all sorts of other checks.

regards,

Jim

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 17 Jun 2002 14:18:00 +0200

Jim and all,

> >          - the index for each of these TE-classes is equal to the

great.

>when there is only BC0 - though I suppose that's totally pointless.

When I drafted new text last Friday to reflect that point, I also noticed 
the optionality wasn't well expressed. Here is the text I came up with. 
Could you check it out:

"
A DS-TE LSR which elects to advertise Bandwidth Constraints MUST use the 
new "Bandwidth Constraints" sub-TLV to do so. For example, where a Service 
Provider deploys DS-TE with two active CTs, only two Bandwidth Constraints 
per link would be meaningful (assuming, for instance, the Russian Doll 
Bandwidth Constraint Model defined in section 9). Assuming the Service 
Provider elects to advertise Bandwidth Constraints, the "Bandwidth 
Constraints" sub-TLV would then be used and should contain BC0 and BC1.

A DS-TE LSR which elects to advertise Bandwidth Constraints MAY also 
include the existing "Maximum Reservable Bw" sub-TLV. This may be useful in 
migration situations where some LSRs in the network are not DS-TE capable 
(see Appendix G) and thus do not understand the new "Bandwidth Constraints" 
sub-TLV. The DS-TE LSR MUST set the value of the "Maximum Reservable Bw" 
sub-TLV to the same value as the one for BC0 encoded in the "Bandwidth 
Constraints" sub-TLV.

A DS-TE LSR receiving both the old "Maximum Reservable Bw" sub-TLV and the 
new "Bandwidth Constraints" sub-TLV for a given link MAY ignore the 
"Maximum Reservable Bw" sub-TLV.
"

While we're on that section, here is what I drafted for that same section 
to reflect the discussion on multiple BC Models being allowed:

"A DS-TE LSR receiving the "Bandwidth Constraints" sub-TLV with a Bandwidth 
Constraint Model Id which does not match the Bandwidth Constraint Model it 
currently uses, MAY generate a warning to the operator reporting the 
inconsistency between Bandwidth Constraint Models used on different links. 
If the DS-TE LSR does not support the Bandwidth Constraint Model designated 
by the Bandwidth Constraint Model Id, or if the DS-TE LSR does not support 
operations with multiple simultaneous Bandwidth Constraint Models, the 
DS-TE LSR MUST discard the corresponding TLV.
"

>do all sorts of other checks.

I woudl also like to see the BC sub-TLV being optional in the general case.
What I am proposing is that:
         - in normal DS-TE deployment where all LSRs have been upgraded and 
are DS-TE capable, then the BC sub-TLV is optional.
         - in teh special case of migration, where some LSRs have not been 
upgraded and are not DS-TE capable, then BC sub-TLV needs to be used to 
help the DS-TE capable LSRs achieve  backwards compatibilitry. Clearly, the 
BC sub-TLV can stop be advertised once migration is completed.

Is that accaptable?

Assuming the above, I have drafted an additional Appendix describing 
operations in such hybrid scenario. Again, comments welcome:

"
Appendix G  Interoperability with non DS-TE capable LSRs

This DSTE solution allows operations in a hybrid network where some LSRs 
are DS-TE capable while some LSRs and not DS-TE capable. This Appendix 
discusses the constraints and procedures of such hybrid operations.

We refer to the set of DS-TE capable LSRs as the DS-TE domain. We refer to 
the set of non DS-TE capable (but TE capable) LSRs as the TE-domain.

Hybrid operations requires that the TE-class mapping in the DS-TE domain is 
configured so that:
-       a TE-class exist for CT0 for every preemption priority actually 
used in the TE domain
-       the index in the TE-class mapping for each of these TE-classes is 
equal to the preemption priority.

Another way to look at this is to say that, the whole TE-class mapping does 
not have to be consistent with the TE domain, but the subset of this 
TE-Class mapping applicable to CT0 must effectively be consistent with the 
TE domain.

In such hybrid networks :
-       CT0 LSPs can be established by both DS-TE capable LSRs and non-DSTE 
capable LSRs
-       CT0 LSPs can transit via (or terminate at) both DS-TE capable LSRs 
and non-DSTE capable LSRs
-       LSPs from other CTs can be only be established by DS-TE capable LSRs
-       LSPs from other CTs can only transit via (or terminate at)  DS-TE 
capable LSRs

Note that, for such hybrid operation, non DS-TE capable LSRs need to accept 
Unreserved Bw sub-TLVs containing non decreasing bandwidth values (ie with 
Unreserved [p] < Unreserved [q] with p <q ). Also, Bandwidth Constraints 
need to be advertised.

Let us consider, the following example to illustrate operations:

LSR0--------LSR1----------LSR2
      Link01       Link12

Where:
         LSR0 is a non-DS-TE capable LSR
         LSR1 and LSR2 are DS-TE capable LSRs

Let's assume that preemption 2 and 3 are used in the TE-domain and that the 
following TE-class mapping is configured on LSR1 and LSR2:
         i   <--->       CT      preemption
       ====================================
         0               CT1     0
         1               CT1     1
         2               CT0     2
         3               CT0     3
         rest                    unused

LSR0 is configured with a Max Reservable bandwidth=m for Link01.
LSR1 is configured with a BC0=x0 and a BC1=x1(possibly=0) for Link01.

LSR0 will advertise in IGP for Link01:
-       Max Reservable Bw sub-TLV = <m>
-       Unreserved Bw sub-TLV = 
<CT0/0,CT0/1,CT0/2,CT0/3,CT0/4,CT0/5,CT0/6,CT0/7>

On receipt of such advertisement, LSR1 will:
-       understand that LSR0 is not DS-TE capable because it advertised a 
Max Reservable Bw sub-TLV and no Bandwidth Constraint sub-TLV
-       conclude that only CT0 LSPs can transit via LSR0 and that only the 
values CT0/2 and CT0/3 are meaningful in the Unreserved Bw sub-TLV. LSR1 
may effectively behave as if the the six other values contained in the 
Unreserved Bw sub-TLV were set to zero.

LSR1 will advertise in IGP for Link01:
-       Max Reservable Bw sub-TLV = <x0>
-       Bandwidth Constraint sub-TLV = <BC Model ID=0, x0,x1>
-       Unreserved Bw sub-TLV = <CT1/0,CT1/1,CT0/2,CT0/3,0,0,0,0>

On receipt of such advertisement, LSR0 will:
-       Ignore the Bandwidth Constraint sub-TLV (unrecognized)
-       Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-TLV and 
use these values for CTO LSP establishment
-       Incorrectly believe that the other values contained in the 
Unreserved Bw sub-TLV relates to other preemption priorities for CT0, but 
will actually never use those since we assume that only preemption 2 and 3 
are used in the TE domain.
"

Cheers

Francois

---

From: Jim Boyle <[email-masked]>
Date: Mon, 17 Jun 2002 12:30:17 -0400 (EDT)

> sub-TLV to the same value as the one for BC0 encoded in the "Bandwidth

I worry about removing the Max reservable BW sub-TLV, even though it
is redundant.  Any concern about implementations which expect it?
Maybe we should always include it, regardless of if one chooses to
additionally advertise a BC sub-TLV?

> DS-TE LSR MUST discard the corresponding TLV.

change the last Must to May.  Afterall, nothing is stopping a head end
who doesn't understand a remote bandwidth constraint model from still
signalling against bandwidth that is advertised as available to a
specific TE Class.

> > > non-DSTE-capable LSR in the network. right?

yes.

> BC sub-TLV can stop be advertised once migration is completed.

If we start to use the BC sub-TLV to mean "I'm DSTE capable" - should
we maybe add a field to that effect - or just add another TLV to that
effect?

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 18 Jun 2002 10:34:19 +0200

Jim,

>additionally advertise a BC sub-TLV?

Today Max Reservable is only optional anyway, so I don't think any 
implementation should "always expect it".
Current text allows:
         - in the interim, during migration and interoperation with old 
LSRs, you may advertise it.
         - in the long run when all LSRs are upgraded, you don't have to 
advertise it, but you may if you want.
I don't think we should mandate always advertising it since it is 
completetly redundant when all LSRs are DSTE capable. We've had lots of 
pressure to minimise IGP extensions, so I am really relunctant to keep 
something redundant in there.
Kireeti made a similar point a while back when the earlier draft proposed a 
different variation (ie BC0 stayed in Max Reservable and BC-sub-TLV only 
advertised BC1, BC2,...) : Kireeti pointed out it would be simpler in the 
long run with a single sub-TLV for all BCs.

>signalling against bandwidth that is advertised as available to a

Fair enough. Done.

>we maybe add a field to that effect - or just add another TLV to that

We could certainly do that. This is the approach of explicitely signaling 
"DS-TE capability" on new LSRs. The drawback I see of such an approach is 
that it would result in some additional information being always advertised 
in the IGP for ever and ever, just to resolve a temporary migration issue.

The approach currently proposed is more like inferring "DS-TE incapability" 
of old LSRs. It forces use to use an existing sub-TLV in a particular way 
during transition, but the benefit is that once LSRs are all upgraded you 
are back to a minimised IGP signaling ie you can leave with ONLY 
advertising the 8bw values of "Unreserved BW " sub-TLV and that's it.
Again, because we had so much pressure to minimise IGP signaling, I favor 
the current approach.

No?

Francois

---

From: Jim Boyle <[email-masked]>
Date: Tue, 18 Jun 2002 13:59:33 -0400 (EDT)

...

> Again, because we had so much pressure to minimise IGP signaling, I favor

yes - I can see a migration w/o the BC sub-TLV, but if one must, then
right, it'll do.