Re: Single AS multiple Dirverse Providers

[Joe Provo <nanog-post () rsuc gweep net>]

On Mon, Jun 10, 2013 at 03:22:41PM -0400, Patrick W. Gilmore wrote:
> On Jun 10, 2013, at 14:14 , Joe Provo <nanog-post () rsuc gweep net> wrote:
> > On Mon, Jun 10, 2013 at 01:18:04PM -0400, Patrick W. Gilmore wrote:
> > > On Jun 10, 2013, at 12:54 , Joe Provo <nanog-post () rsuc gweep net> wrote:
> > > > On Mon, Jun 10, 2013 at 11:36:44AM -0500, Dennis Burgess wrote:
>
> > > > > I have a network that has three peers, two are at one site and the third
> > > > > is geographically diverse, and there is NO connection between the two
> > > > > separate networks.
> > > >
> > > > So, you have two islands? Technically, that would be separate 
> > > > ASNs as they are separatre routing policies, but the modern 
> > > > world has adapted. 
> > >
> > > Should we change the rules? I know with 64-bit ASNs mean it is
> > > tough to run out of ASNs, but not sure we really want each island
> > > to be its own AS going forward.
> > >
> > > Comments from the peanut gallery?
> >
> > I missed your proposal for loop detection to replace the current 
> > behavior in the above text. Was it compressed?
>
> Was not compressed. Don't want to take out loop detection in
> general. If you are running an island, it is up to you to ensure
> that island is specifically configured.

So, you like loop detection but you don't like how it is implemtned? 
Then I ask again for your suggestion for BGPv5.

> This makes it no different than lots of other "weird" things on
> the 'Net.  (I put weird in quotes because weird implies out of the
> ordinary, but there are probably more weird things than "normal"
> things these days.)

Handwave without data meant to belittle the loop detection concern.
"Probably" and "Lots of" are nice rhetorical dodges, but they work 
better in a conference hall. Let's keep this text to real data.

> > I will admit that it is Not Hard for people who know what 
> > they're doing to operate well outside default and standard 
> > behavior. That's why I merely recommended that the questioner 
> > educate themselves as to the whys and wherefore before just 
> > turning knobs. I would submit that not knowing loop detection 
> > is a default and valuable feature might indicate the person 
> > should understand why and how it affects them. I don't have 
> > the hubris to believe that I understand his business needs, 
> > nor edge conditions/failure modes where a different solution 
> > might be needed.
>
> All good points.
>
> Is it enough to keep the standard? Or should the standard have a
> specific carve out, e.g. for stub networks only, not allowing islands
> to provide transit. Just a straw man.

I'd be leery of attempting to add anything into the protocol
spec that doesn't have an alternative for loop detection.

> Or we can keep it like it is today, non-standard and let people
> who know what they are doing violate it at their own peril.

...like much of the rest of the 'net: "know what you're doing".

> The problem with the latter is some ISPs point to standards as
> if there is no other possible way to do things. Which makes it
> difficult to be someone who knowingly violates a standard.

I'll point out that in this case, it only matters for the 
relationship between the island AS and its immediate neighbors;
if I'm paying for service that doesn't get me what I want, I 
vote with my wallet (as we've alreays done).

You skip the obvious route; we write a BCP for "Operation of 
BGP Islands: effective ASN reuse". Some will like it, some 
will throw stones, and some will insist that it just get 
folded into an update to RFC4271. Interestingly, a quick 
re-review of BCP126 doesn't tip its toes into these waters, 
but there might be room to insert it there.

> Anyway, just wondering how others felt.

You like to remind everyone (when convenient) that you don't run 
a "network" - perhaps It would be nice to hear if anyone who runs
*networks* thinks they can discard AS_PATH based loop detection
and they want to cook up Some Other Way for BGPv5.

Cheers!

Joe

-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NANOG