Subject: [OSPF] LSA types in draft-ietf-ospf-mt-ospfv3-03

From: Paul Wells <[email-masked]>
Date: Thu, 06 Sep 2007 11:13:08 -0500

Hi Sina, Abhay,

Looking at draft-ietf-ospf-mt-ospfv3-03 think there may be a 
problem in section 5 with the definition of a "T-bit".

RFC 4970 section 5 has defined an IANA registry for OSPFv3 LSA 
function codes that defines 256-8175 as reserved, 8176-8183 as 
Experimental, and 8184-8191 vendor private. So, it would seem that 
any experimental or vendor defined LSA types would of necessity 
set the proposed T-bit. A lesser problem is that the LSA types 
proposed in the draft would fall into the Reserved range.

Might I suggest that there isn't really a need for an explicitly 
defined T-bit, and that the new set of LSAs could equally well be 
assigned from the 13-255 "Unassigned" range instead.

Regards,
Paul

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: Abhay Roy <[email-masked]>
Date: Fri, 7 Sep 2007 16:51:48 -0700 (PDT)

Good point. We will fix this in the next rev. We still like
the bit idea though, so that we can easily infer the well
known function codes easily enough.

Regards,
-Abhay

On 09/06/07-0500 at 11:13am, Paul Wells writes:

> Hi Sina, Abhay,
>
> Looking at draft-ietf-ospf-mt-ospfv3-03 think there may be a problem in 
> section 5 with the definition of a "T-bit".
>
> RFC 4970 section 5 has defined an IANA registry for OSPFv3 LSA function codes 
> that defines 256-8175 as reserved, 8176-8183 as Experimental, and 8184-8191 
> vendor private. So, it would seem that any experimental or vendor defined LSA 
> types would of necessity set the proposed T-bit. A lesser problem is that the 
> LSA types proposed in the draft would fall into the Reserved range.
>
> Might I suggest that there isn't really a need for an explicitly defined 
> T-bit, and that the new set of LSAs could equally well be assigned from the 
> 13-255 "Unassigned" range instead.
>
> Regards,
> Paul
>