Re: [v6ops] [Idr] BGP Identifier

joel jaeggli <joelja@bogus.com> Tue, 18 February 2014 04:35 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 7861F1A055A; Mon, 17 Feb 2014 20:35:06 -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 L0wtm_UtSavH; Mon, 17 Feb 2014 20:35:04 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7C1A04B7; Mon, 17 Feb 2014 20:35:04 -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 s1I4LNtp055332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Feb 2014 04:21:23 GMT (envelope-from joelja@bogus.com)
Message-ID: <5302DFBD.1090105@bogus.com>
Date: Mon, 17 Feb 2014 20:21:17 -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: George Michaelson <ggm@algebras.org>
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> <5302D994.1030801@bogus.com> <CAKr6gn3YUVus7gPoWYa896mDfXNTe7-9kZbPgDC7z7r4tzV-Jw@mail.gmail.com>
In-Reply-To: <CAKr6gn3YUVus7gPoWYa896mDfXNTe7-9kZbPgDC7z7r4tzV-Jw@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="2D9odCIkxMX8RqjNN0sWm8Va8HF75saXI"
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 04:21:24 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/ERQbKGtIN5aIH-50vEbTNgBpFlk
Cc: idr wg <idr@ietf.org>, V6 Ops List <v6ops@ietf.org>, Christopher Morrow <morrowc.lists@gmail.com>
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 04:35:06 -0000

On 2/17/14, 8:12 PM, George Michaelson wrote:
> 240/4 had drafts against it. NEVER is alas, not a normative word in what
> Joel said.

I was refering to 224/4 which has a fairly toxic property with respect
to it's reuse as ipv4 unicast...

> Juniper already includes a flag to use 240/4 in cloud, at the request of a
> cloud services company.

yup...

> 
> On Tue, Feb 18, 2014 at 1:55 PM, joel jaeggli <joelja@bogus.com> wrote:
> 
>> 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
>>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>