Re: [p2pi] ASN utility

[David Ward <dward at cisco.com>]

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.

-DWard


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
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi