Re: [p2pi] ALTO Information Export Service

stefano previdi <> Wed, 29 October 2008 15:33 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 9FDDB3A68DB; Wed, 29 Oct 2008 08:33:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF0A328C29F for <>; Wed, 29 Oct 2008 08:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TjaPvdVEKfpf for <>; Wed, 29 Oct 2008 08:33:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 374103A687E for <>; Wed, 29 Oct 2008 08:33:15 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from (localhost []) by (8.11.7p3+Sun/8.11.7) with ESMTP id m9TFX9W09822; Wed, 29 Oct 2008 16:33:09 +0100 (CET)
Received: from [] ( []) by (8.11.7p3+Sun/8.11.7) with ESMTP id m9TFX8G09809; Wed, 29 Oct 2008 16:33:08 +0100 (CET)
User-Agent: Microsoft-Entourage/
Date: Wed, 29 Oct 2008 16:33:03 +0100
From: stefano previdi <>
To: Laird Popkin <>
Message-ID: <>
Thread-Topic: [p2pi] ALTO Information Export Service
Thread-Index: Ack526Gv4EZK9KXOEd2VNgAX8vOM8g==
In-Reply-To: <>
Mime-version: 1.0
Cc: Richard Woundy <>,
Subject: Re: [p2pi] ALTO Information Export Service
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

> From: Laird Popkin <>
> Keep in mind that ASNs are just an option in ALTO (as we're discussing it so
> far), so even if the P2P network uses a public IP to ASN mapping database, the
> ISP can provide their own IP prefix guidance without referencing ASNs if they
> care to.

I agree.

However, I also believe on the usefulness BGP can deliver in ranking
preferences. The point to keep in mind is that BGP is location-dependent in
terms of computation (which may not be the case for other routing

> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> ----- Original Message -----
> From: "stefano previdi" <>
> To: "Richard Woundy" <>om>, "John Leslie"
> <>et>, "Stanislav Shalunov" <>
> Cc:
> Sent: Wednesday, October 29, 2008 9:55:04 AM (GMT-0500) America/New_York
> Subject: Re: [p2pi] ALTO Information Export Service
>> From: "Woundy, Richard" <>
>>> 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.
> that is right. BGP is a path vector protocol which means that the visibility
> any router gets from its BGP peers, correspond to the selection mechanisms
> those peers have done (vector-based protocols: first select best route, then
> advertise best route).
> This is valid for any looking glass server as well as for any ALTO server,
> which implies that any preference scheme may vary according to each SP
> location/pop where it is computed.
> s.
>> 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:
>> 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: [] On Behalf Of
>> John Leslie
>> Sent: Tuesday, October 28, 2008 1:23 PM
>> To: Stanislav Shalunov
>> Cc:
>> Subject: Re: [p2pi] ALTO Information Export Service
>> Stanislav Shalunov <> 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.
>> 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 <>
>> _______________________________________________
>> p2pi mailing list
>> _______________________________________________
>> p2pi mailing list
> _______________________________________________
> p2pi mailing list

p2pi mailing list