Re: Address Family Support in OSPFv3

Sina Mirtorabi <sina@CISCO.COM> Wed, 09 July 2003 19:42 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 PAA17589 for <ospf-archive@LISTS.IETF.ORG>; Wed, 9 Jul 2003 15:42:26 -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 <7.00A5BB3C@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 15:42:26 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47946510 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 15:42:05 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 15:42:05 -0400
Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h69Jg1T25902 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 9 Jul 2003 12:42:01 -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: <000501c34652$2b1c8da0$386545ab@amer.cisco.com>
Date: Wed, 09 Jul 2003 12:42:02 -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: <200307091810.h69IAdb95165@fuinar.juniper.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Quaizar

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

I do not agree to "much less than O(2)" performance gain and let me get
an example to clarify that

Let's consider the following

- a network participating in IPv6 unicast& multicast and IPv4 unicast &
multicast
- a worse case scenario where there is No overlap between any topologies
- we would consider 1450 byte as the limit for generating new fragments
for router LSA, prefix LSA
- a router have in average 20 adj in each AF (so 80 adj in total as we
considered no overlap)

You could see that even in worse case scenario our proposal compared to
the multiple instance has a

Gain O(4) for each Router LSA
Gain O(4) for each network LSA
Gain O(4) for each prefix LSA
Gain O(4) for each link lsa

You could see that we are far away from "much less than O(2)"

Sina