Re: Address Family Support in OSPFv3

Acee Lindem <acee@REDBACK.COM> Thu, 10 July 2003 18:56 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 OAA16322 for <ospf-archive@LISTS.IETF.ORG>; Thu, 10 Jul 2003 14:56:02 -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 <20.00A5F4EA@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 14:56:03 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48072657 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 14:56:03 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 14:56:02 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 63028A7EEE5 for <OSPF@PEACH.EASE.LSOFT.COM>; Thu, 10 Jul 2003 11:55:34 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> <3F0C756D.6000308@redback.com> <Pine.OSX.4.51.0307091954210.28357@rwlaptop.local> <3F0CDF59.3050301@redback.com> <200307101841.h6AIf9I98046@fuinar.juniper.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3F0DB69A.2060706@redback.com>
Date: Thu, 10 Jul 2003 14:55:22 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@REDBACK.COM>
Subject: Re: Address Family Support in OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Quaizar Vohra wrote:
>  > > 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.

I haven't thought about it in great depth. I guess if you
use solely address family foo prefixes for a address family foo
instance it might be possible.

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


--
Acee