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 <ra...@psg.com> 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 <ra...@psg.com> > > Subject: Re: do not filter your customers > > To: Shane Amante <sh...@castlepoint.net> > > Cc: North American Network Operators' Group <na...@nanog.org> > > 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 > > sidr@ietf.org > > 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:ra...@psg.com";>ra...@psg.com</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:ra...@psg.com";>ra...@psg.com</a>><br> > Subject: Re: do not filter your customers<br> > To: Shane Amante <<a > href="mailto:sh...@castlepoint.net";>sh...@castlepoint.net</a>><br> > Cc: North American Network Operators' Group <<a > href="mailto:na...@nanog.org";>na...@nanog.org</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:sidr@ietf.org";>sidr@ietf.org</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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
