Re: ClassType object for Signalling? Routing? Neither?

[Jim Boyle <jboyle@pdnets.com>]

On Fri, 22 Feb 2002, Kireeti Kompella wrote:

> I would go with (1) (ClassType object in signalling, inferred TEClasses
> in the IGP).
>
> It is a bit asymmetric, but the notion of 'hold priority' makes
> signaling different anyway.
>
> Kireeti.
>

But the Setup/Hold could now be the Setup/Hold TEClasses.

Here are some of the issues I have with the classtype object in signaling.

-) you can now have two different class-types signalling with the same
signalled value in the setup/hold priority fields
-) what is signalled is not identical to what is signalled upon (e.g.
TEClass[4] in IGP might become {Class Type 1, preemption 3} in
signalling.  I'm not sure either of above are intuitive

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.

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).

So, for me, my preference is (3), no new DS-TE objects in routing or
signalling.

regards,

Jim