Re: OSPF WG Charter Proposal

Dave Katz <dkatz@JUNIPER.NET> Thu, 07 November 2002 23:17 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 SAA17618 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Nov 2002 18:17:57 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007B8D4D@cherry.ease.lsoft.com>; Thu, 7 Nov 2002 18:20:27 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331431 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 7 Nov 2002 18:20:27 -0500
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 7 Nov 2002 18:20:26 -0500
Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gA7NKQS59191 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 7 Nov 2002 15:20:26 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA7NKQ368904; Thu, 7 Nov 2002 15:20:26 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net)
References: <20021107230916.JPPU12281.rwcrmhc52.attbi.com@rwcrwbc69>
Message-ID: <200211072320.gA7NKQ368904@cirrus.juniper.net>
Date: Thu, 07 Nov 2002 15:20:26 -0800
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: Dave Katz <dkatz@JUNIPER.NET>
Subject: Re: OSPF WG Charter Proposal
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To: <20021107230916.JPPU12281.rwcrmhc52.attbi.com@rwcrwbc69> (message from Manohar Naidu Ellanti on Thu, 7 Nov 2002 23:09:16 +0000)
Precedence: list

   And no need to address to ways of reducing the LSAs that need to be flooded
   in a timely manner? When both sides have synced up LSDB then only the  link
   is declared FULL. But all the auxliary information is also exchanged before a l
   ink is declared FULL. Shouldn't that be part of protocol - to declare adjacency
   is FULL once basic link/node information is in sync and in the second phase the
   neighbors can exchange auxiliary information such as link colors etc i.e phased DB exchange. This all
   This all boils down to seperating the basic functionality from extended functionality which
   should reduce the congestion.

Deciding when the adjacency is declared FULL has no direct impact on
congestion, only on convergence time.

Playing games along these lines certainly requires protocol spec changes;
whether they are sufficiently worthwhile in OSPFv2 to make such changes
is open to debate.