Re: [Idr] RFC5065 - Section 5.3

Danny McPherson <danny@tcb.net> Tue, 08 July 2008 16:16 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFA03A6A38; Tue, 8 Jul 2008 09:16:07 -0700 (PDT)
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 B339E3A683A for <idr@core3.amsl.com>; Tue, 8 Jul 2008 09:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level:
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
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 T18e8mtUaZN6 for <idr@core3.amsl.com>; Tue, 8 Jul 2008 09:16:05 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E16FC3A6A76 for <idr@ietf.org>; Tue, 8 Jul 2008 09:16:00 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 920AD2684E9; Tue, 8 Jul 2008 10:16:10 -0600 (MDT)
Received: from [10.0.9.156] (bedford.lex.arbor.net [204.118.128.2]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for idr@ietf.org; Tue, 08 Jul 2008 10:16:10 -0600 (MDT) (envelope-from danny@tcb.net)
Message-Id: <5471C047-BF87-4180-9D5F-AD7408FA3F94@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: idr idr <idr@ietf.org>
In-Reply-To: <487378D9.3010707@uk.clara.net>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Tue, 8 Jul 2008 10:15:54 -0600
References: <48736F35.5030300@uk.clara.net> <20080708135820.GA31991@slice> <487378D9.3010707@uk.clara.net>
X-Mailer: Apple Mail (2.926)
Subject: Re: [Idr] RFC5065 - Section 5.3
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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

On Jul 8, 2008, at 8:25 AM, David Freedman wrote:

> Thanks, I do indeed understand but believe it makes it harder now to
> convince vendors to "enhance" implementations now that there is an
> explicit "SHOULD NOT"

It says "SHOULD NOT", not "MUST NOT".  This was done
for interoperability reasons.

Just a reminder, RFC 2119:
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the  
definition is an absolute prohibition of the specification.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that  
there may exist valid reasons in particular circumstances when the  
particular behavior is acceptable or even useful, but the full  
implications should be understood and the case carefully weighed  
before implementing any behavior described with this label.
Given BGP's deployment footprint and the path selection
criteria of existing routers, and the probability of introducing
routing stability with changes of this sort, this text still seems
prudent, IMO.

That said, given that even route reflection CLUSTER_LIST
lengths are considered in path selection, I do consider this
to be a reasonable request, convince your vendor(s) to do it,
the specification certainly doesn't prohibit it.

-danny


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr