Re: OSPF WG Charter Proposal

Dave Katz <dkatz@JUNIPER.NET> Fri, 08 November 2002 07:49 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 CAA09719 for <ospf-archive@LISTS.IETF.ORG>; Fri, 8 Nov 2002 02:49:12 -0500 (EST)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007BA4A8@cherry.ease.lsoft.com>; Fri, 8 Nov 2002 2:51:43 -0500
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332616 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 8 Nov 2002 02:51:42 -0500
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 8 Nov 2002 02:51:42 -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 gA87pgS84533 for <OSPF@DISCUSS.MICROSOFT.COM>; Thu, 7 Nov 2002 23:51:42 -0800 (PST) (envelope-from dkatz@juniper.net)
Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id gA87pgx69866; Thu, 7 Nov 2002 23:51:42 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net)
References: <E7E13AAF2F3ED41197C100508BD6A32879198B@india_exch.hyderabad.mindspeed.com>
Message-ID: <200211080751.gA87pgx69866@cirrus.juniper.net>
Date: Thu, 07 Nov 2002 23:51:42 -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: <E7E13AAF2F3ED41197C100508BD6A32879198B@india_exch.hyderabad.mindspeed.com> (VishwasM@NETPLANE.COM)
Precedence: list

   a) As Jerry stated earlier, a lot of these things have already been done in
   a proprietry way by vendors. I would want to know how you feel having a
   standard way would clutter the code while a non-standard way would not?

Given that most of this stuff is not subject to standardization, it's
unlikely that there will be a "standard" way, for what that's worth.

The issue is whether the more complex stuff is worth doing, particularly
if the implementation is already robust enough to not collapse under load.

   b) I think we have made it clear that we do not intend to fiddle with the
   protocol in the normal case, that is why we have not followed an approach of
   basing the flooding on RTT unlike some other protocols.

Actually, flooding based on RTT can certainly be done without "fiddling
with the protocol" (assuming that you mean a normative change.)  As long
as the packets look right, you can do a whole lot without torquing the
standard.