Re: RFC 2370 Update and a Proposed Change to Stub Area Behavior

[Acee Lindem <[e-mail]>]

Any other views on this?

Acee Lindem wrote:

> In the evolution of the OSPFv2 protocol specification
> (RFC 1247->RFC 1583 -> RFC 2178 -> RFC 2328) numerous
> bugs were fixed and some protocol behaviors were altered. Examples
> include the metric cost for area ranges and the selection of the
> ASBR for AS external route computation.
>
> In the context of documenting the OSPFv3 NSSA differences I've
> looked again at section 2.10 and I really think the idea of not flooding
> unknown LSA types with the U-bit set to 1 is broken. I think it breaks
> the whole idea of being able to introduce new LSA types in a backward
> compatible fashion. Furthermore, it won't stop the leakage of these
> unknown LSAs when some routers understand them and others do not -
> it all depends on whether you have a spanning tree of routers that
> understand them. Since the LSAs in question are area scoped or link
> scoped, it implies that at least one router (the originator) 
> understands the
> new type and you will have a mixture. IMHO, this is broken. I've had
> some discussions with others who agree. At this juncture,
> we have 3 alternatives:
>
>    1) Remove the restriction for that unknown LSAs with the U-bit
>        set to 0 for stub areas.
>    2) Extend the broken restriction to NSSAs in the update.
>    3) Limit the damage to stub areas and only restrict AS scoped LSAs
>        from NSSAs.
>
> Of course, I'd vote for #1 or I wouldn't be sending this E-mail.
>
> Thanks,
> Acee
>