Subject: Re: Address Family Support in OSPFv3

From: Vivek Dubey <[email-masked]>
Date: Sat, 14 Jun 2003 08:51:56 -0000

Sounds interesting, as IGP would then not depend
on "address family combinations" supported at IP
level.
How will multiple OSPFv3 instance will provide that
support?

On Wed, 11 Jun 2003 Acee Lindem wrote :
>At the last IETF, the draft draft-mirtorabi-ospfv3-AF-00.txt was
>presented. It proposes to make some protocol changes to OSPFv3 now
>in case we ever want to support multiple address families (e.g.,
>permutations of IPv4, IPv6, unicast, and multicast).
>
>The draft raised a moderate level of technical discussion (mainly
>centered on the proposal's backward compatibility mechanism). The
>big question is whether or not there is a real requirement for this?
>We all know this is done in ISIS but that doesn't necessarily mean
>there is a requirement. And if there is, could the requirement better
>be satisfied with multiple OSPFv3 instances. On the other hand, we
>really want to get the protocol changes in as early as possible if
>we ever want to support multiple address families.
>
>Comments? I have some additional considerations that I will put
>in a separate E-mail.
>
>--
>Acee

---

From: Acee Lindem <[email-masked]>
Date: Sat, 14 Jun 2003 06:32:41 -0400

> How will multiple OSPFv3 instance will provide that

Alternately, you could also use separate OSPFv3 instances
for each address family. OSPFv3 natively supports multiple
instances of OSPFv3 on a link without using secondary
addresses or multiplexing via a layer 2 encapsulation (e.g.,
802.1q).

For incongruent IPv6 topologies, you'd simply configure
additional OSPFv3 instances using the interfaces you wish
to use for that topology. The OSPFv3 instance would populate
the RIB corresponding to the respective topology. As example
application would be carrying multicast traffic on a separate
topology from unicast traffic.

For other address families (most notably IPv4), we'd still
need new LSAs to carry the non-IPv6 prefixes (independent of
whether you use multiple instances or support multiple address
families in a single instance).

The advantage of supporting multiple address families in
single instance is that you only have a single set of OSPFv3
adjacencies. The disadvantage is complexity we're exerting
on the base protocol. To it right, you really need separate
interface costs, prefix ranges, redistribution policy,
default origination, etc, for each address family. You
already have all this with separate instances.

At the last IETF, there was discussion as to whether or
not there is a strong enough requirement for this to warrent
consideration by the OSPF WG. Much of this discussion focused
on whether or not a provider would ever phase out OSPFv2 in
favor of using OSPFv3 to advertise IPv4 prefixes.

My feeling is that perhaps we should consider the modest
changes to the OSPFv3 protocol now in case we ever want
to support multiple address families.

This E-mail contains the additional considerations I eluded
to in my previous post.

Thanks,
Acee

>> ------------------------------------------------------------------------
>>
>> <http://www.herohonda.com/karizma>
>

--
Acee

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 16 Jun 2003 10:59:19 -0700

Acee, all

Let me summarize what are the disadvantages of using Instance-ID to run
multiple AF

running multiple instance will

a) require to maintain more adjacencies, in fact to add N AF you may
have to add N adjacencies. This will increase sending and processing of
Hello packet by N for each node

b) require to maintain more LSDB, in fact type 1 & 2 LSA ( which are Not
AF specific) are used again in each instance for each overlapping AF
topology

c) increase the flooding and processing of OSPF packets, this result
from an increase in adjacency and regeneration of type 1&2 LSA within
each instance

D) need a mapping of instance-ID to AF which is user dependent and can
be prone to misconfiguration and increase troubleshooting.

Further other routing protocols ( ISIS, BGP, EIGRP) have adopted AF,
although OSPFv2 -> OSPFv3 transition went with SIN ( ship in the night)
because of inability of v2 to add AF, OSPFv3 separated topology
information and AF specific information and move toward AF integration.
I am not sure we want to fall back to SIN by using instance_ID

Thanks
Sina

---

From: Quaizar Vohra <[email-masked]>
Date: Fri, 20 Jun 2003 10:40:07 -0700

Sina,

I like the idea of using instance-ids for multiple address
families rather than adding AF specific changes to the existing LSAs.

Please see my answers inline to all the disadvantages you have
listed to using instance-ids for AFs.

 > Hello packet by N for each node

I don't think creation and maintanence of extra adjs itself is a
problem, specially if N is 2 or 3. Also there is ongoing development
of IGP independent fast liveness protocols on links (needs only one
hello per link irrespective of whatever other protocols, e.g.  OSPF,
are being run on the link). Given that generally the world is heading
in that direction, it would be okay to run IGP hellos with larger
intervals and so hello maintanence is not a real problem. Even without
that it is not a problem.

 > from an increase in adjacency and regeneration of type 1&2 LSA within

