Re: Address Family Support in OSPFv3

Sina Mirtorabi <sina@CISCO.COM> Wed, 09 July 2003 16:43 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 MAA09235 for <ospf-archive@LISTS.IETF.ORG>; Wed, 9 Jul 2003 12:43:08 -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 <12.00A5B365@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 12:43:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47916379 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 12:43:09 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 12:43:09 -0400
Received: from smirtoraw2k03 (sjc-vpn2-442.cisco.com [10.21.113.186]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h69Gh8T25375 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 9 Jul 2003 09:43:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Message-ID: <000a01c34639$2d345370$f2ce7243@amer.cisco.com>
Date: Wed, 09 Jul 2003 09:43:07 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Sina Mirtorabi <sina@CISCO.COM>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <3F0C3B2C.5060608@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

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

thanks
Sina