Re: [v6ops] [Idr] BGP Identifier

joel jaeggli <joelja@bogus.com> Tue, 18 February 2014 03:55 UTC

Return-Path: <joelja@bogus.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 1B9E81A030F; Mon, 17 Feb 2014 19:55:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] 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 o_622q1Of9kl; Mon, 17 Feb 2014 19:55:09 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EF1A0129; Mon, 17 Feb 2014 19:55:09 -0800 (PST)
Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s1I3t1Qa055188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 03:55:01 GMT (envelope-from joelja@bogus.com)
Message-ID: <5302D994.1030801@bogus.com>
Date: Mon, 17 Feb 2014 19:55:00 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0
MIME-Version: 1.0
To: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>, Christopher Morrow <morrowc.lists@gmail.com>, Randy Bush <randy@psg.com>
References: <12AA6714-4BBE-4ACE-8191-AA107D04FBF4@cisco.com>, <m2wqgyjifd.wl%randy@psg.com>, <006801cf2b34$22837cd0$678a7670$@chinamobile.com>, <m2a9dqfr6k.wl%randy@psg.com>, <009e01cf2b8b$26a43d20$73ecb760$@chinamobile.com>, <CA+b+ERnD8yeeT-KzNZzJU4ZJYqMSW9YjD5JYdwhDR=dPHfuSkw@mail.gmail.com>, <002401cf2bc8$8d1a7a50$a74f6ef0$@chinamobile.com>, <m21tz22fyz.wl%randy@psg.com>, <009801cf2bea$cd5eafb0$681c0f10$@chinamobile.com>, <m2wqgtu72t.wl%randy@psg.com>, <CAL9jLaZg4_4bhyaR7vUvmqZ9hiQkFy=mQFPCq-zwDJ=RSiwWGg@mail.gmail.com> <2014021810450694712020@chinamobile.com>
In-Reply-To: <2014021810450694712020@chinamobile.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neMTn6Mn9OFbeD1QKP68CoWAKHeon6evk"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Feb 2014 03:55:02 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/5WrBG9D7JnH7-rOwwRwKSSw33RY
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: Tue, 18 Feb 2014 03:55:12 -0000

On 2/17/14, 6:45 PM, lizhenqiang@chinamobile.com wrote:
> 
> 
> 
> 
> 
> 
> Thank you very much, Mr. Morrow. Yes, it is a good start. I will
> contact Vijay for detail. However, I do not see the function that we
> want from the slides. In fact, we also use some tools to assist our
> network plan. However, the tools can not satisfy such complex
> requirement. In a hierarchical operation network, the tools to
> implement the logic we want is not a easy job. Zhenqiang Li

We allocate ipv4 addresses today presumably, which implies the existence
of business logic in basically all isps that accounts for the hierarchic
allocation of 32 bit numbers.

A brief cruise over to

http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

Reveals a pool of  at least 28 bits (a /4 in ipv4 land) worth of 32bit
numbers that will never overlap with ipv4 unicast address assignments
that you traditionally use for router-ids. embedding those in family iso
addresses if you like seems harmless and you'll never accidentally
configure one as a unicast address on an interface. it'll be a little
while before I need 268 million bgp speaking routers in the same AS.


> 
> From: Christopher MorrowDate: 2014-02-17 23:59To: Randy BushCC: idr
> wg; V6 Ops List; Robert RaszukSubject: Re: [Idr] [v6ops] BGP
> Identifierhttp://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf
>
>  Mike's presentation (given by vijay) is a decent start...
> 
> On Mon, Feb 17, 2014 at 9:50 AM, Randy Bush <randy@psg.com> wrote:
>>> Would you please give me an example about how modern large ISPs
>>> manage their networks?
>> 
>> programmatic generation of configurations from databases.
>> 
>> randy
>> 
>> _______________________________________________ Idr mailing list 
>> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________ Idr mailing list 
> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
> 
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>