This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IXP peering lan reachability
- Previous message (by thread): [address-policy-wg] IXP peering lan reachability
- Next message (by thread): [address-policy-wg] IXP peering lan reachability
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friaças
cfriacas at fccn.pt
Tue Oct 24 13:12:05 CEST 2017
Hi, On Tue, 24 Oct 2017, Nick Hilliard wrote: > Gert Doering wrote: >> The *absence* of the route is a very strong indicator that no other >> services than directly peering-related are sitting on that network, no? > > or that the holder is squatting the space, or that it's being used for > connectivity which is unrelated to the standard DFZ (e.g. l3vpn p2p > addressing), or that it's just not being used at that time, or... > > By all means, the RIPE NCC should flag things as a problem if it sees > server farms configured on an assigned ixp range, or sees traceroutes > ending up in residential customer, or whatever, but the presence or > absence of a prefix in the dfz, per se, does not mean anything. I understand it as a simple clue. Clues sometimes lead nowhere... Btw, is the NCC already monitoring this address space's usage somehow? (i may have missed this bit from Andrea's presentation, i didn't catch it from the beginning). Or we are simply relying on stat.ripe.net, atlas, and the like...? Cheers, Carlos > Nick >
- Previous message (by thread): [address-policy-wg] IXP peering lan reachability
- Next message (by thread): [address-policy-wg] IXP peering lan reachability
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]