Re: [p2pi] ALTO Information Export Service

Reinaldo Penno <rpenno@juniper.net> Wed, 29 October 2008 04:23 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 7DB993A67FB; Tue, 28 Oct 2008 21:23:26 -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 235293A67E2 for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 21:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 sIG0K4Z+oq-o for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 21:23:23 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id BA4A53A67C1 for <p2pi@ietf.org>; Tue, 28 Oct 2008 21:23:12 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Tue, 28 Oct 2008 21:23:23 PDT
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 21:22:42 -0700
Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 21:22:41 -0700
Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Oct 2008 00:22:40 -0400
Received: from 172.23.1.75 ([172.23.1.75]) by proton.jnpr.net ([10.10.2.37]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Oct 2008 04:22:39 +0000
User-Agent: Microsoft-Entourage/12.13.0.080930
Date: Tue, 28 Oct 2008 21:22:30 -0700
From: Reinaldo Penno <rpenno@juniper.net>
To: Salman Abdul Baset <sa2086@columbia.edu>
Message-ID: <C52D3316.13DBD%rpenno@juniper.net>
Thread-Topic: [p2pi] ALTO Information Export Service
Thread-Index: Ack5ffTyF9hrongj1EmiGkePvBGXag==
In-Reply-To: <alpine.SOC.1.00.0810290002350.24142@mango.cc.columbia.edu>
Mime-version: 1.0
X-OriginalArrivalTime: 29 Oct 2008 04:22:40.0752 (UTC) FILETIME=[FB5B2700:01C9397D]
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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Interesting.

How do I interpret its results? For example, first IP addresses I put.

 ./aslookup -r 200.200.200.1 | more

Who owns this prefix? Is it AS7132 (SBC), AS4230(Embratel) or
AS28513(Telmex)?

751:route:      200.200.200.0/24
descr:      cccoe.k12.ca.us
origin:     AS7132
mnt-by:     MAINT-AS7132
changed:    backbone@sbc.com 20030317
source:     RADB

route:      200.200.0.0/16
descr:      EMBRATEL BRAZIL
origin:     AS4230
remarks:    -------------------------------------------------
remarks:    For SECURITY issues, please send messages only to
remarks:    abuse@embratel.net.br
remarks:    -------------------------------------------------
notify:     netadmin@embratel.net.br
mnt-by:     MAINT-EMBRATEL
changed:    netadmin@embratel.net.br 20070222
source:        NTTCOM

route:         200.200.0.0/16
descr:         EMBRATEL
origin:        AS28513
mnt-by:        TELMEX-MNT
changed:       noc@reduno.com.mx 20081014
source:        LEVEL3
DATA Type C
Complete


On 10/28/08 9:05 PM, "Salman  Abdul Baset" <sa2086@columbia.edu> wrote:

> 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