[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ClassType object for Signalling? Routing? Neither?
Jim and all,
I consider that the approach in the current draft :
- assumes (1) as the default mode
- but already allows a flavour of (2) as an option. For instance,
if you use the optional "bandwidth constraint sub-TLV" which advertises a
"bandwidth constraint model id" as well as the bandwidth constraints for
all active classes, the LSR can check that all other relevant LSRs (i) are
DSTE capable, (ii) support the same Bandwidth Constraint Model and (iii)
support the considered CT.
I vote for retaining that approach:
- 1) by default
- 2) optionally (for the most essential DSTE information)
Cheers
Francois
At 12:45 22/02/2002 -0500, Jim Boyle wrote:
>In the protocol draft:
>
>http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-00.txt
>
>A new object is introduced for explicitily signalling the class-type (see
>for example section 2 of appendix A).
>
>This differs from the use of the use of the TEClass in the IGP
>advertisements, where TEClass[i] is mapped to a unique ClassType and
>preemption priority.
>
>The intention was to allow for existing semantics over the setup and hold
>priorities. However there some discussion on this approach compared to
>having those fields again being TEClass values (which would map into
>ClassType and preemption priority on the router).
>
>The specific question that we have for the WG is the following:
>
>Would it be preferable to:
>
>(1) Keep it as in the draft with ClassType object in signalling and
>inferred TEClasses in the IGP.
>
>(2) Keep the ClassType object in the signalling, but also add additional
>information in the IGP to communicate throughout the TE domain which nodes
>are DS-TE capable, and perhaps some limited amount of additional
>information.
>
>(3) Use inferred TEClasses in both the signalling and the IGP (e.g. no new
>objects, just semantics).
>
>Briefly, should we add explicit DS-TE information such as ClassType to:
>(1) Signalling only
>(2) Signalling and Routing
>(3) Neither
>
>regards,
>
>Jim