[Idr] RFC5065 - Section 5.3

David Freedman <david.freedman@uk.clara.net> Tue, 08 July 2008 13:32 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 78C373A69A0; Tue, 8 Jul 2008 06:32:06 -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 886003A69A0 for <idr@core3.amsl.com>; Tue, 8 Jul 2008 06:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.105
X-Spam-Level:
X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, WHOIS_MYPRIVREG=1.499]
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 3f5ZPZhGNeYO for <idr@core3.amsl.com>; Tue, 8 Jul 2008 06:32:04 -0700 (PDT)
Received: from synchronicity.convergence.cx (synchronicity.convergence.cx [195.8.70.6]) by core3.amsl.com (Postfix) with ESMTP id CB18928C164 for <idr@ietf.org>; Tue, 8 Jul 2008 06:31:19 -0700 (PDT)
Received: from synchronicity.convergence.cx (localhost.localdomain [127.0.0.1]) by synchronicity.convergence.cx (8.13.8/8.13.8) with ESMTP id m68DiLUQ005540 for <idr@ietf.org>; Tue, 8 Jul 2008 14:44:22 +0100
Message-ID: <48736F35.5030300@uk.clara.net>
Date: Tue, 08 Jul 2008 14:44:21 +0100
From: David Freedman <david.freedman@uk.clara.net>
Organization: Claranet Limited
User-Agent: Thunderbird 2.0.0.14 (X11/20080421)
MIME-Version: 1.0
To: idr@ietf.org
X-Enigmail-Version: 0.95.6
Subject: [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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Admittedly I'm a little late for this now that draft-ietf-idr-rfc3065bis
is now an RFC, but I'm unclear as to why Section 5.3 (3) states:

3) When comparing routes using AS_PATH length, CONFED_SEQUENCE and
      CONFED_SETs SHOULD NOT be counted.

I would rather have said:

When comparing routes using AS_PATH length, an implementation MAY
provide the ability to count CONFED_SEQUENCE and CONFED_SET.


Looking back through the archives, I see Ilya Varlashkin has commented
on this previously :

(http://www.nabble.com/BGP-best-path-selection-in-confederations-(draft-ietf-idr-rfc3065bis-06.txt)-td11081109.html#a11081109)


I too run a network where each subconfederation has a discrete IGP and I
do not wish them to interact, an implementation which provides the
ability to count CONFED_SEQUENCE / CONFED_SET and use this for route
comparison would be extremely useful, I do not understand why the
author(s) have used "SHOULD NOT" in this case, it seems silly.

Can somebody explain?

Regards,

David Freedman


- --
David Freedman
Group Network Engineering
Claranet Limited
http://www.clara.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIc281tFWeqpgEZrIRAuMRAJ0c326vMTO+C17me7QEuVqRt8JKMgCgjb7S
ucQOP5cSwu9jupiDdpMw++o=
=WcEY
-----END PGP SIGNATURE-----
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr