Re: [Idr] Revised proposed IDR charter

"Susan Hares" <skh@ndzh.com> Fri, 05 February 2010 21:07 UTC

Return-Path: <skh@ndzh.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF47A28C0FF for <idr@core3.amsl.com>; Fri, 5 Feb 2010 13:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.019
X-Spam-Level:
X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6quHRl08XYb for <idr@core3.amsl.com>; Fri, 5 Feb 2010 13:07:23 -0800 (PST)
Received: from hickoryhill-consulting.com (63-208-161-197.digitalrealm.net [63.208.161.197]) by core3.amsl.com (Postfix) with ESMTP id EB7D728C0E9 for <idr@ietf.org>; Fri, 5 Feb 2010 13:07:22 -0800 (PST)
Received: from Fargo2 (unverified [64.112.195.202]) by hickoryhill-consulting.com (SurgeMail 3.9h) with ESMTP id 974906-1945496 for multiple; Fri, 05 Feb 2010 16:08:11 -0500
Message-ID: <4BF28081C3744D1DB19DAFF6048743AA@corp.nexthop.com>
From: Susan Hares <skh@ndzh.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Eric Rosen <erosen@cisco.com>
References: <52635EAD-5E0B-4975-BFA5-B315036F59C8@juniper.net><29514.1265213012@erosen-linux> <20100203185142.GA13846@slice>
Date: Fri, 05 Feb 2010 16:08:04 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Authenticated-User: skh@ndzh.com
Cc: idr@ietf.org, Eric Rosen <erosen@cisco.com>
Subject: Re: [Idr] Revised proposed IDR charter
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2010 21:07:24 -0000

Jeff:

This note is **not** about word-smithing the charter, but your concerns 
regarding IDR's actions .

It would be good to have some proposals on exactly what it means to:
" BGP that's interoperable but may have scaling issues for the wider 
Internet."

We've chatted about what this mean for years, but "scaling issues for wider 
Internet" has lacked specific ideas.

While the IRTF and LISP work has suggested some parameters, I'm interested 
if you, Danny or Eric have a proposal or a paper you might reference.

Thanks,

Sue Hares


----- Original Message ----- 
From: "Jeffrey Haas" <jhaas@pfrc.org>
To: "Eric Rosen" <erosen@cisco.com>
Cc: <idr@ietf.org>
Sent: Wednesday, February 03, 2010 1:51 PM
Subject: Re: [Idr] Revised proposed IDR charter


> On Wed, Feb 03, 2010 at 11:03:32AM -0500, Eric Rosen wrote:
>> With regard to the paragraph:
>>
>>         The IDR working group also has an oversight role for all 
>> extensions
>>         made to BGP for other uses that may be developed in other working
>>         groups. IDR will review extensions made to BGP in other working
>>         groups at least at WG document adoption and during working group
>>         last calls. The IDR working group will also provide advice and
>>         guidance on BGP to other working groups as requested. In some 
>> cases
>>         the IDR WG chairs may work with the chairs of other working 
>> groups
>>         and the IESG to move BGP work into the IDR WG instead of the 
>> another
>>         WG.
>>
>> I'd suggest omitting the first and last sentences.  The first sentence 
>> adds
>> no content, it just provides something to fight about (what does 
>> "oversight"
>> mean, exactly?).
>
> I would agree with Eric about omitting the first sentence.  I disagree 
> with his
> comment on the last sentence.
>
>> On the issue of whether it is IDR's job to "protect the Internet" by
>> blocking other WGs from augmenting the use of BGP (or particular BGP
>> sessions), that fight has been fought and lost multiple times in the past
>> dozen years.
>
> I believe this is less an issue of "protecting the Internet" and more a 
> matter
> of maximizing interoperability.  The day a given BGP protocol based spec
> deviates enough from the domain IDR cares about is the day that spec 
> should be
> forked and the protocol run on a different TCP port.  At that point, it 
> becomes
> that working group's responsibility to provide an interoperability 
> mechanism if
> some sort of interoperability is desired.
>
> I bowed very quickly out of the MPLS-TP work but I believe that 
> illustrates
> what happens when one group takes another's protocol and decides to do 
> their
> own thing.  Let's not have that level of squabble within IETF.
>
> Scalability and session survivability are perhaps another matter.  The new
> charter helps address that with the following work item:
> - Augment the BGP multiprotocol extensions to support the use of
>  multiple concurrent sessions between a given pair of BGP speakers.
>
> With the addition of that work item, my two major concerns about IDR's
> shepherding role for BGP are satisfied:
> - Be interoperable
> - If you're going to cram something into BGP that's interoperable but may 
> have
>  scaling issues for the wider Internet, give me a way to separate that 
> stuff
>  so we can keep global IP connectivity working well.
>
> -- Jeff
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>