Re: Address Family Support in OSPFv3

[Quaizar Vohra <[e-mail]>]

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.


 > 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

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.

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

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.

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

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

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

 >
 > Thanks
 > Sina