Re: Address Family Support in OSPFv3

Acee Lindem <acee@REDBACK.COM> Wed, 09 July 2003 17:32 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11319 for <ospf-archive@LISTS.IETF.ORG>; Wed, 9 Jul 2003 13:32:41 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A5B4C9@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 13:32:42 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47919609 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 13:32:41 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 13:32:41 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id C13C164C5C5 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 9 Jul 2003 10:32:39 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000a01c34639$2d345370$f2ce7243@amer.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3F0C51B9.3080306@redback.com>
Date: Wed, 09 Jul 2003 13:32:41 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sina,

Sina Mirtorabi wrote:
> Acee
>
> ->A big question here is "What percentage of OSPFv3 deployments
> ->will eventually require multiple AFs?" The higher the
> ->percentage, the more multiple AFs makes sense.
>
> Although one could argue for the need of carrying IPv4 in OSPFv3 (which
> eventually I believe customers will ask for it)  but multicast IPv6 AF
> is a good example of the need for multiple AF
>
> We are comparing two solutions for _multiple_ address-family ( multiple
> means any additional AF to unicast IPv6) in OSPFv3 and we know which one
> is more efficient, now if we do not want to use address-family at all
> (and keep only unicast IPv6) then there is nothing to compare
>
> The fact of not using AF cannot be counted an advantage for multiple
> instance-id as the solution to AF in OSPFv3

Sina,

I disagree with you here. Adding a new layer for AF to OSPFv3 requires
more base protocol changes as well as the attendant implementation
costs and overhead. Any unbiased evaluation has to take this into
consideration.

Thanks,
Acee

>
> thanks
> Sina
>


--
Acee