Subject: Re: OSPFv3 Applications Support

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 19 Mar 2003 14:33:07 -0500

-> . . . One of the main motivations for
-> the OSPFv2 opaque LSA was to solve the problem of how to get
-> LSAs flooded
-> w/o every router in the OSPF routing domain understanding all the
-> opaque LSAs types. In OSPFv3, flooding of unknown LSA types
-> is handled explicitly - this obviates the requirement for
-> opaque LSAs.

  I think I heard these misconception about opaque LSAs quite
  few times now. Let me explain about the history of Opaque LSAs.
  When Rob was here in this group, the main motivation was
  to extend OSPF for the continuing extensions. Which he felt
  must be done in a simple, elegant way (around May 1997 the first
  draft was out). Along with Juha, Rob wrote first use of opaque
  LSAs to resolve ATM addresses (which never standardized).

  The initial Opaque LSAs draft reads:
  ...
    As a result of this deployment and the evolution of networking
    technology, OSPF has been extended to support many options;
    this evolution will obviously continue.

    This memo documents enhancements to the OSPF protocol to support a new
    type of link-state advertisement (LSA) called the Opaque LSA which
    defines an optional generalized mechanism to allow for future extensi-
    bility of OSPF. The information contained in Opaque LSAs may be used
    directly by OSPF or by other protocols.
                        ^^^^^^^^^^^^^^^^^^
    For example, the OSPF LSA may be used to distribute BGP AS Path
    information (as documented in The OSPF External Attributes LSA
    which is then used by BGP route-leaking mechanisms. The option may
    also be used to distribute IP QoS information which may be used
    directly by an OSPF path computation. The exact use of the Opaque
    LSA is beyond the scope of this draft.
  ...

  The main motivation is not about OSPFv2 "flooding problems" because
  other routers are not able to decode those LSAs. The main motivation
  is "How best other protocols/applications can make use of OSPF
  reliable flooding mechanisms instead of extending LSAs for each and
  every applications requirements?". More over in v2, all the
  LSAs are tightly encoded and difficult to piggyback the information.
  OSPFv2 required some way of TLV encoded LSAs.

  Draw a "clear-cut line" between the *LSA types* which are being
  used by OSPF for internal use (Hop-by-Hop Routing, flooding etc)
  _and_ the LSAs which are not used by OSPF protocol at all. That
  clear-cut line is named as "Opaque LSAs".

  I heard quite few times that other applications are re-using
  parser code in OSPF etc etc...NO...the applications are using
  the OSPF reliable flooding mechanism (which is somewhere in
  between connection less IP/UDP/DCCP and connection oriented
  TCP/SCTP)

Venkata.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 21 Mar 2003 12:51:48 -0500

Venkata,

I don't disagree with your recollection of the evolution of
OSPFv2 opaque LSAs. It is my opinion (and that a large number
of people I've spoken to) that opaque LSAs are unnecessary in
OSPFv3 due to the inherent handling of unknown LSA types. I
believe that identifying the application by the LSA type
will actually make it more straight forward to export/import
application data to/from another protocol.