Re: making ospfv3 multi AF aware [7:87244] posted 04/16/2004
- Subject: Re: making ospfv3 multi AF aware [7:87244]
- From: "Howard C. Berkowitz" <hcb@xxxxxxxxxxxx>
- Date: Fri, 16 Apr 2004 17:25:39 GMT
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
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
>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
>> >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
>> and forth several times as to how much support OSPFv3, and to
>> extent OSPFv2 extensions, should give to other protocol
>> 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
>> DR election, making it difficult to make a secondary address
>> adjacencies. There are a lot of little differences in the way
>> does things, and many of them are meant to clean up things that
>> 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: http://www.groupstudy.com/list/cisco.html