Subject: Re: OSPFv2 Opaque LSAs in OSPFv3

From: Bill Fenner <[email-masked]>
Date: Tue, 15 Oct 2002 20:52:38 -0700

To avoid misunderstandings: although I am contributing to this discussion
because I am an AD, this message is a technical contribution, not a ruling
from on high.  I'd like to actually have the discussion, not make a mandate,
so please treat this like you would treat a technical contribution from
anyone else.

Kireeti says:
>there are a *small* number of
>currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more.
>If we analyse the applicability of those LSAs to OSPF v3, and mandate
>that any future definition of an OSPFv2 Opaque LSA MUST have a similar
>analysis, that seems to me to address the "backdoor" problem.

Let's step back half a step and look at this solution -- documenting
the v3 applicability of the existing Opaque LSAs and requiring documentation
of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each
OSPFv2 Opqaue LSA type.

Boiling it down to the basics, OSPFv2 Opaque LSAs have a flooding
scope (type 9, 10 or 11), an 8-bit type and a 24-bit LS [Opaque] ID.
All OSPFv3 LSAs have a flooding scope (the top 2 bits of the LS Type),
a 14-bit type and a 32-bit LS ID.

Given this, why is it better to allocate a single OSPFv3 type for
this purpose?  Presumably, the real place that code reuse comes into
play is in parsing the contents of the LSA, not the header; the OSPFv2
and OSPFv3 headers are only subtly different but different enough that
you're not going to use the same code to parse both of them anyway.

Using the native OSPFv3 LSA format instead of a copied Opaque format
gives you more bits in the type space and more bits in the LS ID.
It also gives you the flexibility to standardize independently;
you may want to standardize an OSPFv2 Opaque LSA before the implications
of that type on OSPFv3 is fully understood.  With a shared space,
and your suggestion of analyzing the OSPFv3 implications of any Opaque
LSA, that wouldn't be allowed.  Finally, it also allows a proposal to
utilize the OSPFv3 U bit, if the non-global behavior is desired.

Perhaps I'm missing something, but it seems that saying "OSPFv2
type-10 LSA opaque type #4, OSPFv3 type-0xa014, LSA contents ____" is
not significantly different than saying "OSPFv2 type-10 LSA, OSPFv3
type-(whatever 10 maps to) LSA, opaque type #4, LSA contents ____".

  Bill

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Oct 2002 11:17:58 -0400

I originally thought that we'd simply define an opaque LSA type
for OSPFv3. However, after hearing all the arguments, I think that defining
a new LSA type for each OSPFv3 application is the right direction. In
addition to Bill's points, I think that defining unique LSA types
will lend itself to a more natural implementation and user interface
for handling application specific LSAs.

--
Acee

---

From: Rohit Dube <[email-masked]>
Date: Wed, 16 Oct 2002 12:28:17 -0400

On Wed, 16 Oct 2002 11:17:58 -0400 Acee Lindem writes:
=>I originally thought that we'd simply define an opaque LSA type
=>for OSPFv3. However, after hearing all the arguments, I think that defining
=>a new LSA type for each OSPFv3 application is the right direction. In
=>addition to Bill's points, I think that defining unique LSA types
=>will lend itself to a more natural implementation and user interface
=>for handling application specific LSAs.

Having gone back and forth on this a couple times, I come out the same
way : (most) code should still be reusable even as new protocol
objects have a better chance of being well specified with this approach.

Regards,
--rohit.

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 16 Oct 2002 09:56:09 -0700

Bill,

> of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each

if you want to allocate a new LSA type for each opaque type ( or better say
for each new LSA introduced ) then we won't need to call this opaque LSA,
you basically want to go to the idea of 'introducing a new LSA type' for
each 'new LSA defined' and we will end up with many, many LSA type which I
am not sure is a clean way ...

> a 14-bit type and a 32-bit LS ID.

I believe it is better to have opaque LSA as it was introduced in v2 that
is, use LSID to break it down to Opaque type and instance, if you are
concerned about 'bit shortcoming' for those fields we could always add more
Functional code in LS type to handle this.
since flooding is now explicitly coded, we could allocate a range say 10-20
for opaque LSA
so if we are done with FC = 10 as it was introduced in Kireeti draft and
used all the bits for opaque type in LS ID  we will use FC = 11 etc

that way we honor the name opaque LSA ;-) and won't introduce a new LSA type
every time we need to define a LSA

also it is not because we define opaque in v3 the same way as in v2 ( that
is, using LS ID for opaque type and instance ) that we have to sync
completely between v2 and v3, ospfv3 could have its own opaque type to be
defined / standardized independently ...

Sina

Outgoing messages scanned and certified safe by Stop-Sign, the Personal Alarm Service.
http://defender.veloz.com/dlp_ban/?n=tl&sp=08.out002

