[PDB-tech] Netnod Stockholm LANs same IX

[Job Snijders]

> >> 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.
> > 
> > Maybe the prefix (peering lan prefix) is the unique key here, what if we
> > consider an IXP to be solely an (org, ipv4_prefix ∪ ipv6_prefix) tuple
> > to be an IXP. (prefix being both the v4 and v6 peering lan prefix).
> 
> That also was my first approach and it seems to be natural. But I
> could imagine situations where this doesn't work. You may have e.g
> Job-IX with a single switch in three cities all using the *same*
> ipv4_prefix ∪ ipv6_prefix, but still being *different* IXPs ...

I cannot see how that works. I'd consider such an IXP to be in
splitbrain mode. I do not know of an IXP which has been designed this
way. If a participant would be connected to two of the three sites and
operate the network without next-hop-self on iBGP blackholing would be
the result. 

> > The (org, ipv4_prefix ∪ ipv6_prefix) tuple has properties such as
> > locality, MTU, vlan tag, purpose (unicast / multicast), presence of
> > route-servers, arp sponge mac address, etc...
> 
> ... so you at least would have to add locality imho. From there you
> may add properties. It's imho just another approach from what I
> proposed and I guess we should take that model which is easiest to
> handle, understand and implement.

Yeah, my main point was that the properties should not be part of the
key that defines a unique IXP.

> > In the PeeringDB integrations I've done I've always targetted the code
> > to search for IPs that are in the same subnet as I am (which means a
> > peering could be established). The properties are then evaluated against
> > the local policy (for instance, inter-domain multicast peering not
> > supported => no multicast peering). What remains can be configured.
> > 
> 
> Regarding same subnet: are there IXP that use *different* subnet on
> the same vlan forming a single peering fabric (not asking why you
> would do so)

That's fine, from a programmatic perspective they would be different
IXPs. If I have configured only one of the subnets but not the other, I
cannot reach the other, so for all intends and purposes its as if the
second subnet is on a different IXP.

Kind regards,

Job