Re: Address Family Support in OSPFv3

[Acee Lindem <[e-mail]>]

Hi Russ,

See inline.

Russ White wrote:
>>    - The multiple instance approach has the advantage of not requiring
>>      as much new invention (as Quaizar pointed out). The separation of
>>      link state databases and configuration is already there (since it
>>      each address family has a separate instance). However, it will still
>>      require new invention if other address families are to be carried (e.g.,
>>      IPv4).
>
>
> I think this is the strongest argument for address families--the seperate
> instance approach is going to require you to either:
>
> -- create a new version of ospf, and run a seperate instance, finding some
> way to only exchange that information relevant to the right ospf instance
> on each neighbor through some means, for wach type of information you'd
> like to carry

One thing you are missing is that OSPFv3 already has an instance
ID in all the packets that could be used for this. Also all widely
deployed OSPF implementations support multiple instances (I'm not
sure about OSPFv3 implementations but I'd expect the same).


>
> -- create new tlv's/ways of carrying information (address families) within
> the data structures so you can carry then information in a way that it can
> be sorted out correctly
>
> For instance, if you have two routers:
>
> A----B
>
> Suppose you want to carry ipv6, foo, and ipv4 between these routers. This
> would mean creating three different versions of ospf for these functions,
> out of which you can distinguish, in some way, what sort of information a
> specific peer is going to be passing, along with specific tlv's, etc. If,
> as in the case of multicast, the information is actually in the same
> format, you need to arbitrarily change the data format just to
> differentiate it.
>
> So, what you have is address families, anyway. You could argue that ospfv2
> and ospfv3 are actually address families as it is, just over different
> peering sessions.
>
> So, it seems to me the question comes down to: "address families over a
> single adjacency, or address families over independant adjacencies?" The
> answer to that question seems very clear--address families over a single
> adjacency is much easier to implement, much easier to configure and
> maintain, and much more flexible.

I'm not sure I'd jump to the same conclusions. Assuming your OSPFv3
implementation supports multiple instances you're adding another level
of hierachy to it. This adds an extra level of data structures, et al,
to your implementation. As for configuration and maintenance, I'd say
this is more influenced by how well the CLI, etc, is implemeneted than
the difference between these two approaches.

A big question here is "What percentage of OSPFv3 deployments will
eventually require multiple AFs?" The higher the percentage, the more
multiple AFs makes sense.

>
> You're not going to get away from "inventing" new packet formats for each
> type of data you want to carry, sometimes with arbitrary changes just to
> differentiate the data type. Why not make the arbitrary change an address
> family field, and be done with it?

For address families other than IPv6, you definitely need new LSAs with
either approach. Unless we go to OSPFv4, I don't think we can add an
address family/len field every place it is needed in the LSA formats (maybe we
could leave out virtual links this time :^)

>
> :-)
>
> Russ
>
>
> __________________________________
> [e-mail] CCIE <>< Grace Alone
>


--
Acee