[PDB-tech] proposed new attribute: max_allowed_peering_next_hop_latency

[LOOS Eric (BCS/CBU)]

Hi,

I am not 100% familiar with the internals so just to make sure I understand; this attribute is intended to signal to prospective peers (as part of a peering policy) that you have as a network a particular max latency peering policy. As far as I understand it, you would not request a network to document the latency every particular peering record has to the actual next L3 hop, correct?

I understand the comment about lawyering over a definition of remote peering, but I don't think it is that much of an issue. Remote peering is very much an accepted way of connecting to IX'es and it has many valid use cases. Furthermore 'are you using remote peering' is a very understandable question for new participants (which are most likely not to meet the requirement). Therefore I would indeed stick with an easy definition of a policy requirement saying remote peering: 'accepted, not accepted, no preference'

In addition, again if I understand it correctly, this only works one way? i.e. someone checking whether they can peer with NTT will find the max_allowed_peering_next_hop_latency attribute and have to decide whether they can connect, it doesn't work from the point of view of a network seeking to peer with all non-remote peering members on an exchange? That would also be very valuable but calls for a remote peering record on each IX connection. Luckily, this could be maintained by the IX'es in most cases because they know whom came in via a partner.

As such, indeed it is a policy requirement, but it is important enough next to ratio requirements, multiple locations, ... given the amount of new customers joining in this way.

Just my 2 cents :)

--
Eric Loos


Date: Wed, 20 Apr 2016 17:29:27 +0200
From: Arnold Nipper <arnold.nipper at de-cix.net>
To: "pdb-tech at lists.peeringdb.com" <pdb-tech at lists.peeringdb.com>
Subject: Re: [PDB-tech] proposed new attribute:
        max_allowed_peering_next_hop_latency
Message-ID: <5717A057.7020808 at de-cix.net>
Content-Type: text/plain; charset="utf-8"

On 19.04.2016 17:19, Job Snijders wrote:

> I propose a new attribute for network records called
> "max_allowed_peering_next_hop_latency".
>

Excellent idea! Where did this idea only came from ;-)

> The purpose of this attribute is to signal to other interested parties
> (human peering coordinators looking for new interconnection, or
> computer scripts generating route server configs) what the maximum
> unidirectional latency can be between the two (potentially) peering routers.
>

Who of us really is able to do measurement of unidirectional latency?
Hence I would propose to stick to some sort of RTT (if I understand your post in the other thread correctly it would be
Min(RTT_of_a_series_of_pings)/2))

Otoh I do not really care as long as it is easy to measure the latency.
Doing it via ping *is* easy.


Kind regards
Arnold
--
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



________________________________

**** DISCLAIMER****
http://www.bics.com/maildisclaimer/