[PDB-tech] Netnod Stockholm LANs same IX

[Martin J. Levy]

I think I'm trying to convince you all that there's value in the more-complex data structure to handle theses edge cases.

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).

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