Re: Address Family Support in OSPFv3

[Sina Mirtorabi <[e-mail]>]

Quaizar

->
->Sina,
->
->The example you take picks a small number of adjs.

Humm, 80 adj per router is small :)

->If you go
->to a larger number of adjs, you will run into logical
->fragmentation. And once the total adjs grow over 4 logical
->fragments, the AF approach and SIN approach will result in
->the same number of LSA fragments.

Do not forget that 20 adj per AF was the worse case scenario which is no
link overlap between any AF, if you have some overlap you could grow
your number of adj for each AF ( up to a ideal case of 90 ) and still
can fit into a single fragment

->
->I concede the fact that you could have a large network
->where each router has only a small number of adjs. Then
->the gain you mention works.

Good ;-) I will still argue for the word small adj in a normal case
which will have overlap

->But I doubt that anyone
->will run IPv4 unicast using OSPFv3 for a very long time.

Well there is no fact to justify that

->As far as total memory is concerned, both approaches would
->turn out to be quite equivalent in any topology if the
->metric values are different across all AFs. Sharing router
->LSA links for multiple AFs will be painful from the
->implementation point of view.

But the metric value is not necessarily different, you could have simply
incongruent topology.
for example if your ocX link cost is C why would you want to change it ?


So I do not agree that the amount of memory are the same further do not
forget that you have also additional memory to keep for each area data
structure, adj etc in case of multiple instance

->
->Also with prefix LSAs you can't share the prefixes between v4
->and v6 simply because they are different.

Why not ? The prefix carry a prefix length so you can code IPv4 in the
existing LSAs

->
->So the gain is O(3) even in the best case. Big deal :).

Good so we went from "much less than O(2)" to O(3) ;-)

->This
->is true whether you talk about the amount of memory or amount
->of LSAs. I feel that most implementations of the AF approach
->will end up choosing not to implement overlapping router LSA
->links for multiple AFs, simply because of the implementation
->complexity.

Well let's the implementations choose but I do not see why you are
making the proposal to look so complex
If there are some part that you consider complex we are open to
suggestions to optimize

->So you will end up with any gain only in terms of
->the number of LSAs (not in total memory).

In terms if number of LSA , memory, flooding and adjacency

-> Even the later
->doesn't work if routers have large number of adjacencies.

50-80 adj is pretty a good number for the average number of adj, in fact
in most of the case ( except hub and spoke) you won't even have that
many

->
->Not worth all the implementation pain :).

If we talk about other AF than IPv6 then you would have some of the same
pain in multiple instance id

further if you have ospfv2 today and you want to add V3 you know that it
will require more resources, the same apply here for adding 2/3 other AF
to OSPFv3.

Let's focus on the customer and optimize their cost rather than the
extra implementations cost ( although still I do not believe there is a
big difference between multiple AF and multiple instance complexity if
we count the whole sets of AF and not only multicast IPv6 AF addition)

Thanks
Sina