OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: OSPFv3 Applications Support

From: Rohit Dube (rohitXEBEO.COM)
Date: Tue Mar 04 2003 - 17:29:11 CST


Folks,

This issue has been around for a while and it is time that
we picked one of the proposals as the WG document.

My read of the consensus is that
draft-ishiguro-ospf-ospfv3-traffic-01.txt
should be used as the basis for TE for OSPFv3.

Anybody care to comment further on the topic? Preferrably with
points that have not been discussed on the list before.

Regards,
--rohit.

On Thu, 9 Jan 2003 18:06:01 -0500 Acee Lindem writes:
=>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
___