Re: [p2pi] ASN utility

David Ward <> Tue, 21 October 2008 20:28 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 36E7F28C1B8; Tue, 21 Oct 2008 13:28:31 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DC693A6870; Mon, 29 Sep 2008 11:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NPUh4UpZGwRR; Mon, 29 Sep 2008 10:59:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6CFD13A6AD8; Mon, 29 Sep 2008 10:59:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,333,1220227200"; d="scan'208";a="22620573"
Received: from ([]) by with ESMTP; 29 Sep 2008 17:59:47 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m8THxkBa015728; Mon, 29 Sep 2008 13:59:46 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m8THxkg1029412; Mon, 29 Sep 2008 17:59:46 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 13:59:46 -0400
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 13:59:46 -0400
In-Reply-To: <>
References: <>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <>
From: David Ward <>
Date: Mon, 29 Sep 2008 12:59:42 -0500
To: Lisa Dusseault <>
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 29 Sep 2008 17:59:46.0403 (UTC) FILETIME=[28875330:01C9225D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3146; t=1222711186; x=1223575186; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20David=20Ward=20<> |Subject:=20Re=3A=20ASN=20utility |Sender:=20 |To:=20Lisa=20Dusseault=20<>; bh=Y8YIyPUdAxuZpE5Fwd1oHlwafm7CD5GA/ZELeobJZRs=; b=bDiMxCrLzP8sY1m2ColGrK/43EzucxVmcaHJxHE+gJXw2ZknO2YsdV4K4k lV6lp6yfPmEx31XNShOgggxHByC7AopkoMZriTY/HYMjIOSt15+z1PbhVoyW qH2dxOYhcy;
Authentication-Results: rtp-dkim-1;; dkim=pass ( sig from verified; );
X-Mailman-Approved-At: Tue, 21 Oct 2008 13:28:30 -0700
Subject: Re: [p2pi] ASN utility
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

Lisa -

My issue is that the charter has ASN as a viable item to return to a  
query without limiting how the ASN is to be gleaned. The solution you  
state below "avoid this ASN" is a bit different than an dynamically  
generated, ordered list of preferred ASN based on current routing  
"proximity" or "reachability." In addition,  information about  
specific attributes and topologic information could be useful, e.g.  
AS path list (vs just AS origin information) for transit "hints."  
There could be a query "give me prefixes and/or ASN that are tagged  
w/ X community" (where the community represents SP preference.  
Another easy one to think about  "give me servers|prefixes in AS X  
that don't traverse AS Y."

There is obviously a large amount of routing data (passed in routing  
protocols along w/ other attributes associated with the prefix, peer,  
AS, exit point, policy, cost, topologic location, etc) that could be  
used in the future for very interesting preference schemes.   
Generally this information is passed in BGP or other routing/ 
signaling protocols. That would mean that the ALTO server would need  
to be a peer or member of the routing system to get this information  
and routing protocol extensions (e.g. BGP) may be necessary.  
Therefore, this interaction and these extensions would be in or out  
of charter. I was confused how far this would go.

If instead you want to limit the server to passing "policy and  
preference information" which in this case is akin to a list of hand  
configured objects (e.g. list of ASN you want some client to prefer)  
that has no other relationship to the routing system, then let's put  
that in the charter. I assume the client in this case would get the  
ASN, "query" some looking-glass server and make decisions.

  I think there are a lot of very interesting services to think about  
when the ALTO server *is* a peer of the routing system but, if the WG  
doesn't want to go down this path ... I'd just like it clarified in  
the charter. If you want it watered down further, I'd like it stated  
in the charter that the outcome of the framework document will make  
it clear and please mention that it is specifically to be worked on.


On Sep 29, 2008, at 12:38 PM, Lisa Dusseault wrote:

> When the IESG looked at the proposed ALTO charter last week, Dave  
> had some comments about ASNs which I'd like to follow up on by  
> dragging Dave into the conversation.
> What I understand the ASN related suggestions so far to be, is to  
> have the ALTO server return a list of ASN numbers to prefer or  
> avoid.  This sort of information could only be provided by an ISP- 
> operated ALTO server.  A peer, armed with this information, can do  
> whatever they do today to figure
> out which IP address falls in which ASN.  The P4P and Yale folks  
> claim that returning a preference of ASNs helped their application  
> tremendously.
> Dave, was your concern about discovering ASN being unnecessary, or  
> about ranking of ASNs being unhelpful?  Can you recap?
> Thanks,
> Lisa

p2pi mailing list