The drafts (three of them, together) are an attempt to define, constrain, and solve the problem.
Yes, it is tricky and difficult. I'm not saying that the solutions (two of them to choose from) are the only way to do it. But, I believe that either of them actually solves the problem. In a nutshell, here's how it works: Mark the path "intent" in one of two ways (customer or non-customer), (based on mutual agreement between adjacent peers) Incorporate some kind of mechanism to detect/prevent fudging (a la bgpsec sig) Apply a simple set of rules based on route color vs peering "type", plus "v-free" type logic. Everything is in-band, and the transitive closure _is_ the transitive closure. ASCII art is not adequate for presenting complex ideas, IMHO. I will attempt to provide a richer presentation for Paris. Please, if anyone is interested, for the love of $deity, read the drafts and provide feedback. Thanks, Brian On Wed, Mar 21, 2012 at 5:37 PM, Randy Bush <[email protected]> wrote: > >>> Answer: Evaluate policy. > >> 'apply prefix lists' you mean? > > No. Evaluate _policy_. Policy is about whether an ASN /intended/ to > > announce a path to another ASN _or_ not. More succinctly: one needs > > input to verify output, (since you said "show me the math"). > > From: Randy Bush <[email protected]> > Subject: Re: do not filter your customers > To: Shane Amante <[email protected]> > Cc: North American Network Operators' Group <[email protected]> > Date: Sat, 25 Feb 2012 15:22:35 +0530 > > > as would be solving world hunger, war, bad cooking, especially bad > > cooking. > > > > route leaks, as much as i understand them > > o are indeed bad ops issues > > o are not security per se > > o are a violation of business relationshiops > > o and 20 years of fighting them have not given us any significant > > increase in understanding, formal definition, or prevention. > > let me try to express how i see the problem. to do this rigorously, i > would need to form the transitive closure of the business policies of > every inter-provider link on the internet. > > why i say it is per-link and not just inter-as (which would be hard > enough) is that i know a *lot* of examples where two ass have different > business policies on different links. [ i'll exchange se asian routes > with you in hong kong, but only sell you transit in tokyo. we have two > links in frankfurt, one local peering and one international transit. ] > > it is not just one-hop because telstra was 'supposed to' pass some > customers' customers' routes to optus. > > i find this daunting. but i would *really* like to be able to > rigorously solve it. please please please explain to me how it is > simpler than this. > > randy > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
