[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Interoperability issues between non-DS-TE and DS-TE LSRs ( was RE: More comments/questions on DS-TE solution draft)
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
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
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
>