Re: [p2pi] ALTO Information Export Service

Salman Abdul Baset <sa2086@columbia.edu> Wed, 29 October 2008 04:05 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F693A689C; Tue, 28 Oct 2008 21:05:56 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCF13A6A95 for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 21:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9BFKSp8tfGa for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 21:05:53 -0700 (PDT)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9D8B93A67FB for <p2pi@ietf.org>; Tue, 28 Oct 2008 21:05:53 -0700 (PDT)
Received: from mango.cc.columbia.edu (mango.cc.columbia.edu [128.59.29.52]) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9T45lIT011548; Wed, 29 Oct 2008 00:05:48 -0400 (EDT)
Received: from mango.cc.columbia.edu (localhost [127.0.0.1]) by mango.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m9T45lai024465; Wed, 29 Oct 2008 00:05:47 -0400 (EDT)
Received: from localhost (sa2086@localhost) by mango.cc.columbia.edu (8.14.1/8.14.1/Submit) with ESMTP id m9T45iOH024460; Wed, 29 Oct 2008 00:05:45 -0400 (EDT)
X-Authentication-Warning: mango.cc.columbia.edu: sa2086 owned process doing -bs
Date: Wed, 29 Oct 2008 00:05:44 -0400 (EDT)
From: Salman Abdul Baset <sa2086@columbia.edu>
To: Reinaldo Penno <rpenno@juniper.net>
In-Reply-To: <C52CF2E6.13D5A%rpenno@juniper.net>
Message-ID: <alpine.SOC.1.00.0810290002350.24142@mango.cc.columbia.edu>
References: <C52CF2E6.13D5A%rpenno@juniper.net>
User-Agent: Alpine 1.00 (SOC 882 2007-12-20)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-824023566-1225253147=:24142"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8
Cc: p2pi@ietf.org, "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
Subject: Re: [p2pi] ALTO Information Export Service
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

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@cs.berkeley.edu jrex@research.att.com jiawang@research.att.com
> randy@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@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@ietf.org [mailto:p2pi-bounces@ietf.org] On Behalf Of
>> John Leslie
>> Sent: Tuesday, October 28, 2008 1:23 PM
>> To: Stanislav Shalunov
>> Cc: p2pi@ietf.org
>> Subject: Re: [p2pi] ALTO Information Export Service
>>
>> Stanislav Shalunov <shalunov@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@jlc.net>
>> _______________________________________________
>> p2pi mailing list
>> p2pi@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2pi
>> _______________________________________________
>> p2pi mailing list
>> p2pi@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2pi
>
> _______________________________________________
> p2pi mailing list
> p2pi@ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi
>
>
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi