Subject: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling

From: "Pandian, Vijay" <[email-masked]>
Date: Tue, 12 Sep 2006 08:39:08 -0400

Hi,
 
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?
 
Should we consider C-Type = 1 as obsolete?
 
Regards,
 
Vijay

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 17 Sep 2006 10:49:33 +0100

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