Dear colleagues, During current RIPE meeting I have presented my report about verification of route policy from registries with deeper analysis for RIPE database. I analysed the customer to provider relations because of its global visibility. The result are fearful: 60% of link completeness, less than half of this amount have information about Pref values and again most of pref values have errors. As a result there is only 10% likelihood to find real priorities using this dataset. The community must decide how to change this situation. In my opinion there are only two ways to overcome this problem: verify this data or delete at all. All our data is available on our website <http://radar.qrator.net>. The collected data is based on imitation mathematical model with use of AS paths recovered from BGP views and novel active verification abilities that could detect priorities on every level of BGP decision making process. We are eager for collaboration and eager to help RIPE Stats or RIPE DB to verify policy data, highlight errors and give other aggregated data if community decides that it is needed. -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@highloadlab.com | visit: www.qrator.net
Dear Alexander, Perhaps I can just clarify what the RIPE Database software does with this data. I presume you are referring to the policy attributes in the aut-num object (import, export, etc). There are syntax checks on all these attributes. These apply the rules defined in RPSL. For example, the keywords and value types and ranges. No checks are done on policy. We don't check for matching import/export. We don't check for any keywords being present or not, or for any values or references being 'correct' by any definition. If the community considers it would be useful to apply checks on the policy content, the RIPE NCC would be happy to work with the community in defining any such checks. Regards Denis Walker Business Analyst RIPE NCC Database Team On 16/10/2013 16:46, Alexander Azimov wrote:
Dear colleagues,
During current RIPE meeting I have presented my report about verification of route policy from registries with deeper analysis for RIPE database. I analysed the customer to provider relations because of its global visibility. The result are fearful: 60% of link completeness, less than half of this amount have information about Pref values and again most of pref values have errors. As a result there is only 10% likelihood to find real priorities using this dataset. The community must decide how to change this situation. In my opinion there are only two ways to overcome this problem: verify this data or delete at all.
All our data is available on our website <http://radar.qrator.net>. The collected data is based on imitation mathematical model with use of AS paths recovered from BGP views and novel active verification abilities that could detect priorities on every level of BGP decision making process. We are eager for collaboration and eager to help RIPE Stats or RIPE DB to verify policy data, highlight errors and give other aggregated data if community decides that it is needed.
-- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@highloadlab.com <mailto:aa@highloadlab.com> | visit: www.qrator.net <http://www.qrator.net/>
Hi On Wed, Oct 16, 2013 at 07:05:15PM +0300, Denis Walker wrote:
If the community considers it would be useful to apply checks on the policy content, the RIPE NCC would be happy to work with the community in defining any such checks.
Actually, having a *warning* if you send in an aut-num: object that declares import/export policies that do not match the corresponding "other AS's" aut-num: policies could useful. Yes, it would create an impressive amount of warnings, but maybe that leads to sufficient peer pressure... Making it an *error* is a no-go, as the amount of non-matching policy documentation is too high (and you'd have an unsolvable conflict when trying to set up a new peering, as whoever tries to enter the policy first would be told "error: other end is not there"). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi,
Actually, having a *warning* if you send in an aut-num: object that declares import/export policies that do not match the corresponding "other AS's" aut-num: policies could useful. Yes, it would create an impressive amount of warnings, but maybe that leads to sufficient peer pressure...
I wonder if this should be a keyword-driven thing to request the verification of policy rather than generating warnings on updates, as policies may start off right but what you really want is a quick way to check whether another ASN has changed their policy and you need to change your own policy to reflect that.
Making it an *error* is a no-go, as the amount of non-matching policy documentation is too high (and you'd have an unsolvable conflict when trying to set up a new peering, as whoever tries to enter the policy first would be told "error: other end is not there").
Just a quick plug that towards the end of tomorrow's routing working group session Denis is going to present on import-via/export-via and following that is going to ask for some thoughts about new ways of showing peering relationships in RPSL... Cheers, Rob
Hi, thank you for responses. I think there is a great need to highlight the information that is outdated or errorless. You can’t say: “We’re just keeping the data, the quality of data depends on community” because people make references not to AS holders but to RIPE DB or RIPE Stats. And most of end-users and even network engineers believe to this reference. As a result – stub networks becomes transnational, filtering networks are said to be distributed. And of course there is little opportunity to use such data for traffic flow prediction or AS design. RIPE DB makes people mistaken and this couldn’t be solved by updating RPSL. 2013/10/16 Rob Evans <rhe@nosc.ja.net>
Hi,
Actually, having a *warning* if you send in an aut-num: object that declares import/export policies that do not match the corresponding "other AS's" aut-num: policies could useful. Yes, it would create an impressive amount of warnings, but maybe that leads to sufficient peer pressure...
I wonder if this should be a keyword-driven thing to request the verification of policy rather than generating warnings on updates, as policies may start off right but what you really want is a quick way to check whether another ASN has changed their policy and you need to change your own policy to reflect that.
Making it an *error* is a no-go, as the amount of non-matching policy documentation is too high (and you'd have an unsolvable conflict when trying to set up a new peering, as whoever tries to enter the policy first would be told "error: other end is not there").
Just a quick plug that towards the end of tomorrow's routing working group session Denis is going to present on import-via/export-via and following that is going to ask for some thoughts about new ways of showing peering relationships in RPSL...
Cheers, Rob
-- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@highloadlab.com | visit: www.qrator.net
Hi Alexander,
RIPE DB makes people mistaken and this couldn’t be solved by updating RPSL.
Understood. However, updating RPSL (for example by abstracting the import/export attributes into a single separate peering object -- not my idea, I hasten to add), could make it easier to maintain accurate policies than having to ensure two different aut-num objects agree with each other. Cheers, Rob
Hi, Rob. Understood. However, updating RPSL (for example by abstracting the
import/export attributes into a single separate peering object -- not my idea, I hasten to add), could make it easier to maintain accurate policies than having to ensure two different aut-num objects agree with each other.
I agree that it would be signficant improvement in the quality of data. But problems with link completeness and wrong priorities could still occur. I think it would be a good first step but it isn't sufficient. -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@highloadlab.com | visit: www.qrator.net
participants (4)
-
Alexander Azimov -
Denis Walker -
Gert Doering -
Rob Evans