Re: [v6ops] [Idr] BGP Identifier

Jeffrey Haas <> Tue, 18 February 2014 16:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 21BD31A069B; Tue, 18 Feb 2014 08:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.116
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0zfBeFPexa6C; Tue, 18 Feb 2014 08:06:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 741FD1A0693; Tue, 18 Feb 2014 08:06:42 -0800 (PST)
Received: by (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 <>
To: "Fan, Peng" <>
Message-ID: <20140218160639.GC12348@pfrc>
References: <> <> <> <> <00d501cf2c6a$36c995d0$a45cc170$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00d501cf2c6a$36c995d0$a45cc170$>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 18 Feb 2014 09:52:41 -0800
Cc: 'idr wg' <>, 'V6 Ops List' <>, 'Christopher Morrow' <>, 'JAMES' <>
Subject: Re: [v6ops] [Idr] BGP Identifier
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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