Re: Address Family Support in OSPFv3

Sina Mirtorabi <sina@CISCO.COM> Wed, 09 July 2003 19:28 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 PAA17016 for <ospf-archive@LISTS.IETF.ORG>; Wed, 9 Jul 2003 15:28:40 -0400 (EDT)
Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A5B957@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 15:28:39 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47944350 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 15:28:38 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 15:28:38 -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 h69JSZT18965 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 9 Jul 2003 12:28:35 -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: <000401c34650$4bfce9e0$386545ab@amer.cisco.com>
Date: Wed, 09 Jul 2003 12:28:35 -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: <3F0C51B9.3080306@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

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

If you do not need to have other AF, you can only have the minimum
required in our proposal that is setting the AF bit in the Hello and
v6-AF bit in the AdressFamilies field  (Disabled mode)

Once you want to have additional AF then you have to bother about the
additional two new LSA and potentially other new LSAs in other AF (if
needed) which even in case of multiple instance you would need to define
ways to be backward compatibles, define new LSA for new AF etc

Sina


->
->Thanks,
->Acee
->
->>
->> thanks
->> Sina
->>
->
->
->--
->Acee
->