On Mon, Jun 10, 2013 at 03:22:41PM -0400, Patrick W. Gilmore wrote:
> On Jun 10, 2013, at 14:14 , Joe Provo <nanog-p...@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-p...@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
