Re: [p2pi] ALTO Information Export Service
Laird Popkin <laird@pando.com> Wed, 29 October 2008 16:47 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 43DD13A681B; Wed, 29 Oct 2008 09:47:42 -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 DCF5E3A681B for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 09:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.265
X-Spam-Level:
X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334]
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 pae+oDRk5VtH for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 09:47:39 -0700 (PDT)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 618FF3A635F for <p2pi@ietf.org>; Wed, 29 Oct 2008 09:47:39 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5E850E10B1A; Wed, 29 Oct 2008 12:47:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+kPzl6l9mYv; Wed, 29 Oct 2008 12:47:19 -0400 (EDT)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id E4289E10B10; Wed, 29 Oct 2008 12:47:19 -0400 (EDT)
Date: Wed, 29 Oct 2008 12:47:19 -0400
From: Laird Popkin <laird@pando.com>
To: John Leslie <john@jlc.net>
Message-ID: <1901116948.409151225298839875.JavaMail.root@dkny.pando.com>
In-Reply-To: <20081029154744.GF7530@verdi>
MIME-Version: 1.0
X-Originating-IP: [10.10.20.77]
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
I agree with your analysis, up until the last paragraph. I don't understand why you say that "policy stated in ASNs is actively misleading" though. Keep in mind that ALTO helps p2p networks find good endpoints, not good routes - that's done by BGP, OSPF, etc., when actually exchanging data. That is, a p2p network knows that it can exchange data between a addresses within (to make up an example) AT&T NYC and Verizon NYC, but it can't control the actual route that the data flows through. Of course, selecting endpoints that have cheap routes between them makes it likely that those cheap routes are actually used, but that's more a matter of the lower layers working properly than anything ALTO allows ISPs to directly express. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "John Leslie" <john@jlc.net> To: "Laird Popkin" <laird@pando.com> Cc: p2pi@ietf.org Sent: Wednesday, October 29, 2008 11:47:44 AM (GMT-0500) America/New_York Subject: Re: [p2pi] ALTO Information Export Service Laird Popkin <laird@pando.com> wrote: > > 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. Indeed they can -- (by omitting any ASN guidance at all). But then, why include the option? The advantage of including an ASN option, IMHO, is that a policy can be stated in a reasonably static manner using ASNs -- provided that the meaning of those ASNs is clearly "where my routers will forward packets". This avoids having to frequently update policy as routing tables change and having to state policy for hundreds of thousands of CIDR blocks. A downside is that ALTO clients may lack up-to-the-minute routing information when mapping IPs to ASNs. That, IMHO, is something to work on when the ALTO WG is formed. Several "good-enough" approaches suggest themselves... But if clients are encouraged to use mapping quite unrelated to the actual routing, then policy stated in ASNs is actively misleading. I would much prefer not to _design_ misleading policy into ALTO. -- John Leslie <john@jlc.net> _______________________________________________ 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