Flooding and packet processing will be affected by a factor of 2
atmost, as typically the database is dominated by LSAs carrying prefix
information. So the only thing you are saving on is advertising the
same prefix LSAs for unicast and multicast (for IPv4 and IPv6 you will
have to anyway originate different prefix LSAs. If you start carrying
different metric values for different AFs then the savings in the
router LSA is also gone (due to logical fragmentation if your router
LSAs are big and if not then you network is small and this should not
be a problem).

And if you want to advertise different unicast and multicast
topologies, in all likehood the topologies are really different with
some overlap. In that case, the saving is smaller than a factor of 2.
Specially once you get down to summarizing your prefixes, the metric
for each topology will be different and then you will anyway advertise
2 LSAs.

Also if you want to be selective about which prefixes you advertise in
unicast and multicast, or if you want to advertise external LSAs with
different costs in unicast and multicast topologies, the benefits are
even less.

A very similar argument can be made against the savings in the size of
the LSDB.

 > be prone to misconfiguration and increase troubleshooting.

Mapping AF to Instance shouldn't be that difficult. We could reserve
certain instance ids for the well known AFs.

 > I am not sure we want to fall back to SIN by using instance_ID

On th other hand, changes like LG election and AF-Functionality LSA or
AF-inter-area-router LSA add significant complexity to code.

As far as changes in ISIS are concerned, the changes there are
more equivalent to using instance-ids then the changes in your
draft. In fact all they do is replicate TLVs, once for each
topology. So they end up advertising proportionately more
LSPs, CSNPS etc. The only saving is in the adjacency formation.

If you still think savings on the adj. is important, than
we could run adjs only within a single instance, shared by
all other AF instances.

The changes you are proposing in the draft are changes to the protocol
itself and are not a gereric or a single high level change which fixes
everything in a clean and complete way. The fear is in the unknown,
i.e. further bandages which will be needed.

Quaizar

---

From: Sina Mirtorabi <[email-masked]>
Date: Sun, 22 Jun 2003 10:55:10 -0700

Quaizar,

->I don't think creation and maintanence of extra adjs itself
->is a problem, specially if N is 2 or 3. Also there is ongoing
->development of IGP independent fast liveness protocols on
->links (needs only one hello per link irrespective of whatever
->other protocols, e.g.  OSPF, are being run on the link).
->Given that generally the world is heading in that direction,
->it would be okay to run IGP hellos with larger intervals and
->so hello maintanence is not a real problem. Even without that
->it is not a problem.

Independently of a fast liveliness protocols, you would have to send and
process Hellos.
Depending on the number of adj and topology, your N = 2/3 multiplied by
the number of adjacency could be significant. For example say you have a
Hub and Spoke with Hub router having 300 adj, if all Spoke participate
in say two other AF you would end up adding 600 more adj which is
unnecessary and significant

->Flooding and packet processing will be affected by a factor
->of 2 atmost, as typically the database is dominated by LSAs
->carrying prefix information.

Again it all depends on your topology and environment,  in case of AF
proposal not only type 1/2 but also intra-area-prefix will be optimized
since you carry more than one prefix within the intra-area-prefix-LSA (
see below )

If you are in an environment that you are doing summarization then the
dominant LSA can be type 1/2 & intra-area-prefix-lsa therefore you could
gain more than a factor 2. In any case even a factor 2 multiplied by X
number of LSA could be significant

->So the only thing you are saving
->on is advertising the same prefix LSAs for unicast and
->multicast (for IPv4 and IPv6 you will have to anyway
->originate different prefix LSAs. If you start carrying
->different metric values for different AFs then the savings in
->the router LSA is also gone (due to logical fragmentation if
->your router LSAs are big and if not then you network is small
->and this should not be a problem).

In v3 each prefix is defined by  { Prefix, Prefix length, Prefix Options
}, therefore you can add bits in Prefix Options to say to which AF a
prefix belongs and since you want to be backward compatible you can use
the NU bit to exclude the prefix from IPv6 unicast AF ( A short draft
will be available soon to demonstrate that for multicast AF)

This mean that the prefix LSA encoding is flexible enough to carry
prefixes of different lengths (IPv6, IPv4 or whatever), as long as we
can distinguish the correct AF, by say looking at some Prefix Options
bits

-> > D) need a mapping of instance-ID to AF which is user
->dependent and can  > be prone to misconfiguration and
->increase troubleshooting.
->
->Mapping AF to Instance shouldn't be that difficult. We could
->reserve certain instance ids for the well known AFs.

It is not sufficient to reserve some values, what happen if some of your
routers does not understand the given reserved values and you compute
the path through them ?

->On th other hand, changes like LG election and
->AF-Functionality LSA or AF-inter-area-router LSA add
->significant complexity to code.

Significant? I do not believe adding two new LSA add significant
complexity. Further those LSA will be used by _all_ AF and are _generic_

->
->As far as changes in ISIS are concerned, the changes there
->are more equivalent to using instance-ids then the changes in
->your draft.
->In fact all they do is replicate TLVs, once for
->each topology. So they end up advertising proportionately
->more LSPs, CSNPS etc.

Not really, the _same_ LSP is advertised _once_ to sets of neighbors and
a neighbor use whatever TLV it needs. There is no extra adjacency and
extra-flooding because of different AF neighbor

In fact in case of our proposal the LSA flooding is even more optimized
( than ISIS) because type 1/2 are common to all AF further for prefix
information we can use the _same_  prefix LSA and add prefix specific AF
to the existing LSA so it is similar to adding TLV specific AF inside
LSP as in ISIS

->The only saving is in the adjacency formation.

You save also in maintaining LSDB multiple times, further saving in
adjacency leads to saving of flooding LSDB multiple times ( once for
each AF ) and decrease in packet processing

->The changes you are proposing in the draft are changes to the
->protocol itself and are not a generic or a single high level
->change which fixes everything in a clean and complete way.
->The fear is in the unknown, i.e. further bandages which will
->be needed.

The way OSPFv3 was defined, it allows to separate topology information
from prefix information, further prefix LSA information are defined in a
flexible way which could be used for other AF

Therefore the proposed draft leverage and optimize the current OSPFv3
allowing to integrate different AF within OSPFv3, the addition is 2 new
LSAs which are generic to all AF and not a big deal.

I would like to ask WG to debate if they want to go with an integrated
approach or SIN, as OSPFv3 is in the initial deployment phase and a
decision need to be made.

Sina

---

From: Quaizar Vohra <[email-masked]>
Date: Mon, 23 Jun 2003 16:09:34 -0700

Sina,

Please see my comments inline.

 > unnecessary and significant

300 adjs or 600 adjs with hello interval of 10 seconds, have hardly
had any impact on the CPU on one of the implementations I know about.

 > number of LSA could be significant

If my dominant LSAs are just type 1/2 and intra-area-prefix, I
wouldn't be very much concerned with a gain of 2, as even in a very
large network, the number of these LSAs won't be very large.
And much of this gain wouldn't even be realized due to
differences in topology.

 > can distinguish the correct AF, by say looking at some Prefix Options

I am sure many of us already understand that. If you you suggesting
that you will carry v4 and v6 prefixes in the same intra-area-prefix
LSA, it is certainly doable with some amount of effort. But I still
don't see any significant benefit out of it. As far as carrying
unicast & multicast prefixes togather, I already counted that in in my
last mail.

 > routers does not understand the given reserved values and you compute

Since even the hello packet will contain the instance-id, the adj
shouldn't come up with a nbr who doesn't understand that instance-id
value. This is nothing but SIN, everything is separate.

 > complexity. Further those LSA will be used by _all_ AF and are
_generic_

It is not a question of just adding 2 more LSAs, it is a question of
what is involved in generating them and processing them. What other
parts of the code you are going to touch. What about LG election ?
And what other bandages are yet to come ?

 > extra-flooding because of different AF neighbor

I already accepted in my last mail that there is no extra adjacecny.
But there definitely is extra flooding. The more TLVs you add, the
more LSP fragments you have and hence you have more to transmit.  If
for a node, there was only one LSP to advertise and it was
significantly small that adding more TLVs for other AFs didn't
require generating another one, then that is quite a degenerate case
and my topology is significanlty small and I should be hardly
worried with a gain of O(2).

 > to the existing LSA so it is similar to adding TLV specific AF inside

Yes, you are more optimal than ISIS (or supposedlty) but this
optimality is achived in a significantly different way, i.e.
by adding new functionality into the protocol. While ISIS chose
to be simple and just replicate the TLVs, once for each AF.

My point is the ISIS way and multiple instance ids are far more
equivalent than your proposal. The only commonality between your
proposal and ISIS is saving on formation of adjacencies.

 > each AF ) and decrease in packet processing

Not in ISIS. Yes, with your proposal but not siginificantly.

Quaizar

---

From: Sina Mirtorabi <[email-masked]>
Date: Mon, 23 Jun 2003 20:43:10 -0700

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