Re: [v6ops] [Idr] BGP Identifier

Christopher Morrow <morrowc.lists@gmail.com> Sat, 15 February 2014 18:37 UTC

Return-Path: <christopher.morrow@gmail.com>
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 40C6A1A0274; Sat, 15 Feb 2014 10:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_FROM=2.3, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no
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 SVxl5IRQVpbl; Sat, 15 Feb 2014 10:37:49 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD01A026E; Sat, 15 Feb 2014 10:37:49 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id l4so10138940lbv.38 for <multiple recipients>; Sat, 15 Feb 2014 10:37:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=e03H8yrtuHfpXKfPuUMvx9LCVdLWHB5BjRQWsREgUE8=; b=MtsN1Po/2wz2aa5TnpcIQHr8qdJEvHqNOhBmaOQLZ5F15bxL0R1ZFHhNFtA5JZEm3Q 6TkhMBwQbNYkDmt+MCcyc3Mbml5mhOG/NTIVmIK96vEMwcXs4t0dj5B+q7duVJqb7IIH eJE/aQC+p37tc2ecaPFRJV6n9IPhVfOsQF1IRIEfo7151qHvFBxRQg8AAhFRGj5juJoj gKL4H0ai9Nov5d6cdyEmRJUUMYF4mEvWf9JOGEp8FKT8z6VUC7pCm2ZzxOdtTmkjvxTx 8yGwmVEJtFLqyJUVkRKVJsnP8HhEZB9IQ+JyzQS263S3LqB/NHjNS/fobfFc5KFmPE1/ 3+7Q==
MIME-Version: 1.0
X-Received: by 10.112.114.228 with SMTP id jj4mr10121916lbb.13.1392489466570; Sat, 15 Feb 2014 10:37:46 -0800 (PST)
Sender: christopher.morrow@gmail.com
Received: by 10.152.203.167 with HTTP; Sat, 15 Feb 2014 10:37:46 -0800 (PST)
In-Reply-To: <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net>
References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com> <m2wqgyjifd.wl%randy@psg.com> <B4D8E670-3823-468F-AA41-FE14754F168C@steffann.nl> <11C9319C-A886-4B9E-9E8D-6947A73DB08E@castlepoint.net> <69e0019b-c13d-4989-b330-d470c37f2ee2@email.android.com> <13E534FF-C97D-4B07-BA34-E62DED3DBE88@castlepoint.net> <570C72FF-349F-4CAF-9EA7-9A847CC0420D@steffann.nl> <32ACD29A-AF81-498F-B849-A018D928591F@castlepoint.net>
Date: Sat, 15 Feb 2014 13:37:46 -0500
X-Google-Sender-Auth: GD4lSzvTplg_64EcysF3ZqR-_Wo
Message-ID: <CAL9jLaaFeZ-f=n8UM3aNtuRX5A9=z0koDfhY8vRh11z5Najv0w@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Shane Amante <shane@castlepoint.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/Z1hj64vsfZ5XJnskWSeRUdofyfI
X-Mailman-Approved-At: Mon, 17 Feb 2014 19:33:44 -0800
Cc: idr wg <idr@ietf.org>, V6 Ops List <v6ops@ietf.org>
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: Sat, 15 Feb 2014 18:37:51 -0000

On Sat, Feb 15, 2014 at 10:53 AM, Shane Amante <shane@castlepoint.net> wrote:
>> And what does an integer called ROUTER_ID tell you about that?
>
> In my past experience, I have found that -- particularly in new networks that I'm unfamiliar with -- looking at the output of "show (ospf|isis) database extensive", finding a ROUTER_ID that originated the LSA/LSPDU and performing a ping and/or traceroute to it to verify the sanity of where in the topology that ROUTER_ID is located has been helpful in rapidly diagnosing and fixing brokenness.  Yes, I will admit that it is not a panacea (i.e.: it does not help in the case of duplicate ROUTER_ID's), but 99% of the time it's often using that information to figure out where traffic is, or is not, going to.
>

for isis I think unique router-id is important (at least inside the
same level? or perhaps I'm just thinking that changing the router-id
is a ted update event.) but for bgp it seems less important (aside
from the troubleshooting you outline). I imagine it'd actually be nice
to be able to set a router-id externally and a different one
internally actually. This could have some fun implications really...
'my router-id everywhere is 1!' (or zero)

>> And hey, you can always create records like
>>  1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net
>
> And, when your DNS server is unreachable because you've got a network issue, what then?

you could, of course, replace 'dns' with any other separated mapping
system (say a text file in the least complex setup). This does add
more work for O&M though, which is probably bad :( extra record
keeping isn't particularly good...

I wonder though what's going to happen if you don't have ipv4 on the
network anylonger, and have no need for ipv4 identifiers? do you just
keep numbering the router-id from "some ipv4 space" or do we have to
look at updating bgp to have a router-id (and isis and ospf and...)
that's more than just 32 random bits that happen to look like an ip
address?

-chris