- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: making ospfv3 multi AF aware [7:87244] posted 04/16/2004
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

At 4:26 PM +0000 4/16/04, p b wrote:
>Agreed.  I think the multi AF support in v3 will ultimately
>help folks move to IPv6. Instead of having to run two routing
>protocols, one can migrate to OSPFv3 for IPv4, get comfortable
>with v3, and the incrementally enable IPv6.
>I think getting to v3 will help eliminate some of the common
>issues we hear about ISIS and v2, namely that it's easier
>to extend ISIS and features tend to get added there first.
>If this help gets folks into v3, and since v3 is TLV based
>like ISIS, we'll see new features get put into v3 and ISIS
>at the same time (or maybe first in v3...)

As you probably know, but isn't often mentioned, OSPF and ISIS are 
generally similar but have significantly different assumptions in 
their detailed design. Knowing some of the assumptions, I believe, 
will help people understand the differences.

OSPF was optimized for high performance on the slow router processors 
of the day. You will note that most fields in LSAs are 16- or 32-bit 
aligned. OSPF tends to use bit flags for options, so there is a 
limitations to the number of options you can have in a 8, 16 or 32 
bit string.

ISIS accepted slower processing as a tradeoff against extensibility, 
and uses variable-length TLV's (Type-Length-Value) structures to 
contain options.  With TLVs, it's fairly unlikely you will run out of 
option space.

>Howard C. Berkowitz wrote:
>>  At 11:50 AM +0000 4/14/04, p b wrote:
>>  >Just an fyi, there's an ID that presents a way to enable
>>  >OSPFv3 to support multiple address families.  So, OSPFv3
>>  >could be used to support unicast IPv4, multicast IPv4/v6, etc.
>>  >
>>  >Interestingly, it also presents a way to make OSPFv3
>>  independent
>>  >of IPv6.  Thus, one could run OSPFv3 natively over IPv4.
>>  >
>>  >See: draft-ietf-ospf-af-alt-00.txt
>>  In my experience with the working group, the pendulum has swung
>>  back
>>  and forth several times as to how much support OSPFv3, and to
>>  some
>>  extent OSPFv2 extensions, should give to other protocol
>>  families.
>>  Part of the reason for introducing the Opaque LSA, for example,
>>  was a
>>  perceived desire to use OSPF mechanisms to distribute IPX
>>  information, or L2 information in support of NHRP.
>>  Assuming decent implementation, OSPFv3 gets away from certain
>>  restrictions in OSPFv2, such as using router IDs for
>>  initialization
>>  DR election, making it difficult to make a secondary address
>>  form
>>  adjacencies. There are a lot of little differences in the way
>>  OSPFv3
>>  does things, and many of them are meant to clean up things that
>>  were
>>  problematic in v2.
>>  It's certainly clear that the idea of address family support is
>>  permeating much new protocol development, and has been quite
>  > effective in BGP.

Message Posted at:
**Please support GroupStudy by purchasing from the GroupStudy Store:
FAQ, list archives, and subscription info: