Re: Address Family Support in OSPFv3

Quaizar Vohra <qv@JUNIPER.NET> Thu, 10 July 2003 18:36 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 OAA15880 for <ospf-archive@LISTS.IETF.ORG>; Thu, 10 Jul 2003 14:36:28 -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 <16.00A5F548@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 14:36:28 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48071531 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 14:36:27 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 14:36:27 -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 h6AIaQu98457 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 10 Jul 2003 11:36:26 -0700 (PDT) (envelope-from qv@juniper.net)
Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h6AIaP398030; Thu, 10 Jul 2003 11:36:25 -0700 (PDT) (envelope-from qv)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
References: <200307092248.h69Mmjp95707@fuinar.juniper.net> <000301c3467b$7b4ad790$f2ce7243@amer.cisco.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Message-ID: <200307101836.h6AIaP398030@fuinar.juniper.net>
Date: Thu, 10 Jul 2003 11:36:25 -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: <000301c3467b$7b4ad790$f2ce7243@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Sina Mirtorabi writes:
 >
 > ->As far as total memory is concerned, both approaches would
 > ->turn out to be quite equivalent in any topology if the
 > ->metric values are different across all AFs. Sharing router
 > ->LSA links for multiple AFs will be painful from the
 > ->implementation point of view.
 >
 > But the metric value is not necessarily different, you could have simply
 > incongruent topology.
 > for example if your ocX link cost is C why would you want to change it ?
 >
 >
 > So I do not agree that the amount of memory are the same further do not
 > forget that you have also additional memory to keep for each area data
 > structure, adj etc in case of multiple instance

But then one would go to the extent of running OSPF for multiple AFs
only if there is some significant distinction in the topology for
each AF, so then you loose some of the gain.

 >
 > ->
 > ->Also with prefix LSAs you can't share the prefixes between v4
 > ->and v6 simply because they are different.
 >
 > Why not ? The prefix carry a prefix length so you can code IPv4 in the
 > existing LSAs

Yes, I understand that. My point was that you can't share the prefixes
as you could share router LSA links. Yes you can put them in the same
LSA but your LSA would grow larger.

 >
 > ->
 > ->So the gain is O(3) even in the best case. Big deal :).
 >
 > Good so we went from "much less than O(2)" to O(3) ;-)

Note the use of "BEST CASE" above.

 >
 > ->This
 > ->is true whether you talk about the amount of memory or amount
 > ->of LSAs. I feel that most implementations of the AF approach
 > ->will end up choosing not to implement overlapping router LSA
 > ->links for multiple AFs, simply because of the implementation
 > ->complexity.
 >
 > Well let's the implementations choose but I do not see why you are
 > making the proposal to look so complex
 > If there are some part that you consider complex we are open to
 > suggestions to optimize
 >
 > ->So you will end up with any gain only in terms of
 > ->the number of LSAs (not in total memory).
 >
 > In terms if number of LSA , memory, flooding and adjacency
 >
 > -> Even the later
 > ->doesn't work if routers have large number of adjacencies.
 >
 > 50-80 adj is pretty a good number for the average number of adj, in fact
 > in most of the case ( except hub and spoke) you won't even have that
 > many
 >
 > ->
 > ->Not worth all the implementation pain :).
 >
 > If we talk about other AF than IPv6 then you would have some of the same
 > pain in multiple instance id

No, there is very little change required in implementation as all
you would have to do is set a different set of bits in the prefix
options, and the right instance-id in the packet header.

 >
 > further if you have ospfv2 today and you want to add V3 you know that it
 > will require more resources, the same apply here for adding 2/3 other AF
 > to OSPFv3.
 >
 > Let's focus on the customer and optimize their cost rather than the
 > extra implementations cost ( although still I do not believe there is a
 > big difference between multiple AF and multiple instance complexity if
 > we count the whole sets of AF and not only multicast IPv6 AF
 > addition)

Let the customer decide on the tradeoff between implementation and
maintanence complexity versus efficiency.

Thanks,
Quaizar


 >
 > Thanks
 > Sina