Hi Vijay,
What is the rationale behind defining a new C-Type ( C-Type = 2, suggested value, TBA by IANA) for the PROTECTION Object in the e2e draft instead of extending C-Type = 1 defined in rfc3473?
If you are familiar with the way RSVP has been developed over the years you will notice that this is standard practice.
Consider the Session_Attribute object in RFC 3209. You will see two different C-Types here according to the content of the object.
Perhaps a better example is the RSVP Hop object. This appears in RFC 2205 with C-Types 1 and 2 (for different uses) and is extended in RFC 3473 with two new C-Types.
The C-Type is used to distinguish sub-types of the same object. This is, of course, useful, in normal implementation because it means that we don't have to make assumptions about the object's contents from parsing other fields (like the length). It is particulalry useful when a new variant of an object is introduced because it enables backward compatibility problems to be detected - a legacy implementation that does not support the new C-Type will reject the message (see RFC 2205) and the message sender can then take action to avoid the problem.
In the case of draft-ietf-ccamp-gmpls-recovery-e2e-signaling, you'll notice that although the format of the first 8 bytes of the C-Type2 Protection object matches the C-Type1 Protection object in RFC 3473 with the adoption of some of the reserved bits, an extra 32 bit reserved field is added to the end of the object. (As indicated in draft-ietf-ccamp-gmpls-recovery-e2e-signaling, these 32 bits are defined in draft-ietf-ccamp-gmpls-segment-recovery.) So the processing for the two C-Types is different and it is useful to be able to distinction them through a different code point.
Should we consider C-Type = 1 as obsolete?
Why?You must interoperate with 3473 implementations (always assuming interop is on your agenda) and any implementation not wanting e2e or segment protection can continue to use C-Type 1.
Adrian