Re: [v6ops] [Idr] BGP Identifier

David Farmer <> Sat, 15 February 2014 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C90131A0277 for <>; Sat, 15 Feb 2014 11:26:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q3yJHWgoZWlH for <>; Sat, 15 Feb 2014 11:26:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A33481A0214 for <>; Sat, 15 Feb 2014 11:26:09 -0800 (PST)
Received: from ( []) by (UMN smtpd) with ESMTP for <>; Sat, 15 Feb 2014 13:26:04 -0600 (CST)
X-Umn-Remote-Mta: [N] [] #+LO+TS+TR
X-Umn-Classification: local
Received: by with SMTP id k19so2822473igc.4 for <>; Sat, 15 Feb 2014 11:26:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=plgJqSQ4/tOPyQ6PTC0ZHFKzNtrUs3Z5f92DWrNQYJM=; b=G64x6ac8S9bOeBaTPVTuwadaid/jGou7b/HaV2ghO5GNg2FZ2YJ/lYaLkKhNt3+DZq rFuC5TDsvGPI4ED850KD5WnWUf81/6AZAXOIgVo/JVTTSJH2f9AFwXxgZN5423MaBjS6 D88IxMG0dFcnnKndt8++MiUSnCZkUbY7fqtkwX4Y5mtO5kT9tbTUsulH/XSI0DXlUbpm v3EoPfJNNHPKmBtYBJMCdA7y7B3fFMk/37MpXcfx4xvMNm84aQ+NbsABz99bzsdtZDY3 Hu9hItIIjzhsbqFbUBOBhO+WKxT8z+QMhgyUxgJuPOQgbVIPQJH39clj5V11jTIStTHl WxpA==
X-Gm-Message-State: ALoCoQkmRyaKilliErRU/9C34auzlCnry36hdakLRyUnRE3ofP1N5HxzZkRY7SH2t9FSZyKVM7WMfQfcAlc9/qrCPHGZRHlD+fNeYfk0rwZDwtAuBQReMkwJuyFSvax6myxt80ib3JAc
X-Received: by with SMTP id b6mr11223676icz.22.1392492363281; Sat, 15 Feb 2014 11:26:03 -0800 (PST)
X-Received: by with SMTP id b6mr11223668icz.22.1392492363130; Sat, 15 Feb 2014 11:26:03 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id gd5sm15643872igd.5.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Feb 2014 11:25:59 -0800 (PST)
References: <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <>
X-Mailer: iPad Mail (11B554a)
From: David Farmer <>
Date: Sat, 15 Feb 2014 13:25:59 -0600
To: Shane Amante <>
Cc: idr wg <>, V6 Ops List <>
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: Sat, 15 Feb 2014 19:26:12 -0000

> On Feb 14, 2014, at 21:58, Shane Amante <> wrote:
> I would take exception to a ROUTER_ID being just a 32-bit integer.  Specifically, when a ROUTER_ID is an IP address that allows an operator to quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology of the router purporting to have said ROUTER_ID.
> The other question I would raise is, in a far-off future, if we ever manage to get networks converted away from dual-stack and back to a single AFI -- namely, IPv6 -- if ROUTER_ID's are only 32-bits and you lose those capabilities mentioned above ... would you care?

I agree it is a very common and useful operational practice to use the IPv4 loopback address for the ROUTER_ID.  This practice is strongly reinforced in that most implementations represent the ROUTER_ID in dotted quad decimal notation, the same way we represent IPv4 addresses.

However, common practice does not make it a protocol requirement.  I would suggest there are several possible new operational practices that could be developed that don't require complicate changes to the protocol.  

A very simple one would be to use a common IPv6 prefix for all your /128 IPv6 loopback addresses and embed the ROUTER_ID as the least significant 32 bits.  Just as implementations reinforce the current operational practice, they could also reinforce this possible new practice by representing the 32bit ROUTER_ID in hex instead of dotted quad decimal, or even better both representations next to each other.  Maybe implementations could allow you to specify a /96 IPv6 prefix to be appended with the ROUTER_ID when it is output, giving you the IPv6 address you wanted without changing the protocol.

As an example: let's say your ROUTER_ID is or 0xC0000205.  Then you can use an IPv6 loopback address of 2001:db8:1::c000:205, or you could even used mixed notation 2001:db8:1::

So, you do not loose the ability to "quickly perform diagnosis & troubleshooting using ping/traceroute/etc. to identify the availability and location within the topology."

There was also a DNS recommendation made in the thread, that would work too.

So, I'd prefer effort be put toward an informational draft suggesting operational practices and maybe implementation suggestions that reinforce these suggestions rather than complicated protocol changes.  


David Farmer     
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952