Re: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-bgpsec-ops-14: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 05 January 2017 02:53 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 7BD6F129864; Wed, 4 Jan 2017 18:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 64t9X5ndu6RJ; Wed, 4 Jan 2017 18:53:35 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 B924D129513; Wed, 4 Jan 2017 18:53:35 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id t125so331464948ywc.1; Wed, 04 Jan 2017 18:53:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=45DJNKetxloGT6VNEWjrOpROdQvwUNJJUqH0XVIYGeQ=; b=u7KbwpJUH7wdlPg6p7SrmMDg3VUZGoavt0SoZwLSbFUjA/KKMizKKYGvQAWW0+nejp E201oRg6GWiTo6GiUhVTy+MIDnioGDTUVNsAqwW7NbgI3QP3+Sc6xgcQwnprWHE6p4tz 0NbuUOTO6JkTpGdPww2xUAeVLTwfJVi++UYp7CW6+khlm4eI5UMbf82Abj5ndeM8ysmO RRqKcuXZs1NJFbzRzKLjVFZwiHnZqrB+lfm0pNxPAp3OPNyeVdBGKxE7CxcHi623KKaA 8PcqN6Xf8WuxuxPxh2coPKtjOwgBmOl+bXH4D6iEbCCluC7epFYN+dtQStdo4Ya1wNXd GFhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=45DJNKetxloGT6VNEWjrOpROdQvwUNJJUqH0XVIYGeQ=; b=f6F6oIL84h7+xVBemSljpgz6YHTS6XFJyOLxYh1QUZtHMeFrN3OlFLVuVkF+7WwC3X dnGvJpIutWYgbqiD6ZjTAM8z/xfKIH+GU0cOz26zjdSKVVzG2V3/VJEpatP3TO5MnsAw mNBIC2hUUspIhnzA71u2pc8Ln1NV/sI91CC9xYzgm3DesiNVuSHr2HPM6Ljn8LYMLrmg iHrkyb7beX5APgw0FNo+do1uXs+iDkJ66WRTrm3SVXIvXC9g64nxst5IMnrZHVfKunon znNiBbTLIWROkPjLEdS7wEdWIGwQA8ST5CHgLZSZtY6ZsfeA142p7iSOqAyWJmo6CLfW Ujqw==
X-Gm-Message-State: AIkVDXJcGQTzGBg6z8z+YXTu966Y1957AgB0ImQzg5CHiXtQmlM05eVY+GM6jyw/V3KQwAtwwBLAd5+p3SogKQ==
X-Received: by 10.13.197.68 with SMTP id h65mr66838993ywd.84.1483584815070; Wed, 04 Jan 2017 18:53:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.221.195 with HTTP; Wed, 4 Jan 2017 18:53:34 -0800 (PST)
Received: by 10.37.221.195 with HTTP; Wed, 4 Jan 2017 18:53:34 -0800 (PST)
In-Reply-To: <m2d1g2l5kw.wl-randy@psg.com>
References: <148355705100.13011.5709768999664450618.idtracker@ietfa.amsl.com> <m2d1g2l5kw.wl-randy@psg.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 04 Jan 2017 20:53:34 -0600
Message-ID: <CAKKJt-eiV+-u8WSO+BqpHp=rf4ERp_sq48PDeQfwhAfw5uwcMA@mail.gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: multipart/alternative; boundary="001a114ea2f4e58c480545500149"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/AWYB6FhFa8NWYP5DeePEqlwY1JA>
Cc: 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 02:53:37 -0000

Hi, Randy,

On Jan 4, 2017 18:21, "Randy Bush" <randy@psg.com> wrote:

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.


I'm wondering if there's another term that's not wrong, and not more
confusing. If you say there's not, I believe you!

Thanks for catching me up.

Spencer