---

From: Dennis Ferguson <[email-masked]>
Date: Thu, 17 Oct 2002 10:29:58 -0700

Sina,

> am not sure is a clean way ...

Why is having "many, many LSA types" any less clean than having many, many
opaque LSA types?  What difference does it make whether you need to look at
the LSA type or the opaque LSA's internal type to determine if you recognize
it?  Note that if you don't recognize the LSA type OSPFv3 already forces you
to implement the procedures both to handle any number of unrecognized LSAs
and to flood them properly in any case, so why would you want to add yet
more code to the implementation to do the same thing a different way?  If
there's anything unclean about this it would be adding a second way to
provide functionality which already exists, and must be implemented,
in the protocol.

To be clear, I think the proper way to handle moving functionality from
OSPFv2 Opaque LSAs to OSPFv3 is to take the LSA-type+Opaque-type and map
it to an OSPFv3 LSA-type+flooding-scope.  I am still concerned that there
be a way to specify the contents of the OSPFv2 LSA-type+Opaque-type, or
an equivalent OSPFv3 LSA-type+flooding-scope, in a single document, but
adding Opaque LSAs themselves to OSPFv3 (as opposed to mapping the contents
of a particular OSPFv2 opaque LSA type to an OSPFv3 LSA type) is an orthogonal
issue which adds no new functionality to the protocol, but requires that
every write code to support a second way to do the same thing.  This doesn't
seem to make much sense.

If there was some advantage to Opaque LSAs over OSPFv3's generic LSA flooding
procedures I think the time to point this out was the 3 years between
1996, when OSPFv3's flooding procedures were first proposed, and 1999,
when the document became an RFC, so that the generic procedures could be
removed (like OSPFv2) and Opaque LSAs added instead.  No matter how it is
done there needs to be only one way to do it, and OSPFv3 already has a way.

> every time we need to define a LSA

But you've still not pointed out what is wrong with introducing a new LSA
type every time you need one.  OSPFv3 makes everyone write code to handle
this, so what is wrong with making use of that code?

> defined / standardized independently ...

But OSPFv3 has already has its own opaque type.  It is an LSA type you don't
understand with a flooding scope that you do understand.  What's the use
of having another one?

Dennis Ferguson

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 17 Oct 2002 19:46:12 -0700

>provide functionality which already exists, and must be implemented,
Dennis,  I suspect it's connected to certain IAB's members' recent
hysteria as to 'opaque LSAs are a big security problem and de-facto
allow vendors to
do non-interoperable things under the cloak of IETF by using
non-documented opaques'.
Not much sense in it but that's what goes around ...

    -- tony

---

From: Sina Mirtorabi <[email-masked]>
Date: Thu, 17 Oct 2002 11:44:03 -0700

Dennis,

> it?

not much, however I guess opaque LSA was introduced in order to not define a
new LSA type for each LSA needed therefore staying on the same logic for v3
looked to me natural ( but see more below )

> Note that if you don't recognize the LSA type OSPFv3 already
> forces you

agree, however we could still define all the opaque type having the same
flooding scope on a given FC. therefore by setting the flooding scope bit of
this FC we won't need to add more code ...

> every write code to support a second way to do the same thing.

I think maping directly might not always work, imagine we have a opaque type
between 1-9 that could conflict with FC 1-9 that are already defined...
so we would probably have to define a new LSA type and could not simply use
/ or map ( at least direct mapping ) the opaque ID in v2 already defined (or
will be defined) to v3 given that those opaque could be used in v3 although
the content might be different

> done there needs to be only one way to do it, and OSPFv3 already

I am not arguing about flooding scope definition in v3 versus v2 way of
flooding scope (through opaque)
just that having the same opaque ID as for v2 could accelerate defining same
functionality in v3 by using the same opaque ID number ( when applicable)

> this, so what is wrong with making use of that code?

we could use the same opaque ID already defined in v2 which apply also to v3
for example PCSD LSA already define address type so if we have the opaque ID
we won't need to wait to allocate a new LSA type

as far as flooding scope and code, as I mentioned above we could define all
the opaque type that requires the same flooding scope in a given FC and use
that FC flooding bit to handle flooding correctly

Please note that I am Not saying to define flooding for each FC, each FC has
already 'flooding scope' bit but simply put those opaque ID that requires
the same flooding in a given FC and set the flooding bit of that FC

> understand with a flooding scope that you do understand.  What's the use

I understand both opaque type and flooding scope, honestly there is not much
technical advantage of one over the other
in one case opaque ID of v2 could be used in order to accelerate Opaque ID
definition in v3 in other case I guess a correct mapping could do the same
thing at the end it is a personal preference ....

Sina