Re: [p2pi] ASN utility

[stefano previdi <[e-mail]>]

Dave, 

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

> From: David Ward <[e-mail]>
> 
> 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.

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

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

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.

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

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

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.

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


_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi