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