Subject: Re: Address Family Support in OSPFv3

From: Acee Lindem <[email-masked]>
Date: Tue, 8 Jul 2003 14:45:29 -0400

Sina, Quaizar,

I've thought about this and I don't think one can say one approach
is better than the other in all cases. Here are my thoughts:

    - The multiple address family approach will be more efficient
      when multiple address families are required and the topologies
      overlap (i.e., the same set of links will be used for multiple
      topologies).

    - The multiple instance approach will be more efficient for
      topologies where multiple addresses families are not
      required (let's not forget that an extra address family layer is
      also going cost memory and CPU).

    - As for which is better operationally, I think this is more a
      matter of implemenation than approach. I disagree that the multiple
      address family approach is obviously better. In fact, in some ways
      having a separate link state database per address family may be
      easier to debug. With either approach, one can misconfigure
      something and I don't see that as major issue. It would be great
      to get a carrier's perspective here.

    - The multiple address family approach has precedence in BGP and
      M-ISIS where people configure things by address family. It appears
      to me that to do it right in OSPFv3 lots of things (link costs, ranges,
      redistribution, default origination, et al) have to be configured
      at the address family level rather than the interface, area, or
      instance level.

    - 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).

Thanks,
Acee

Sina Mirtorabi wrote:
> Quaizar,
>
> I will avoid going through an endless discussion regarding SIN and
> integrated approach optimization
>
> Four comments though
>
> 1)
> An integrated approach optimize the CPU usage, memory and network
> bandwidth utilization which apparently is not your concerns.
>
> 2)
> It is interesting how you make a believe that Integrated IS-IS is close
> to SIN instance ID rather than our proposal. If ISIS had to implement
> different instance (or using different process) for different AF then
> how would you compare it to SIN?
>
> The fact that you are having more information to transport which is a
> _result_ of adding AF is irrelevant to the rapprochement that you are
> making between ISIS and SIN instance ID of OSPFv3.
>
> 3)
> Any optimization can lead to some degree of code complexity,  M-ISIS is
> a good example of it.
>
> Defining and processing two new LSA does not look complex to me, as far
> LG election, it is pretty close to DR election algorithm but if that
> bothers you that much there are other ways to fix it ( forcing the
> router that is AF capable to become DR either manually or the router can
> declare itself DR and win DR election )
>
> 4)
> It is not sufficient to have separate instance ID, if a router does not
> understand the reserved value for a AF but has the _same_ instance-ID (
> router downgraded etc ) then how you make sure that the path is not
> through this router ?
>
>
> Sina
>

--
Acee

---

From: Russ White <[email-masked]>
Date: Wed, 9 Jul 2003 10:29:26 -0400

>       require new invention if other address families are to be carried (e.g.,

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

-- 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.

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?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Acee Lindem <[email-masked]>
Date: Wed, 9 Jul 2003 11:56:28 -0400

Hi Russ,

See inline.

> on each neighbor through some means, for wach type of information you'd

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).

> 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.

> 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 :^)

--
Acee

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 9 Jul 2003 09:43:07 -0700

Acee

->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.

Although one could argue for the need of carrying IPv4 in OSPFv3 (which
eventually I believe customers will ask for it)  but multicast IPv6 AF
is a good example of the need for multiple AF

We are comparing two solutions for _multiple_ address-family ( multiple
means any additional AF to unicast IPv6) in OSPFv3 and we know which one
is more efficient, now if we do not want to use address-family at all
(and keep only unicast IPv6) then there is nothing to compare

The fact of not using AF cannot be counted an advantage for multiple
instance-id as the solution to AF in OSPFv3

thanks
Sina

---

From: Acee Lindem <[email-masked]>
Date: Wed, 9 Jul 2003 13:32:41 -0400

Sina,

> instance-id as the solution to AF in OSPFv3

Sina,

I disagree with you here. Adding a new layer for AF to OSPFv3 requires
more base protocol changes as well as the attendant implementation
costs and overhead. Any unbiased evaluation has to take this into
consideration.

Thanks,
Acee

--
Acee

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 9 Jul 2003 11:10:39 -0700

Sina,

I very much agree with Acee here. Optimization at the cost of
implementation overhead is justified when the optimization
results in significant performance gains. The gain with
AF approach is less than O(2), in fact much less in almost
all cases.

Quaizar

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 9 Jul 2003 12:28:35 -0700

Acee,

->> The fact of not using AF cannot be counted an advantage for
->multiple
->> instance-id as the solution to AF in OSPFv3

->Sina,
->
->I disagree with you here. Adding a new layer for AF to OSPFv3
->requires more base protocol changes as well as the attendant
->implementation costs and overhead. Any unbiased evaluation
->has to take this into consideration.

If you do not need to have other AF, you can only have the minimum
required in our proposal that is setting the AF bit in the Hello and
v6-AF bit in the AdressFamilies field  (Disabled mode)

Once you want to have additional AF then you have to bother about the
additional two new LSA and potentially other new LSAs in other AF (if
needed) which even in case of multiple instance you would need to define
ways to be backward compatibles, define new LSA for new AF etc

Sina

->
->Thanks,
->Acee
->
->>
->> thanks
->> Sina
->>
->
->
->--
->Acee
->

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 9 Jul 2003 12:42:02 -0700

Quaizar

->
->Sina,
->
->I very much agree with Acee here. Optimization at the cost of
->implementation overhead is justified when the optimization
->results in significant performance gains. The gain with AF
->approach is less than O(2), in fact much less in almost all cases.

