Re: [p2pi] ALTO Information Export Service
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [p2pi] ALTO Information Export Service



Mapping IP addresses to AS numbers by quering RIRs:
http://www.bugest.net/software/aslookup/index-e.html

-s

On Tue, 28 Oct 2008, Reinaldo Penno wrote:

I agree with you Rich. Getting an accurate mapping of IP to 'owner' ASs is
not an easy task. Some people spent a lot of time on this. I did not know
this presentation.

Here is a another very good reference:

Towards an Accurate AS-Level Traceroute Tool
Zhuoqing Morley Mao Jennifer Rexford Jia Wang Randy H. Katz
UC Berkeley AT&T Labs­Research AT&T Labs­Research UC Berkeley
zmao at cs.berkeley.edu jrex at research.att.com jiawang at research.att.com
randy at cs.berkeley.edu

In this paper they discuss in detail all the roadblocks to have a traceroute
tool that maps IP to ASs.

Thanks,

Reinaldo


On 10/28/08 4:00 PM, "Woundy, Richard" <Richard_Woundy at cable.comcast.com>
wrote:

The routing view which actually matters is the view of the ISP router
which dispatches the particular packet at a peering point. Thus, IMHO,
the ISP should usually be the provider of the mapping of IPs to ASNs.

Before this email, my opinion was that if an ISP wanted to include
ASN(s) in the policy to be returned by the ALTO service, then the ISP
should also supply the IP prefix to ASN mappings, so that the combined
ALTO service guidance came from a consistent information source (the
ISP). But I didn't have a strong opinion against using a looking glass
server instead for the IP-to-ASN mappings.

If I understood John correctly, the looking glass server's view of
IP-to-ASN mappings may depend on the server's location in the Internet
topology, and that view may not be equivalent to the view of the ISP
providing the ALTO service.

Here is one example: Within one ISP's backbone, there may be a set of
specific IPv4 prefixes coming from many origin AS's. Within another
ISP's backbone, these specific prefixes may have been replaced (and
subsumed) by a single aggregate prefix with a different origin AS (e.g.
the first backbone). Therefore, the looking glass servers for the first
and second backbones would differ on the correct origin AS with respect
to this aggregated prefix.

Here is a relevant RIPE presentation (from 2003) in which they faced
similar problems with reporting ASNs in traceroutes:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra
ceroutes.pdf. In the scenario of the RIPE presentation, the route
information in the Internet Routing Registries and in the global BGP
routes were often at odds with one another; slides 8, 10, and 11
describe some interesting cases that relate to this discussion about
looking glasses.

John, in short, I think you make a very good point.

-- Rich

-----Original Message-----
From: p2pi-bounces at ietf.org [mailto:p2pi-bounces at ietf.org] On Behalf Of
John Leslie
Sent: Tuesday, October 28, 2008 1:23 PM
To: Stanislav Shalunov
Cc: p2pi at ietf.org
Subject: Re: [p2pi] ALTO Information Export Service

Stanislav Shalunov <shalunov at shlang.com> wrote:

We put together a first iteration of a very simple ALTO solution
draft.  We hope this will be useful as an example point in the
solutions space and thus allow to refine the requirements document and

the problem statement.


http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx
t
] ...
] 7.  Mapping IPs to ASNs

   I expect ISPs will sometimes mean different things by "preferring"
ASNs. (This is a pretty generic problem with ASNs in ALTO.)

   ISPs generally peer with a limited number of ASNs, and reach IPs
"owned" by other ASNs through routes from the ASNs they directly peer
with.

   What actually causes an ISP to "prefer" a set of IPs is knowing that
they will use a route to them through a particular AS they peer with.
This is _not_ the same as which AS "owns" the IP in question. (Nor is
"owned by an AS" necessarily a meaningful statement for a CIDR block.)

   BGP looking-glass views show which ASNs "originate" routes to a
CIDR block. It is not particularly unusual to find more than one AS
"originating" such a route. Thus, looking-glass results cannot assure
that the route a packet will actually follow to reach an IP address
_ever_ passes through a particular AS.

   Looking-glass views _will_ generally show "holes" punched in CIDR
blocks "owned" by one AS for the purpose of balancing traffic to a
multihomed customer of that AS (even though it may be that _none_ of
the traffic will actually pass through the "owner" AS). But looking-
glass views tend to contain routes that are never seen by routers
not "near the backbone".

   The routing view which actually matters is the view of the ISP
router which dispatches the particular packet at a peering point.
Thus, IMHO, the ISP should usually be the provider of the mapping of
IPs to ASNs.

   (This mapping may change several times per second when routes
"flap", but that's a balancing act the ISP is best able to attempt.)

   In any case, if ALTO provides ASN "preferences" at all we should
provide a mechanism for the ISP to perform mapping of IP to ASN.
(IMHO, at least...)

--
John Leslie <john at jlc.net>
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.