Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering
draft-malis-diff-te-serviceclass-04

2002-10-25 - response
The difference is that if the RSVP message is being processed by a router
that hasn't implemented the CType,  you will get an ResvErr with error code
14 (Unknown object C-Type).

However, with Class Numbers in the range 224-255, RSVP will silently
ignore, but forward an object with a Class Number that it does not
understand, which is exactly the behavior that is needed.

2002-10-25 - note to authors
I've been asked by the IESG to review draft-malis-diff-te-serviceclass
in response to teh RFC Editor's request for advice on publishing
teh ID as a RFC

with that hat on I received a query from the RSVP designated expert
about this internet draft

> It appears to me that a much more economical approach would
> be for the 3-bits that this ID requires to be carried as a
> new CType for the existing SESSION_ATTRIBUTE object (or added to
> that object).

comments?

2002-10-25 - note from braden
draft-malis-diff-te-serviceclass, which adds an object to
carry *3* bits (the ATM service class).  Again, it appears to me
that this could be in the SESSION_ATTRIBUTE object.

2002-10-13 - note to mpls WG chairs
the RFC Editor has been asked to publish draft-malis-diff-te-serviceclass
as an info RFC

since (if memory serves) RSVP-TE came out of the MPLS WG
1/ do you as chairs have any opinion on this document?
2/ if you think its reasonable to ask the MPLS WG list what they think?