Re: [OSPF] OSPF Link Local Signalling
"Abhay D.S" <abhayds@acm.org> Wed, 15 November 2006 02:25 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkATL-0002BK-K7; Tue, 14 Nov 2006 21:25:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkATI-00025A-68 for ospf@ietf.org; Tue, 14 Nov 2006 21:25:52 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkATE-00075M-W5 for ospf@ietf.org; Tue, 14 Nov 2006 21:25:52 -0500
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8R00BN52JR47@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 15 Nov 2006 10:21:27 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8R000BG2JQ3P@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 15 Nov 2006 10:21:27 +0800 (CST)
Received: from [127.0.0.1] ([10.111.34.184]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8R00IA72JP40@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 15 Nov 2006 10:21:26 +0800 (CST)
Date: Wed, 15 Nov 2006 10:21:25 +0800
From: "Abhay D.S" <abhayds@acm.org>
Subject: Re: [OSPF] OSPF Link Local Signalling
In-reply-to: <455A42D0.8090100@cisco.com>
To: Acee Lindem <acee@cisco.com>
Message-id: <455A79A5.5020208@acm.org>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_Pd94eORcs790R2i38s3Kjw)"
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
References: <455A42D0.8090100@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: OSPF List <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: abhayds@acm.org
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org
This draft seems like good reading. Why we might want to waste the TLV space now ? We also have the OSPFv2 router capabilities draft with local LSA's. - Abhay D.S Acee Lindem wrote: > As you all know, we have OSPF Link-local Signaling > (draft-ietf-ospf-lls-01.txt) > as WG document. However, I don't believe we can get IANA to manage the > TLV type number space until the document is published. > > In the interim, Abhay Roy <akr@cisco.com> has volunteered to manage the > allocations for LLS TLVs. Please contact him directly if you have a > draft that > will require a unique code point. I'm more concerned with collisions > than having > holes in the space due to drafts not making it all the way to RFC. > > I've excerpted the IANA considerations section from the draft below: > > LLS TLV types are maintained by the IANA. Extensions to OSPF which > require a new LLS TLV type MUST be reviewed by an designated expert > from the routing area. > > Following the policies outlined in [IANA], LLS type values in the > range of 0-32767 are allocated through an IETF Consensus action and > LLS type values in the range of 32768-65536 are reserved for private > and experimental use. > > This document assigns the following LLS TLV types in OSPFv2/OSPFv3. > > TLV Type Name Reference > 0 Reserved > 1 Extended Options [RFCNNNN]* > 2 Cryptographic Authentication+ [RFCNNNN]* > 3-32767 Reserved for assignment by the IANA > 32768-65535 Private Use > > *[RFCNNNN] refers to the RFC number-to-be for this document. > + Cryptographic Authentication TLV is only defined for OSPFv2 > > > This document also assigns the following bits for the Extended > Options bits field in the EO-TLV outlined in Section 2.5: > > Extended Options Bit Name Reference > 0x00000001 LSDB Resynchronization (LR) [OOB] > 0x00000002 Restart Signal (RS-bit) [RESTART] > > > Other Extended Options bits will be allocated through an IETF > consensus action. > > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > >
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf
- [OSPF] OSPF Link Local Signalling Acee Lindem
- Re: [OSPF] OSPF Link Local Signalling Abhay D.S
- Re: [OSPF] OSPF Link Local Signalling Acee Lindem