[PDB-tech] Netnod Stockholm LANs same IX

[Arnold Nipper]

On 17.04.2016 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.
> 
> 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?
> 

Basically I fully agree, Martin. I guess one of the main purposes of
PDB2.0 also is/was to ease automation. Hence you have to be able to
easily and automagically retrieve information for e.g. about members,
peerings etc.

And before we start the discussion we all should be clear what we mean
by "LAN" or "IXP".

I guess the model has to go along

 org -> "independant physical infrastructure" -> vlan (-> prefixe(s))

Each unique instantion of this triple (or maybe quadruple) would imho be
what would be an IXP.


> Martin
> 

Arnold

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


-- 
Arnold Nipper
Chief Technology Evangelist and Co-Founder

DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main |
Germany | www.de-cix.net | Phone +49 69 1730902 22 |
Mobile +49 172 2650958 | Fax +49 69 4056 2716 |
arnold.nipper at de-cix.net | Geschaeftsfuehrer Harald A. Summa |
Registergericht AG Koeln HRB 51135

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20160417/402286a2/attachment.sig>