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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 17 September 2006 09:56 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOtOR-0000Gr-My for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:56:55 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOtOQ-0002ml-Cm for ccamp-archive@ietf.org; Sun, 17 Sep 2006 05:56:55 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1GOtLD-000KgE-Qm for ccamp-data@psg.com; Sun, 17 Sep 2006 09:53:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1
Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1GOtLC-000Kfl-JO for ccamp@ops.ietf.org; Sun, 17 Sep 2006 09:53:34 +0000
Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1GOtLK-0005KH-00 for ccamp@ops.ietf.org; Sun, 17 Sep 2006 10:53:42 +0100
Received: from your029b8cecfe ([217.158.132.59] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Sep 2006 10:53:29 +0100
Message-ID: <099001c6da3f$19350de0$0a23fea9@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>, ccamp@ops.ietf.org
References: <0679BA70A2F59E49B186858B47F4595C4E015B@viper.sycamorenet.com>
Subject: Re: PROTECTION Object in draft-ietf-ccamp-gmpls-recovery-e2e-signaling
Date: Sun, 17 Sep 2006 10:49:33 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 17 Sep 2006 09:53:31.0708 (UTC) FILETIME=[2221E7C0:01C6DA3F]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa

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