Re: Address Family Support in OSPFv3

[Sina Mirtorabi <[e-mail]>]

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