[PDB-tech] Netnod Stockholm LANs same IX

[Kristian Larsson]

On 17/04/16 16:47, Martin J. Levy wrote:
> I think I'm trying to convince you all that there's value in the
> more-complex data structure to handle theses edge cases.

I'm all for having a proper representation of reality but I want to 
focus on the technical side of it.


> While I know there's plenty of simple cases of "one org -> one ixp ->
> one lan", there's still some more complex setups out there.
>
> In regards to the "seem the same" statement; if agree at first pass;
> however, they are slightly different in how they are described. I
> know that in PDB1.0 the ESPANIX IX needed two entries, however it's
> just one IX that you join. It has A/B LAN. That's a "one org -> one
> ixp -> two lans". LINX in London is "one org -> two ixps -> one lan
> per ixp". These are different data models. NETNOD Stockholm is of
> course more complex; but if claim that an ISP simply joints "NETNOD
> Stockholm" independent of the four IPs it acquires (eight with
> v4/v6).

Isn't the Netnod setup more of an agreement thing. Technically you could 
connect to just one. You won't be able to actually order that and you 
might be breaking an agreement, but why does the data structures in pdb 
need to represent arbitrary information from an agreement?

To me, an IXP is something you have a cable to. For Netnod Stockholm you 
have two cables to two somethings so it looks like two IXes. If Netnod 
drops the you-must-connect-to-both so it starts looking like LINX, I 
don't think the data in pdb should need to be updated.

It's not entirely clear to me just how pdb is structured with regard to 
this. With my understanding it seems we could handle Netnod Stockholm 
similar to LINX; one org -> two IXPs -> two lans (vlan for 1500 + 4470) !?

    kll


>
> Am I make sense?
>
> Martin
>
>> On Apr 16, 2016, at 8:23 PM, Matt Griswold <grizz at 20c.com> wrote:
>>
>> * Chris Caputo <ccaputo at alt.net> [160417 02:36 +0000]:
>>> Maybe I'm confused, but those all seem the same to me, and all
>>> seem like examples of two different ix records each with the same
>>> parent org.:
>> I think he's talking about physically, and not necessarily how the
>> data is represented.
>>
>>> LINX Juniper & LINK Extreme STHIX 1500 MTU & STHIX 9000 MTU
>>> ESPANIX A & ESPANIX B NETNOD A 1500 & NETNOD B 4420 SIX Seattle
>>> Standard & SIX Seattle Jumbo
>>>
>>> The single ix example that I think is most complicating is a
>>> single LAN with two IPv4 address spaces and one IPv6 address
>>> space,
>> Agree completely, I don't see any point in it - and with either
>> system it would be a jumble.
>>
>>> or the like, where folks in the same "Peers at this Exchange
>>> Point" list (and same LAN) can't actually all reach each other.
>> That's a huge mess caused by the current schema, and I hadn't
>> thought of it until you brought it up earlier in this thread. It's
>> arguable that moving participants under the IX LAN where they
>> belong would be more work than just fixing the relationship
>> (someone cue ex-spouse joke? :).
>>
>> * "Martin J. Levy" <mahtin at mahtin.com> [160416 19:04 -0700]:
>>> There's different setups that should be handled.
>> Great examples to bring up, so proposed new system:
>>
>>> - two LANs, two IX names, two IP ranges (LINX Juniper & LINX
>>> Extreme)
>> 2 IXes, separate prefixes, MTUs, etc
>>
>>> - two IP ranges on one IX name (STHIX with 1500 & 9000 MTU LANs)
>>> (ESPANIX with two LANs)
>> Also 2 IXes, can "join" them by `long_name`
>>
>>> - two LANs on two IX names (NETNOD A&B with 1500 & 4420 MTUs)
>> Also, 2 IXes, each has it's own prefix and MTU.
>>
>>> That means the complex table setup has value. Mind you; it's
>>> unclear how the end user would use this. ESPANIX has been very
>>> free form under PDB1.0
>> I don't know that usability changes much either way, as long as
>> it's specified how it works. My biggest thing for usability is not
>> needing to do another lookup when going from network to IX, which
>> has already caused a lot of confusion.
>>
>>> I'd vote for complexity as long as it matches how data can be
>>> created by the IX for (let's say) the Euro-IX json data.
>> Agree completely, just don't think it's needed in this case. Their
>> ixp-json-schema will import correctly either way, and I already
>> have working code from one of the hackathons.
>>
>> I think I have a very nice way to "degrade" this into the form
>> without IX LAN while still keeping compatibility with the current
>> API. SIX is one of the few who has used to the multiple LAN per IX
>> feature and Chris has agreed to work with us and test on a
>> development instance.
>>
>> Great comments and insight, keep them coming.
>> _______________________________________________ Pdb-tech mailing
>> list Pdb-tech at lists.peeringdb.com
>> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
> _______________________________________________ Pdb-tech mailing
> list Pdb-tech at lists.peeringdb.com
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
>