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