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

[Randy Bush <[e-mail]>]

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