Re: ClassType object for Signalling? Routing? Neither?

[Francois Le Faucheur <flefauch@cisco.com>]

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