[PDB-tech] Netnod Stockholm LANs same IX

[Matt Griswold]

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