Re: Address Family Support in OSPFv3

Quaizar Vohra <qv@JUNIPER.NET> Wed, 09 July 2003 18:10 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 OAA12594 for <ospf-archive@LISTS.IETF.ORG>; Wed, 9 Jul 2003 14:10:42 -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 <15.00A5B733@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 14:10:41 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47935441 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 14:10:40 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 14:10:39 -0400
Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h69IAdu07058 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 9 Jul 2003 11:10:39 -0700 (PDT) (envelope-from qv@juniper.net)
Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h69IAdb95165; Wed, 9 Jul 2003 11:10:39 -0700 (PDT) (envelope-from qv)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
References: <000a01c34639$2d345370$f2ce7243@amer.cisco.com> <3F0C51B9.3080306@redback.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Message-ID: <200307091810.h69IAdb95165@fuinar.juniper.net>
Date: Wed, 09 Jul 2003 11:10:39 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Quaizar Vohra <qv@JUNIPER.NET>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <3F0C51B9.3080306@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Sina,

I very much agree with Acee here. Optimization at the cost of
implementation overhead is justified when the optimization
results in significant performance gains. The gain with
AF approach is less than O(2), in fact much less in almost
all cases.

Quaizar



 > 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