On 9-Jul-2007, at 16:58, Sandy Murphy wrote:
I recall asking at the mike in the Oct 06 ARIN meeting about support
for RPSS. Andrei Robachevsky (RIPE rep there at the time) said that
RIPE fully supports RPSS.
As a some-time use of the RIPE db, I agree.
(Ray Plzak said that ARIN did not.)
Similarly, as a some-time user of the ARIN db, I agree with that too.
The key point is that it is possible to build a prefix filter based
on policy expressed in an aut-num or as-set RPSL object using the
RIPE database
I thought the RPLS route object was the closest match to the ROA, not
the aut-num/as-set. Wrong?
What usually happens is that for each ISP there is a set of AS
numbers, the members of which are used to originate routes. One (or
more) of those ASes will roughly equate to "the ISP". The rest
probably can be treated as "BGP-speaking customers".
A peer (in the BGP sense, not the economic sense) of that ISP who
wants to filter prefixes announced from that ISP's routers might ask
"what's your AS-SET?" and receive the name of an object whose members
are the ASes mentioned above. The peer can then query the whois
server and enumerate "all routes with an origin AS that is a member
of this set".
I think in the context of SIDR, the IRR as a whole (the RPSS-
supporting minority and the rest) represents a source of possibly-
feasible routes that a peer AS might want to announce. There are
other such sources (e.g. mail from customers saying "please announce
X"). RPSS means the set is more likely to be accurate, but it's still
no guarantee of anything in practice (and will never be so long as
there are RPSL repositories run by people who are not RIRs).
However you obtain your list of feasible routes, you still need a
reliable, automated mechanism for deciding whether a given route is
actually sensible to accept. It seems to me that most of that would
be accomplished by the work being discussed here (with the possible
exception of a convention or protocol to allow ROAs to be retrieved?).
Joe
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
