Re: [p2pi] ALTO Information Export Service
stefano previdi <sprevidi@cisco.com> Wed, 29 October 2008 15:33 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 9FDDB3A68DB; Wed, 29 Oct 2008 08:33:17 -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 BF0A328C29F for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 08:33:16 -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 TjaPvdVEKfpf for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 08:33:15 -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 374103A687E for <p2pi@ietf.org>; Wed, 29 Oct 2008 08:33:15 -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 m9TFX9W09822; Wed, 29 Oct 2008 16:33:09 +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 m9TFX8G09809; Wed, 29 Oct 2008 16:33:08 +0100 (CET)
User-Agent: Microsoft-Entourage/11.4.0.080122
Date: Wed, 29 Oct 2008 16:33:03 +0100
From: stefano previdi <sprevidi@cisco.com>
To: Laird Popkin <laird@pando.com>
Message-ID: <C52E40BF.7A8EE%sprevidi@cisco.com>
Thread-Topic: [p2pi] ALTO Information Export Service
Thread-Index: Ack526Gv4EZK9KXOEd2VNgAX8vOM8g==
In-Reply-To: <1603497045.408271225293796368.JavaMail.root@dkny.pando.com>
Mime-version: 1.0
Cc: Richard Woundy <Richard_Woundy@cable.comcast.com>, 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: Laird Popkin <laird@pando.com> > > 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 protocols). s. > - Laird Popkin, CTO, Pando Networks > mobile: 646/465-0570 > > ----- Original Message ----- > From: "stefano previdi" <sprevidi@cisco.com> > To: "Richard Woundy" <Richard_Woundy@cable.comcast.com>, "John Leslie" > <john@jlc.net>, "Stanislav Shalunov" <shalunov@shlang.com> > Cc: p2pi@ietf.org > Sent: Wednesday, October 29, 2008 9:55:04 AM (GMT-0500) America/New_York > Subject: Re: [p2pi] ALTO Information Export Service > >> 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 _______________________________________________ p2pi mailing list p2pi@ietf.org https://www.ietf.org/mailman/listinfo/p2pi
- Re: [p2pi] ALTO Information Export Service Laird Popkin
- Re: [p2pi] ALTO Information Export Service stefano previdi
- Re: [p2pi] ALTO Information Export Service John Leslie
- [p2pi] ALTO Information Export Service Stanislav Shalunov
- Re: [p2pi] ALTO Information Export Service John Leslie
- Re: [p2pi] ALTO Information Export Service Woundy, Richard
- Re: [p2pi] ALTO Information Export Service Reinaldo Penno
- Re: [p2pi] ALTO Information Export Service Salman Abdul Baset
- Re: [p2pi] ALTO Information Export Service Reinaldo Penno
- Re: [p2pi] ALTO Information Export Service stefano previdi
- Re: [p2pi] ALTO Information Export Service Laird Popkin
- Re: [p2pi] ALTO Information Export Service Reinaldo Penno
- Re: [p2pi] ALTO Information Export Service John Leslie
- Re: [p2pi] ALTO Information Export Service Laird Popkin