Re: OSPFv3 Applications Support

[Acee Lindem <acee at REDBACK.COM>]

Kunihiro Ishiguro wrote:
> > At the 55th IETF WG meeting, there were two proposals for
> > supporting additional OSPF applications. There was quite
> > a lively discussion of the relative merits of each and
> > we decided that it would be best to discuss it further on
> > the OSPF WG list. Heretofore, there hasn't been any further
> > discussion so I figure it is time to get the ball rolling (or
> > in this case, the E-mails flying).
> >
> >  - OSPFv2 Opaque LSAs in OSPFv3
> >    http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt
> >
> >  - Traffic Engineering Extensions to OSPF version 3
> >    http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-01.txt
> >
> > The first defines the transformations necessary to map OSPFv2
> > opaque LSAs to OSPFv3. The second defines how to map the most
> > widely implemented and deployed OSPFv2 opaque to OSPFv3 using
> > new LSA types.
>
>
> Well, besides I wrote a draft for OSPFv3 TE, I support defining a new
> LS type for new application.  OSPFv3 already has clean design and very
> flexible architecture for new application.

[Speaking as WG member]

I have to agree with you here. I can't see the point of adding another
layer of multiplexing for these types in OSPFv3. In OSPFv2, the opaque
type was necessary since unknown types weren't handled. From an
applications standpoint, it is much more likely that one is going to
want to do something (whether it be process or view) all the LSAs
associated with a given type than all opaque LSAs.

The only additional cost that I see is that when an opaque type is
requested from IANA for OSPFv2, an OSPFv3 LSA type function code must
also be requested.

---
Acee