Re: [v6ops] BGP Identifier

Owen DeLong <owen@delong.com> Sat, 15 February 2014 21:43 UTC

Return-Path: <owen@delong.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 848E81A02F1; Sat, 15 Feb 2014 13:43:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.538
X-Spam-Level:
X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 LkHFeUZfyyiE; Sat, 15 Feb 2014 13:43:02 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6691A02B6; Sat, 15 Feb 2014 13:43:01 -0800 (PST)
Received: from [IPv6:2620::930:0:ca2a:14ff:fe3e:d024] ([IPv6:2620:0:930:0:ca2a:14ff:fe3e:d024]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s1FLeBem010469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 15 Feb 2014 13:40:13 -0800
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s1FLeBem010469
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1392500415; bh=py+2a5F2SF2/mXtnmOvVVLK8uBY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HnCAPca9T8TdpORsaTKLKyj2a4qz0KZKzDnt0wD7rov8tLJlYSPwwnWqGOYqhLQvw 8qrhS/SBU2u1gKKU+guv49kFNTXZSVxSebz+tBMaYEO7i1rkWZ3Cf+gI50k+c2gbhn HDxLstDfHapIL2l8lJe5ecysHEmXtOv1jQrl8rgY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <52FFB6B7.4090408@foobar.org>
Date: Sat, 15 Feb 2014 13:31:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E674C4B-E339-4622-88A1-254797721C1A@delong.com>
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> <52FFB6B7.4090408@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Sat, 15 Feb 2014 13:40:15 -0800 (PST)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/CgZS4-5AhnrpkiDeRb958279iUs
Cc: V6 Ops List <v6ops@ietf.org>, draft-fan-idr-ipv6-bgp-id@tools.ietf.org, idr wg <idr@ietf.org>
Subject: Re: [v6ops] 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 21:43:04 -0000

If nothing else, if the authors intend to apply this to more routing protocols than just BGP, they should change the proposal to reflect that they seek to change ROUTER-IDs in general and not just the BGP identifier.

However, I believe that the idea of converting a router-id from 32 bits to 128 bits is woefully misguided. I say this as an operator who has operated IPv4 and IPv6 and dual-stack networks.

It has always, IMHO, been unfortunate that OSPF Area numbers and Router-IDs for various protocols have been tied to IPv4 address syntax and, in the case of router-IDs, affiliated with interface (including loopback) IP addresses. This has created no end of confusion among less well trained operators.

IPv6 gives us the opportunity to correct this problem and have IDs which no longer match addresses. That is a "good thing™" IMHO.

As near as I can tell, this draft seeks to prevent that improvement from occurring.

Instead, I think that Sander and David are on a much better track and I would be willing to join in on the efforts to write such an operational draft.

Owen

On Feb 15, 2014, at 10:49 , Nick Hilliard <nick@foobar.org> wrote:

> On 15/02/2014 15:26, Sander Steffann wrote:
>> Op 15 feb. 2014, om 16:13 heeft Shane Amante <shane@castlepoint.net> het volgende geschreven:
>>> On Feb 15, 2014, at 12:55 AM, Randy Bush <randy@psg.com> wrote:
>>>> I use this funny thing called DNS. 
>>> 
>>> And that has what to do with the problem of determining liveness or determining where in the topology is a ROUTER_ID?
>> 
>> And what does an integer called ROUTER_ID tell you about that?
>> 
>> And hey, you can always create records like
>>  1.2.3.4.router-id.castlepoint.net IN CNAME router1.somewhere.castlepoint.net
> 
> guys, we're all having a bit of an ietf moment here: within the space of 48
> hours, the conversation has ratholed.  Let's love up a bit.
> 
> The authors of the draft have a simple operational desire to make their
> lives a little easier and as an operator I sympathise with this,
> particularly because they are using ipv6-only networks in anger which is
> more than I do.
> 
> There are two advantages of having a 128 bit router-id (with the unstated
> convention of tying router-id == address of first loopback):
> 
> - firstly it's easy to identify the location of prefix announcements on
> your network
> - secondly the router-id can be autoconfigured.
> 
> On the other hand, implementing this will require that the authors define a
> transition mechanism to allow 128 bit router-id routers interoperate with
> 32 bit router-id routers in such a way that router-id collisions don't occur.
> 
> If the authors want to progress this, they need to state a stronger use
> case and they need to create a transition mechanism.  If they can do this
> in a reasonable way which doesn't break backwards compatibility, then it
> might be appropriate for idr / v6ops / etc to take another look at the draft.
> 
> Also, I wish them well because everyone understands what a router ID is and
> everyone will want to paint theirs a different colour.
> 
> Nick
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops