On Fri, Nov 4, 2011 at 4:52 PM, Brian Dickson <[email protected]> wrote: > On Fri, Nov 4, 2011 at 4:11 AM, Randy Bush <[email protected]> wrote: >> could someone post a clear technical explanation of WHAT a route leak >> is, > > I'll bite. > > It requires carefully a constructed definition, first: > "Customer" - A is a customer of B iff A has an arrangement with B > which explicitly allows B to announce A's routes to any third party, > and for B to announce B's entire routing table to A. > > Customer is a technical arrangement, regardless of how or why that > arrangement was arrived at, e.g. paying money.
channeling russ: "where is this arrangement publicly documented?" (So I can know it and put it into my algorithm) > If A is a customer of B, A is allowed to announce A's own routes (and > by extension A's customer's routes) to B. > A _may_ (or may not, at A's discretion) signal to B that A wishes B to > forward all (or a subset) of A's (and A's customers) routes to third > parties. > A is not _required_ to do so, and A may further signal that B should > only send those prefixes to a subset of third parties with whom B > peers. > > (Observe: B may always announce A's routes to B's other customers.) > > A route leak occurs, when B announces non-customer routes to non-customers. > > (Those would be routes for which B has not been given explicit > _blanket_ permission to announce to third parties.) > Where is this documented? (this permissions giving) How is this enforced? (the permission) what about cases of partial transit? (I sent a route to B, and requested he NOT send it to the world at large) how is that sort of thing documented? (again, channeling russ) > If A (a customer of B) signals to B to not announce a subset of routes > to B's non-customers, but B does so anyways, that would _not_ > constitute a true route-leak as such. depends on your perspective I suppose, no? Doesn't RPSL today have the ability to signal: "Send partial routes to Foo and Full routes to Bar" ? > (It would, however, be a contractual and technical issue that would > normally be resolved between A and B.) > > If it helps, I've tried to illustrate the leak/no-leak distinction below... it didn't really... re-explaining valley-free routing with mistakes due to agreements not-available 2 as-hops away isn't helpful. Routes leak, people should filter... not new knowledge. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
