Re: [v6ops] [Idr] BGP Identifier

Jeffrey Haas <jhaas@pfrc.org> Tue, 18 February 2014 16:06 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD31A069B; Tue, 18 Feb 2014 08:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level:
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zfBeFPexa6C; Tue, 18 Feb 2014 08:06:42 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 741FD1A0693; Tue, 18 Feb 2014 08:06:42 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A02DC25C; Tue, 18 Feb 2014 11:06:39 -0500 (EST)
Date: Tue, 18 Feb 2014 11:06:39 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Fan, Peng" <fanpeng@chinamobile.com>
Message-ID: <20140218160639.GC12348@pfrc>
References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <m2iosdta7m.wl%randy@psg.com> <2014021811305909988540@chinamobile.com> <CAL9jLaa6fXL+FFNFgdK257dbHGXqm4YBRfMEocoQPEAczPmH-Q@mail.gmail.com> <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <00d501cf2c6a$36c995d0$a45cc170$@chinamobile.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/oLhewjrjjnc-XgT5lMmD6EVEx_o
X-Mailman-Approved-At: Tue, 18 Feb 2014 09:52:41 -0800
Cc: 'idr wg' <idr@ietf.org>, 'V6 Ops List' <v6ops@ietf.org>, 'Christopher Morrow' <morrowc.lists@gmail.com>, 'JAMES' <ju1738@att.com>
Subject: Re: [v6ops] [Idr] BGP Identifier
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 16:06:47 -0000

On Tue, Feb 18, 2014 at 01:28:10PM +0800, Fan, Peng wrote:
> Normally it is easier to handle routers within the AS as we have full
> control over it. I think the key point is the ASBR, as we have no control of
> its eBGP peers. A simple approach is to enable both this extension and
> RFC6286, and assign a 32-bit ID in addition to the 128-bit one for backup
> purpose before we are aware of the capability of its peers.

I am not in favor of this draft.  While I understand the operational desire
for it, what the routing protocols (not just BGP) require is just some magic
number to be used to identify various protocol properties tied to a given
router.  I don't think we want to see a series of similar drafts updating
every other protocol in an attempt to realize a consistent 128 bit router id
throughout an AS.

The fact that this number has been able to receive a mapping to a real
address has been extremely operationally useful.

What I would instead suggest is finding a mechanism by which the unique
router-ID can be mapped easily to such addresses.  I don't believe that BGP is
the right place to do this.

-- Jeff