Hi, Jay, Out of curiosity, have you had a chance to read (or skim over) the drafts?
Basically, what they do is say, "how can we categorize the link, with four options to choose from". The categories do not need to handle all the subtleties, they only need to be consistent with whatever local policy is. E.g. Your first example - having the "second party" configure the link as "transit-customer" does not in any way obligate them to apply a transit _policy_ on the link. The link coloring is technically orthogonal to all existing policy mechanisms. It simply adds a mechanism to automatically stop route leaks. The three drafts together have a simple rule of thumb: if all three "standard" link type categorizations would block routes that the peers mutually agree should not be blocked, the fourth, "mutual transit" allows anything to pass. It just so happens that the way "mutual transit" handles customer and non-customer routes, prevents route leaks from crossing the other three types of link (customer, transit, peer). If the "local policy" applied to a given link can fit within one of the three "standard" classes (as a proper subset) without blocking routes that should be sent, then that "standard" class should be used. It is meant to be easy to use, and easy to figure out classification. The question "Am I sending _any_ non-customer routes?", from the perspective of both peers, leads to the correct answer: No/No == Peer Yes/No == Transit No/Yes == Customer Yes/Yes == "mutual transit" (generic for "oddball") This suggests I need to make the docs a little clearer in this regard -- I definitely will. Thanks for your feedback. Brian On Thu, Mar 22, 2012 at 11:27 AM, Jay Borkenhagen <[email protected]> wrote: > I am aware of a number of ebgp relationships where the two parties > disagree on the nature of their connections: > > - the first party believes the second is a transit customer > > - the second party believe the first is a peer > > Today the two parties agree to disagree, and yet the proper routing > works. > > > I am also aware of a number of intricate routing policies, along the > lines of in-country transit, per-continent peer, world-wide customer. > > > I'm afraid these kinds of things could make it tricky or even > impossible to categorize links in black-and-white terms as is done in > these leaks drafts. > > > > Brian Dickson writes: > > 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 > > > > > The drafts (three of them, together) are an attempt to define, > constrain, and solve the problem.<br><br>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.<br> > > But, I believe that either of them actually solves the > problem.<br><br>In a nutshell, here's how it works:<br>Mark the path > "intent" in one of two ways (customer or non-customer), (based on > mutual agreement between adjacent peers)<br> > > Incorporate some kind of mechanism to detect/prevent fudging (a la > bgpsec sig)<br>Apply a simple set of rules based on route color vs peering > "type", plus "v-free" type logic.<br><br>Everything is > in-band, and the transitive closure _is_ the transitive closure.<br> > > <br>ASCII art is not adequate for presenting complex ideas, IMHO. I > will attempt to provide a richer presentation for Paris.<br><br>Please, if > anyone is interested, for the love of $deity, read the drafts and provide > feedback.<br> > > <br>Thanks,<br>Brian<br><br><div class="gmail_quote">On Wed, Mar 21, > 2012 at 5:37 PM, Randy Bush <span dir="ltr"><<a href="mailto: > [email protected]">[email protected]</a>></span> wrote:<br><blockquote > class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex"> > > <div class="im">>>> Answer: Evaluate policy.<br> > > >> 'apply prefix lists' you mean?<br> > > > No. Evaluate _policy_. Policy is about whether an ASN /intended/ > to<br> > > > announce a path to another ASN _or_ not. More succinctly: one > needs<br> > > > input to verify output, (since you said "show me the > math").<br> > > <br> > > </div>From: Randy Bush <<a href="mailto:[email protected]";>[email protected] > </a>><br> > > Subject: Re: do not filter your customers<br> > > To: Shane Amante <<a href="mailto:[email protected]";> > [email protected]</a>><br> > > Cc: North American Network Operators' Group <<a href="mailto: > [email protected]">[email protected]</a>><br> > > Date: Sat, 25 Feb 2012 15:22:35 +0530<br> > > <br> > > > as would be solving world hunger, war, bad cooking, especially > bad<br> > > > cooking.<br> > > ><br> > > > route leaks, as much as i understand them<br> > > > o are indeed bad ops issues<br> > > > o are not security per se<br> > > > o are a violation of business relationshiops<br> > > > o and 20 years of fighting them have not given us any > significant<br> > > > increase in understanding, formal definition, or prevention.<br> > > <br> > > let me try to express how i see the problem. to do this rigorously, > i<br> > > <div class="im">would need to form the transitive closure of the > business policies of<br> > > every inter-provider link on the internet.<br> > > <br> > > </div>why i say it is per-link and not just inter-as (which would be > hard<br> > > enough) is that i know a *lot* of examples where two ass have > different<br> > > business policies on different links. [ i'll exchange se asian > routes<br> > > with you in hong kong, but only sell you transit in tokyo. we have > two<br> > > links in frankfurt, one local peering and one international transit. > ]<br> > > <br> > > it is not just one-hop because telstra was 'supposed to' pass > some<br> > > customers' customers' routes to optus.<br> > > <br> > > i find this daunting. but i would *really* like to be able to<br> > > rigorously solve it. please please please explain to me how it is<br> > > simpler than this.<br> > > <span class="HOEnZb"><font color="#888888"><br> > > randy<br> > > </font></span><div class="HOEnZb"><div class="h5"><br> > > _______________________________________________<br> > > sidr mailing list<br> > > <a href="mailto:[email protected]";>[email protected]</a><br> > > <a href="https://www.ietf.org/mailman/listinfo/sidr"; target="_blank"> > https://www.ietf.org/mailman/listinfo/sidr</a><br> > > </div></div></blockquote></div><br> > > _______________________________________________ > > sidr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
