Subject: Re: [p2pi] ASN utility

From: David Ward <[email-masked]>
Date: Mon, 29 Sep 2008 12:59:42 -0500

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
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: stefano previdi <[email-masked]>
Date: Wed, 22 Oct 2008 18:16:29 +0200

Dave, 

I mostly agree with you. Just a few points below:

> From: David Ward <[email-masked]>
> 
> Lisa -
> 

indeed and note that some of this is already used in 'some'
implementations...

> and routing protocol extensions (e.g. BGP) may be necessary.

I'd prefer to rephrase stating that the alto server would need to access
routing layer information. Having to be a participant is a bit constraintful
to me.

> ASN, "query" some looking-glass server and make decisions.

Well, I hope we can go a bit beyond that. But again, I'm not sure we have to
specify any 'interaction' between alto server and routing layer.

Either the alto server has some form of proprietary mechanisms in order to
acquire routing knowledge, either it uses well known standardized interfaces
such as igp adjacencies and bgp sessions.
 
> it clear and please mention that it is specifically to be worked on.

The alto server needs not to be a participant into the routing layer as it
will raise too many other issues that we would have to address (and probably
in different WGs). This doesn't mean you can't do that... it's just that I
don't think we have to enforce this rule.

But there's no question on whether or not an alto server should get the
routing layer info or optimizing localization computation. I believe it
proved to help.

s.