Re: [p2pi] ALTO Information Export Service

John Leslie <john@jlc.net> Tue, 28 October 2008 17: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 2FBA828C349; Tue, 28 Oct 2008 10:23:19 -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 8EA7328C327 for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 10:23:17 -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 k6jVjQLg++4A for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 10:23:16 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id B53A828C2D4 for <p2pi@ietf.org>; Tue, 28 Oct 2008 10:23:16 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 31C4933C36; Tue, 28 Oct 2008 13:23:16 -0400 (EDT)
Date: Tue, 28 Oct 2008 13:23:16 -0400
From: John Leslie <john@jlc.net>
To: Stanislav Shalunov <shalunov@shlang.com>
Message-ID: <20081028172316.GC7530@verdi>
References: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com>
User-Agent: Mutt/1.4.1i
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

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.txt
] ...
] 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