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
- PROTECTION Object in draft-ietf-ccamp-gmpls-recov… Pandian, Vijay
- Re: PROTECTION Object in draft-ietf-ccamp-gmpls-r… Adrian Farrel