Subject: Interoperability issues between non-DS-TE and DS-TE LSRs ( was R E: More comments/questions on DS-TE solution draft)

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Mon, 17 Jun 2002 11:58:14 -0400

Francois,
Although the solution you proposed to address the interoperability issue
between non-DS-TE and DS-TE LSRs works, I have few concerns. 
 
Consider the following new suggestions (presented in your write-up):
  
   (1) In addition to the existing configuration, now the administrator has
    to configure the CT0 entries, at a specific TE-Class index [i.e TE-Class
    index == preemption priority, for CT0].
 
    Somehow, this configuration requirements feels like a 'workaround' and
    will also make the configuration more error prone. It will be nice to
come-up 
    with a solution, without this additional user configuration requirement.

    (2) In the proposed solution, we _hope_ that the non-DS-TE LSRs will 
    never use the 'wrongly interpreted' entries in Unreserved BW TLV,
because
    we assume that only a certain subset of preemption priorities for CT0
    is used in the entire TE domain (DS-TE and non-DS-TE)
 
    It is probably a valid assumption, to assume that only certain sub-set
    of preemption priorities are used for CT0 in the entire network, but
there
    is no way to enforce this in a already deployed non-DS-TE network.
 
    (3) Now all the DS-TE LSR implementations will be required to generate
     the BC TLV.  I think this can be avoided.

I am not sure, whether the providers will view the aboved mentioned issues
as
problems or not. Thought, will share with you anyway.

Here is a possible alternative to think about:--->
 
[Tread-off: uses little more bandwidth, to reduce the dependency of user
 configuration ]
 
    1. DS-TE LSRs should advertise their bandwidth using a new unreserved
    BW TLV (similar to the ones defined in non-DS-TE LSRs, but not the 
    same).
 
    2. Hybrid DS-TE LSRs ,can generate the legacy unreserved bw TLV, in
    addition to the _new_ unreserved DS-TE BW TLV. 
    
    The legacy TE unreserved BW TLV, can contain unreserved bandwidth
    for only the CT0 preemption priorities supported in the DS-TE domain
    [unsupported ones marked as 0s?]
 
    If the entire TE domain, does not have any non-DS-TE LSRs, this
(additional)
    legacy (non-DS-TE) unreserved bw TLV, need not be generated
 
    3. non-DS-TE LSR, will not recognize the new  (DS-TE) unreserved bw TLV 
    and ignore it.
 
    4. DS-TE LSRs, can identify whether another LSR supports DS-TE or not,
    based on the receipt of the new (DS-TE) unreserved BW TLV.

Thanks,
sanjay

 

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Monday, June 17, 2002 8:18 AM
To: Jim Boyle
Cc: Francois Le Faucheur; [email-masked]' '
Subject: RE: More comments/questions on DS-TE solution draft

Jim and all,

At 22:19 15/06/2002 -0400, Jim Boyle wrote:

On Mon, 10 Jun 2002, Francois Le Faucheur wrote:

> Hi Sanjaya,
....
>
> >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

sounds good.

great.

...

>
> 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

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.

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. 
"

> 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?
>

.....

> 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 ?

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
<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.

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.

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, 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

regards,

Jim

>
> If you agree with these few changes to ensure interoperability, they could
> be incorporated in the next rev.
>
> Thanks for raising this point.
>
> Francois
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 18 Jun 2002 11:13:55 +0200

Sanjaya,

At 11:58 17/06/2002 -0400, Choudhury, Sanjaya wrote:
>between non-DS-TE and DS-TE LSRs works,

thanks for checking that it works.

>  I have few concerns.
>     never use the 'wrongly interpreted' entries in Unreserved BW TLV, because
>I am not sure, whether the providers will view the aboved mentioned issues as

This is covering old grounds.

If you remember, our very first draft proposed that DS-TE LSRs use another 
sub-TLV than the current Unreserved Bw. This proposal had lots of very nice 
properties in terms of interworking and flexibility. In particular, you 
could have any mix of new and old LSRs, they could use any preemption 
levels,...it would always work as best as achievable because LSRs could 
always work it out through IGP advertisements.

There was lots of discussion and the strong conclusion was that it was more 
important to minimise IGP advertisement than to maximise smoothness of 
transition. Hence the alignment to Jim's proposal to reuse existing sub-TLV 
for minimum IGP impact.

As you rightly pointed out, there is clearly a trade-off being "ideal 
migration" and "IGP scalability". The potential migration concerns you 
mention above are valid but they are far from unsurmountable and based on 
the discussion we've had earlier on that trade-off, they would not justify 
significant increase in IGP advertisement and completely revisiting the 
fundamental IGP approach we've selected for DSTE...

We have a solution which minimises IGP advertisment and achieves migration 
fairly well (even if not absolutely ideally). We're pretty comfortable 
migration should work with this solution since you and Jim double-checked 
me on it.

Thanks

Francois

>>> > in the "Unreserved Bw" sub-TLV of the IGP. This will be the case 
>>> since this
>>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.
>>"
>>
>>         - 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?
>>
>>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:
>>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
>>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.
>>
>>-       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
>>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'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
>>-       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.
>>
>>-       Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-TLV 
>>and use these values for CTO LSP establishment
>>will actually never use those since we assume that only preemption 2 and 
>>3 are used in the TE domain.
>>"
>>
>>Cheers
>>
>>Francois
>>
>>>regards,
>>>
>>>Jim
>>>
>>> >