I am working on getting a better grasp on what data we
have in the RIS project from RIPE.
To this end, I am checking the
export policies of the ASes peering with RIPE AS12654 at different
IXPs.
I am wondering if anybody knows what these ASes actually
announce to the RIPE repositories? Do they dump their entire routing
tables (including their internal routes) ?�
In some cases I saw
the export policy ANNOUNCE ANY, is this consistent with a particular AS
behaving like the RIPE AS was its customer?
Another type of export
policy is for example 'to AS12654:� ANNOUNCE AS "YYY"
'(where� "YYY" is any AS peering with RIPE in the RIS
project).
How is this policy different from the previous one from
the point of view of the routing feed the RIPE repository receives?
INEX used to maintain two peering matrices. One was based on RIPE IRRDB
data; the other was based on netflow/sflow BGP data sampled from the IXP
infrastructure. The difference between the two was shocking.
In some cases I saw the export policy ANNOUNCE ANY, is this consistent
with a particular AS behaving like the RIPE AS was its customer?
well, if i was to take that literally, that would include internal
prefixes, e.g. some of p2p inter-router links, loopbacks, ...
of course, taking anything from the IRR literally is naïve at best.
some years back, i asked for a *simple minimal* tagging of announcements
to route views, just peer, customer, internal. it got ietfed to utter
uselessness, with more crap welded on to it than envisioned in mad max.
of course, taking anything from the IRR literally is naïve at best.
Unfortunately, if the BGPSEC, RPKI and SIDR work stays course in the IETF, we're still going to need IRR-esque policy capabilities (outside of route server and prefix origin bindings in that work), so we best starting figuring out how to make them suck less.
some years back, i asked for a *simple minimal* tagging of announcements
to route views, just peer, customer, internal. it got ietfed to utter
uselessness, with more crap welded on to it than envisioned in mad max.
I agree, it's important to analyze systemic cost/benefit and complexity analysis and new operational impacts various standards work is introducing.
Thank you for your reply.
I do, however, have
one more question, please find it bellow.
In some
cases I saw the export policy ANNOUNCE ANY, is this consistent
with a particular AS behaving like the RIPE AS was its
customer?
well, if i was to take that literally, that
would include internal
prefixes, e.g. some of p2p inter-router
links, loopbacks, ...
What would be then the
difference between this ANNOUNCE ANY policy and this other policy I have
found "ANNOUNCE AS-YYY" (where AS YYY is the AS exporting its
routes)? What are the ASes actually exporting in this case?
of course, taking anything from the IRR literally is na�ve at
In some cases I saw the export policy ANNOUNCE ANY, is this consistent
with a particular AS behaving like the RIPE AS was its customer?
well, if i was to take that literally, that would include internal
prefixes, e.g. some of p2p inter-router links, loopbacks, ...
of course, taking anything from the IRR literally is naïve at best.
Please don't conflate the policy mechanisms enabled by the IRR policy *language*/specification itself with the *data* contained in the IRR ...
some years back, i asked for a *simple minimal* tagging of announcements
to route views, just peer, customer, internal. it got ietfed to utter
uselessness, with more crap welded on to it than envisioned in mad max.
Wrt your last paragraph: care to share a link the I-D (or, RFC) that you allude to above?
I think your last paragraph is alluding to tagging routes with standard BGP communities, based on your "simple minimal" criteria, before they are sent to route-views. That strikes me as potentially orthogonal to issues with the present data in the IRR.
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Thu Jan 19 10:06:17 2012
Date: Thu, 19 Jan 2012 11:01:13 -0500
From: Peter Kristolaitis <alter3d@alter3d.ca>
To: nanog@nanog.org
Subject: Re: RIS raw data
>
>> uselessness, with more crap welded on to it than envisioned in mad max.
> oooh... steampunk BGP.
The Internet is like a series of (steam) tubes?
It is widely known that some people _do_ let off a lot of steam via that
mechanism. *chuckle*
Please don't conflate the policy mechanisms enabled by the IRR policy
*language*/specification itself with the *data* contained in the IRR
i don't. the former is called rpsl.
some years back, i asked for a *simple minimal* tagging of announcements
to route views, just peer, customer, internal. it got ietfed to utter
uselessness, with more crap welded on to it than envisioned in mad max.
Wrt your last paragraph: care to share a link the I-D (or, RFC) that
you allude to above?
I think your last paragraph is alluding to tagging routes with
standard BGP communities, based on your "simple minimal" criteria,
before they are sent to route-views. That strikes me as potentially
orthogonal to issues with the present data in the IRR.
