Re: [p2pi] ALTO Information Export Service

"Woundy, Richard" <Richard_Woundy@cable.comcast.com> Tue, 28 October 2008 23:02 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 1EA5728C32B; Tue, 28 Oct 2008 16:02:03 -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 9088428C32F for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 16:02:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 mI-OT6CuJrWb for <p2pi@core3.amsl.com>; Tue, 28 Oct 2008 16:01:55 -0700 (PDT)
Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 46A7F3A6931 for <p2pi@ietf.org>; Tue, 28 Oct 2008 16:01:55 -0700 (PDT)
Received: from ([24.40.15.92]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.52469714; Tue, 28 Oct 2008 19:01:13 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Oct 2008 19:01:13 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 28 Oct 2008 19:00:35 -0400
Message-ID: <74CCBBDF76102846AFA7B29F3A98D3F6028963B5@PACDCEXCMB06.cable.comcast.com>
In-Reply-To: <20081028172316.GC7530@verdi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [p2pi] ALTO Information Export Service
Thread-Index: Ack5IfFnziqzqTA+S7a0lPNtm6F0ogADRzeA
References: <127D035B-1B67-4168-9DFE-90C55173562D@shlang.com> <20081028172316.GC7530@verdi>
From: "Woundy, Richard" <Richard_Woundy@cable.comcast.com>
To: "John Leslie" <john@jlc.net>, "Stanislav Shalunov" <shalunov@shlang.com>
X-OriginalArrivalTime: 28 Oct 2008 23:01:13.0313 (UTC) FILETIME=[13258510:01C93951]
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

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

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