IETF Logo Mail Archive

Re: Address Family Support in OSPFv3

Quaizar Vohra <qv@JUNIPER.NET> Thu, 10 July 2003 18:41 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 OAA16016 for <ospf-archive@LISTS.IETF.ORG>; Thu, 10 Jul 2003 14:41:09 -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.00A5F556@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 14:41:11 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48072059 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 14:41:10 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 14:41:09 -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 h6AIf9u98851 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 10 Jul 2003 11:41:09 -0700 (PDT) (envelope-from qv@juniper.net)
Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h6AIf9I98046; Thu, 10 Jul 2003 11:41:09 -0700 (PDT) (envelope-from qv)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> <3F0C756D.6000308@redback.com> <Pine.OSX.4.51.0307091954210.28357@rwlaptop.local> <3F0CDF59.3050301@redback.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Message-ID: <200307101841.h6AIf9I98046@fuinar.juniper.net>
Date: Thu, 10 Jul 2003 11:41:09 -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: <3F0CDF59.3050301@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

 > > But, if you are carrying something which doesn't necessarily fit into the
 > > ipv6 address format, then you need the new instance, and the new tlv's
 > > anyway, correct?
 >
 > New LSA types will be required to advertise addresses for new address
 > families independent of the approach.

I don't think we would even require new LSA types. The prefix encoding
as it stands currently is fairly flexible. I doubt that you would even
require extra bits in the prefix options. The clearing of NU bit
and the indication of the AF from the instance-id is sufficient to
tell you which AF the prefix belongs to.


 >
 > > So, you've now gained the additional complexity on all
 > > sides, and gained nothing, it seems to me.
 >
 > I'm not sure how get to this conclusion - the processing of the new LSA
 > types is an incremental cost on top of either approach.
 >
 > >
 > > :-)
 > >
 > > Russ
 > >
 > > __________________________________
 > > riw@cisco.com CCIE <>< Grace Alone
 > >
 >
 >
 > --
 > Acee

v2.28.0 | Report a Bug | By Email | System Status