Re: Address Family Support in OSPFv3

[Acee Lindem <[e-mail]>]

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