[PDB-tech] Netnod Stockholm LANs same IX

Job Snijders job at instituut.net
Sun Apr 17 08:52:41 PDT 2016


On Sun, Apr 17, 2016 at 05:36:45PM +0200, Arnold Nipper wrote:
> 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.

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

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

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.

Would this approach simply things?


More information about the Pdb-tech mailing list