Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)
Randy Bush <randy@psg.com> Thu, 05 January 2017 00:21 UTC
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E5312947A; Wed, 4 Jan 2017 16:21:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Level:
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZaYUFb40D0Qa; Wed, 4 Jan 2017 16:21:24 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B33129449; Wed, 4 Jan 2017 16:21:24 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cOvo2-0005G9-6w; Thu, 05 Jan 2017 00:21:22 +0000
Date: Thu, 05 Jan 2017 09:21:19 +0900
Message-ID: <m2d1g2l5kw.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
In-Reply-To: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com>
References: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/gg_0lLsqJ9HaISSXMJm60fbde0I>
Cc: The IESG <iesg@ietf.org>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 00:21:25 -0000
you are at the intersection (well actially union) of two twisty sets of passages, bgp routing and internet ops. > I'm wondering if "the transitive closure of a client's customers" has > a precise meaning. I know what a customer is, at the hand-waving > level the academic, overly-idealized, definitions of customer/provider/peer are in https://www.cs.princeton.edu/~jrex/papers/sigmetrics00.long.pdf, aka gao-rexford; though this has been shown to apply to the real internet far less strictly than many researchers have stubbornly assumed; see http://conferences2.sigcomm.org/imc/2015/papers/p71.pdf at the network ops level, a 'customer' is an ebgp-speaking AS to which you give routes learned from o other custimers o your peers o your upstreams/transits o your internals of course, by business arrangement, this might be restricted. this may be contrasted with peers and upstreams/transits, to whom you give only customer and internal routes. > Is "customer" being used a shorthand for another term that isn't > depending on an economic transaction? exactly > (If this was "the transitive closure of a client's clients", for > instance, I would know what that meant a route reflector's "clients" are ibgp speakers (stress is on the 'i') within the RR's AS. a (possibly improper) subset of those clients may be "customer aggregation" routers, i.e. connect via ebgp to ASs of external entities (aka customers). iff one or more of those RR clients (or their clients, cf 'transitive closure') speak bgpsec to a customer is the RR required to do bgpsec. if all the customers (which could be the null set) of of the RR's clients speak only bgp classic, there is no requirement that the RR speak bgpsec. randy
- [sidr] Spencer Dawkins' No Objection on draft-iet… Spencer Dawkins
- Re: [sidr] Spencer Dawkins' No Objection on draft… Randy Bush
- Re: [sidr] Spencer Dawkins' No Objection on draft… Spencer Dawkins at IETF
- Re: [sidr] Spencer Dawkins' No Objection on draft… Randy Bush