Re: Address Family Support in OSPFv3

[Sina Mirtorabi <[e-mail]>]

Hi Acee

Thanks for the input, please see in line

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

Yes, the more overlap you have the more would be the gain however in any
case even if all topology has no links in common the multiple address
family can not be worse than multiple instance id since your LSA header
is still common between AF in multiple address family and without even
talking about adjacency gain


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

If you use any other AF than IPv6 then multiple instance can not be more
efficient even in an extreme case where all topology are completely
different

If you use only IPv6 AF then there may be some memory / cpu as you
indicated for AF layer however we are comparing multiple AF with
multiple instance ID as the solution to _multiple_ AF therefore this
cannot be counted as an advantage if any


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

ok let's don't count this as advantage/disadvantage

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

Yes, for multiple address family approach, every thing you mentioned
will be part of AF and one need simply to indicates which link
participate in which AF

for instance ID, we are going away from BGP and ISIS concept of
address-family and the common configuration, rather we are associating
the instance ID with a given AF which will be a new concept for the
operator


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

Well the extra new invention is actually two new LSAs which are common
to all AF. As for introducing other LSAs ( for both multiple AF and
multiple instance) this can be avoided as much as possible

We published a draft ( which I guess was not announce on the alias ) for
multicast AF without introducing any new LSAs

http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-multicast-af-
00.txt

The same concepts can be used for IPv4 as the length of the prefix are
identified in prefix length

Thanks
Sina


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