[as112-ops] Yahoo Peering Invite at Phoenix IX

[Joe Abley]

Hi Nick,

Seems to me that there are two cases here:

1. An AS who peers and/or buys transit wants to export the usual AS112 routes with origin 112 as part of the normal set they send to their BGP neighbours because they host an AS112 node internally, and

2. An exchange point operator hosts an AS112 node at an exchange, and solicits adjacencies between their router in AS112 and the routers of other exchange participants.

In the first case (which I've seen before) peers and transit providers want to see something that looks like an LOA that confirms that you are entitled to propagate the AS112 prefixes. I know we discussed writing something that looks like an LOA in the RFC series at some point, so there was a consistent, official-looking reference to pass on. I don't think anything ever came of that idea.

In the second case I'm not sure I precisely understand what is needed. Is the problem that the AS112 node at FooIX has NOC/ops contact info that is different from the AS112 node at BarIX? Or is this more like a PeeringDB schema problem, that it's hard for more than one person to administer records related to AS112? Or something else?

If case (2) has intractable problems and (1) does not, one option would be to avoid (2) and make the IX cases look like (1) -- have the exchange point management AS give transit to 112 towards peers, rather than having people peer with 112 routers directly?


Joe

> On May 24, 2017, at 12:25, Nick Hilliard <nick at inex.ie> wrote:
> 
> Matt Griswold wrote:
>> * Aleksi Suhonen <as112-ops at trex.fi> [170523 13:18 +0300]:
>>> So some months ago Yahoo sent the peering invite, which I forwarded on
>>> this list. Later they closed that ticket. And now they created a new
>>> ticket, to which I responded with the old ticket. Now they seem to be
>>> waiting for me to set up the sessions in Phoenix IX. (see attachment)
>> 
>> I escalated it at Yahoo, they're going to take care of it.
> 
> Yahoo isn't the only large organisation which has problems with AS112.
> Turns out, most organisations large enough to have a provisioning
> database make the assumption that an ASN has a single owner, which fails
> epically with as112.
> 
> Nick
> 
> _______________________________________________
> as112-ops mailing list
> as112-ops at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/as112-ops