Subject: ClassType object for Signalling? Routing? Neither?

From: Jim Boyle <[email-masked]>
Date: Fri, 22 Feb 2002 12:45:13 -0500 (EST)

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: Kireeti Kompella <[email-masked]>
Date: Fri, 22 Feb 2002 11:58:17 -0800 (PST)

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.

---

From: Nabil Seddigh <[email-masked]>
Date: Fri, 22 Feb 2002 19:05:40 -0500

I would say that (3) is not desirable. Ideally (2) is the cleanest
solution. However since the "Unreserved BW" TLV has been redefined
to carry bw info per TE class instead of per-premption priority, 
then (1) is an acceptable compromise.

Nabil Seddigh

---

From: Jim Boyle <[email-masked]>
Date: Sat, 23 Feb 2002 20:55:18 -0500 (EST)

> signaling different anyway.

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

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 26 Feb 2002 11:15:02 -0500

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

Interesting idea but I think we would want to stay away from 
redefining the setup/hold priorities as not all MPLS networks
necessarily want to do TE.

> Here are some of the issues I have with the classtype object 
> in signaling. 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

Is the intention to allow the CT object to pass through such
nodes without being rejected? i.e to signal through the legacy
part of the network? If so, RSVP allows this. If IANA assigns
a class-num greater than C0 for the Class-Type object then 
nodes that don't recognize it will simply forward it thru.

---
Best,
Nabil Seddigh
[email-masked]

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 26 Feb 2002 19:05:28 +0100

Nabil,

At 11:15 26/02/2002 -0500, Nabil Seddigh wrote:

>nodes without being rejected?

As discussed in my earlier email, I recommend that:
         - it should be possible to establish a CT0 LSP (ie regular TE 
LSPs) across DSTE-capable and DSTE-incapable LSRs
         - it should not be possible to establish a CT1/CT2/... LSP across 
DSTE-incapable LSRs

The current proposal already achieves that by:
         - signalling CT0 LSPs without a CT object
         - signalling CT1/CT2/... with a CT object whose class-num is of 
the form 0bbbbbbb.

Cheers

Francois

>i.e to signal through the legacy

---

From: Nabil Seddigh <[email-masked]>
Date: Tue, 26 Feb 2002 14:11:01 -0500

Francois,

So there appears to be 2 different types of desired behaviour
for CT1, CT2 across legacy networks. Jim appears to want to 
signal through it while you prefer to reject the LSP setup.

Which one is desired?

I would suggest settling on the behaviour - once that's done the
solution can emerge.

Best,
Nabil

p.s. The different treatment of CT0 vs other CTs mentioned below
   is acceptable though it is a bit messy.

Francois Le Faucheur wrote:
>   - it should be possible to establish a CT0 LSP 
>   (ie regular TE LSPs) across DSTE-capable and DSTE-incapable LSRs
>   a) signalling CT0 LSPs without a CT object
>   b) signalling CT1/CT2/... with a CT object whose class-num 
>            is of the form 0bbbbbbb.
> 
> Cheers
> 
> Francois