[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