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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
