Listing or google map of peering exchange

Wed Jul 9 21:10:18 UTC 2014

On Jul 9, 2014, at 1:15 PM, Patrick W. Gilmore <patrick at ianai.net> wrote:

> On Jul 09, 2014, at 16:03 , Bill Woodcock <woody at pch.net> wrote:
>> it’s all automated with rulesets and a whole lot of exceptions (knowing that AS 701, 702, 703 are the same organization, etc.).
> 
> Is that a good idea?
> 
> For instance, if I were stupid enough to peer with as3856 and not with as42 (because not peering with either of those is idiotic :), would I get the same data as peering with both?
> 
> It is absolutely true that if I peer with as702, I do _not_ get the same prefixes as peering with as701. Just because one is a downstream of the other does not mean they are separate (from BGP's PoV).

There are a lot of these things that seem self-evident to a human in specific cases, but when you write a rule to implement the apparently-self-evident-specific-case, it winds up creating something unanticipated elsewhere.  The more you try to have common code that gets applied uniformly across multiple tools, the more you wind up with unexpected results.  So, there are times when people want to know that AS42 and AS3856 are both PCH, and there are times when they want to know that they’re different ASes with different routing policies.

I’ll report back when I know whether or how we’re over-uniquing that number.  In all likelihood, we’re applying a ruleset that’s used in multiple tools, and someone thought it made sense to aggregate more in a different tool.  But that’s just speculation, and I’ll know more when our staff who maintain that have finished looking through that section of code and get back to me.

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140709/205ede68/attachment.sig>