Re: [p2pi] ALTO Information Export Service

stefano previdi <sprevidi@cisco.com> Wed, 29 October 2008 13:55 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 2235528C0E8; Wed, 29 Oct 2008 06:55:21 -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 DDD803A6D0F for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 06:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 5PUDg6csZ5ED for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 06:55:13 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 46E603A6AAF for <p2pi@ietf.org>; Wed, 29 Oct 2008 06:55:13 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9TDtBo03643; Wed, 29 Oct 2008 14:55:11 +0100 (CET)
Received: from [192.168.0.100] (ams3-vpn-dhcp4622.cisco.com [10.61.82.13]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9TDtAG03604; Wed, 29 Oct 2008 14:55:10 +0100 (CET)
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Wed, 29 Oct 2008 14:55:04 +0100
From: stefano previdi <sprevidi@cisco.com>
To: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>, John Leslie <john@jlc.net>, Stanislav Shalunov <shalunov@shlang.com>
Message-ID: <C52E29C8.7A835%sprevidi@cisco.com>
Thread-Topic: [p2pi] ALTO Information Export Service
Thread-Index: Ack5IfFnziqzqTA+S7a0lPNtm6F0ogADRzeAACe40Jw=
In-Reply-To: <74CCBBDF76102846AFA7B29F3A98D3F6028963B5@PACDCEXCMB06.cable.comcast.com>
Mime-version: 1.0
Cc: p2pi@ietf.org
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

> From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
> 
>> 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:
> 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