Subject: RE: ClassType object for Signalling? Routing? Neither?

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Fri, 22 Feb 2002 18:20:26 -0500

I support (1), signaling only.  I don't see the need to extend the IGP.

Jerry Ash

-----Original Message-----
From: Jim Boyle [mailto:[email-masked]]
Sent: Friday, February 22, 2002 12:45 PM
To: [email-masked]
Subject: ClassType object for Signalling? Routing? Neither?

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 25 Feb 2002 16:24:58 +0100

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 25 Feb 2002 16:35:37 +0100

Jim,

At 20:55 23/02/2002 -0500, Jim Boyle wrote:

>but most concerning...
>
>-) You can get in a situation where a transit node doesn't recognize the
>class type object and rejects the path message.  What is the head end to
>do now?  One approach would be to wait 15 seconds and try again.  Or would
>it "poison" it in its local database? (and for how long - what if the
>transit node gets upgraded with functionality later?).  There's something
>explicit in the signalling, but nothing to match it up against in the IGP.

As mentioned in my earlier email, the optional "bandwidth constraint 
sub-TLV" (of the current approach) can be used to ensure that the above 
situation will not occur. This is a form of (2).

>In (3), where signalling and IGP are implicitly interpreted as TEClasses,
>one could actually signal through a legacy TE portion of the domain w/o
>problem (for better or for worse).  With (1) - you can't, and it's hard to
>say how you cope with the situation.  At least in (2) - you can avoid non
>DSTE capable portions of your network.  So I think (2) is better than (1),
>but (3) is best of all (in my opinion).

If the above situation did occur for some reason, the outcome of options 
(1/2) seems preferable to me over the outcome of (3).
In other words, if there is an inconsistency and a Head-End LSR attempts to 
set up a CT1 LSP through an LSR which is not DS-TE capable, then I feel the 
LSP should be rejected since its whole purpose is to be established to meet 
some specific constraints (e.g. BC1). Setting up the LSP anyway "for better 
or for worse" (ie without being able to satisfy its BC1 constraint) seems 
undesirable to me. It would result in the Head-end being fooled into 
thinking it has set-up a CT1 LSP when it actually has not. So far in TE, a 
TE LSP is only established when we know for sure that it satisfies all the 
constraints. I think we should retain that principle.
Note also that with options (1/2) as specified in the current draft, you 
can still establish CT0 LSPs across a mix of LSRs which support DSTE and 
LSRs which do NOT support DS-TE.

I'd say this current behaviour is the desirable one:
         - allow establishment of CT0 LSPs in heterogeneoud environments 
(TE LSRs & DS-TE LSRs) since you can guarantee all specified constraints 
are met (this allow backward compatibility)
         - do not allow establishment of LSPs from other CTs in 
heterogeneous environments, since you can not meet the specified constraints.
No?

Francois