I do not agree to "much less than O(2)" performance gain and let me get
an example to clarify that

Let's consider the following

- a network participating in IPv6 unicast& multicast and IPv4 unicast &
multicast
- a worse case scenario where there is No overlap between any topologies
- we would consider 1450 byte as the limit for generating new fragments
for router LSA, prefix LSA
- a router have in average 20 adj in each AF (so 80 adj in total as we
considered no overlap)

You could see that even in worse case scenario our proposal compared to
the multiple instance has a

Gain O(4) for each Router LSA
Gain O(4) for each network LSA
Gain O(4) for each prefix LSA
Gain O(4) for each link lsa

You could see that we are far away from "much less than O(2)"

Sina

---

From: Acee Lindem <[email-masked]>
Date: Wed, 9 Jul 2003 16:05:01 -0400

> ways to be backward compatibles, define new LSA for new AF etc

Sina,
Let me try and be more clear - What I'm saying is that with multiple
instances you already have the separation between the topologies without
any protocol changes or an additional AF layer in your implementation.

For example, to support the OSPFv3 IPv6 multicast topology with the
multi-AF approach one must implement the two drafts you've posted plus
deal with all the issues related to the AF layer in configuration and
management (i.e., show commands, etc). To do it with multiple instances,
all you have to do is configure the address family and default OSPFv3
interface ID at the instance level. I haven't thought about this at
great depth but on the surface I can't see why it wouldn't work.
There will be no protocol changes and I'll submit to you that the
implementation cost is less.

At this point, I'm not saying that one approach is obviously better or
trying to precisely quantify the relative efficiencies when multiple AFs
are used. All I'm saying is that you can't completely discount the
associated costs.

Thanks,
Acee

--
Acee

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 9 Jul 2003 15:48:45 -0700

Sina,

The example you take picks a small number of adjs. 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.

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. But I doubt that anyone
will run IPv4 unicast using OSPFv3 for a very long time.

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.

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

So the gain is O(3) even in the best case. Big deal :). 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. So you will end up
with any gain only in terms of the number of LSAs (not in total
memory). Even the later doesn't work if routers have large number
of adjacencies.

Not worth all the implementation pain :).

Quaizar

---

From: Russ White <[email-masked]>
Date: Wed, 9 Jul 2003 19:55:50 -0400

> interface ID at the instance level. I haven't thought about this at great
> depth but on the surface I can't see why it wouldn't work. There will be
> no protocol changes and I'll submit to you that the implementation cost
> is less.
>

But, if you are carrying something which doesn't necessarily fit into the
ipv6 address format, then you need the new instance, and the new tlv's
anyway, correct? So, you've now gained the additional complexity on all
sides, and gained nothing, it seems to me.

:-)

Russ

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 9 Jul 2003 17:37:44 -0700

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 9 Jul 2003 23:36:57 -0400

Russ White wrote:
> anyway, correct?

New LSA types will be required to advertise addresses for new address
families independent of the approach.

> So, you've now gained the additional complexity on all

I'm not sure how get to this conclusion - the processing of the new LSA
types is an incremental cost on top of either approach.

--
Acee

---

From: Quaizar Vohra <[email-masked]>
Date: Thu, 10 Jul 2003 11:36:25 -0700

> structure, adj etc in case of multiple instance

But then one would go to the extent of running OSPF for multiple AFs
only if there is some significant distinction in the topology for
each AF, so then you loose some of the gain.

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

Yes, I understand that. My point was that you can't share the prefixes
as you could share router LSA links. Yes you can put them in the same
LSA but your LSA would grow larger.

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

Note the use of "BEST CASE" above.

 > pain in multiple instance id

No, there is very little change required in implementation as all
you would have to do is set a different set of bits in the prefix
options, and the right instance-id in the packet header.

 > we count the whole sets of AF and not only multicast IPv6 AF

Let the customer decide on the tradeoff between implementation and
maintanence complexity versus efficiency.

Thanks,
Quaizar

---

From: Quaizar Vohra <[email-masked]>
Date: Thu, 10 Jul 2003 11:41:09 -0700

> families independent of the approach.

I don't think we would even require new LSA types. The prefix encoding
as it stands currently is fairly flexible. I doubt that you would even
require extra bits in the prefix options. The clearing of NU bit
and the indication of the AF from the instance-id is sufficient to
tell you which AF the prefix belongs to.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 10 Jul 2003 14:55:22 -0400

> tell you which AF the prefix belongs to.

I haven't thought about it in great depth. I guess if you
use solely address family foo prefixes for a address family foo
instance it might be possible.

--
Acee

---

From: Sina Mirtorabi <[email-masked]>
Date: Thu, 10 Jul 2003 14:31:33 -0700

Quaizir,

->Let the customer decide on the tradeoff between
->implementation and maintenance complexity versus efficiency.

I guess we agree on the fact that

- an integrated approach has the advantage of efficiency and optimize
number of LSA, memory, flooding, adjacency

- instance id approach has the advantage of implementation simplicity

I will get the discussion further off line with you guys, I would like
however to hear from customers and operator for their preference

Thanks
Sina

---

From: Sina Mirtorabi <[email-masked]>
Date: Thu, 10 Jul 2003 16:39:51 -0700

Acee,

->I haven't thought about it in great depth. I guess if you
->use solely address family foo prefixes for a address family
->foo instance it might be possible.

Yes as I said previously, since a prefix carry prefix length no new LSA
is required to define prefix information for other AF and this is true
for either approach

Sina