[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interoperability issues between non-DS-TE and DS-TE LSRs ( was R E: More comments/questions on DS-TE solution draft)
Sanjaya,
At 11:58 17/06/2002 -0400, Choudhury, Sanjaya wrote:
Francois,
Although the solution you
proposed to address the interoperability issue
between non-DS-TE and DS-TE
LSRs works,
thanks for checking that it 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).
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
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:flefauch@cisco.com]
Sent: Monday, June 17, 2002 8:18 AM
To: Jim Boyle
Cc: Francois Le Faucheur; ''te-wg@ops.ietf.org' '
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
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
>