> And I'm still looking for a convincing use case, where the benefits outweigh the possible complications that may arise if an ALTO client does not know how to handle ASNs or maps them in a wrong way.
I see two benefits for network operators to use ASNs: (1) ASN can be a useful abstraction (and level of aggregation) for localization, and (2) the mapping of ASN-to-IP prefixes changes relatively slowly, perhaps at a different timescale than changes to ALTO guidance. I worry a little bit about ALTO clients using their own source(s) of ASN-to-IP prefixes information. An Internet Routing Registry (IRR) could be a good third-party source of such information, but they have been known to be incomplete and/or inaccurate (an IRR tutorial can be found at http://www.sanog.org/resources/sanog4-IRR-Tutorial-champs.pdf). Alternatively, a looking glass server could be used, but its usefulness and accuracy may depend on its location in the Internet topology, e.g. http://www.traceroute.org/#Looking%20Glass. -- Rich -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sebastian Kiesel Sent: Thursday, April 23, 2009 6:00 AM To: Reinaldo Penno Cc: [email protected] Subject: Re: [alto] ALTO client protocol and Autonomous System Numbers Hi Reinaldo, On Tue, Apr 21, 2009 at 12:06:37PM -0400, Reinaldo Penno wrote: > Hello, > > I think what you are asking is this: > > If the ALTO protocol uses any type of indirect aggregation (ASNs, PID, > etc) as opposed to plain prefixes, does the ALTO Server needs to > expand them? I do no think this issue is specific to ASNs. You are right, basically my question is not limited to ASNs. However, so far ASNs were the only proposed kind of identifiers, which do not have an immediate meaning to a P2P entity (such as IP prefixes) and which do not have a mapping mechanism to IP prefixes *as part of the proposed ALTO protocol specification* (such as PIDs). And I'm still looking for a convincing use case, where the benefits outweigh the possible complications that may arise if an ALTO client does not know how to handle ASNs or maps them in a wrong way. > As long as you have the proper interfaces /query mechanism in place, > it seems to me you are free to use an aggregation method that suits > your deployment. The ALTO Protocol draft and the presentation at the > last IETF provided examples on PIDs usage and resolution. With a flexible naming scheme for the macros one could also mimic other identifier schemes, e.g., one could define a PID "pid-as1", which expands to the IP prefixes of AS #1, and so on. The difference of using "pid-as1" compared to just using "AS #1" in ALTO queries and replies would be that the ALTO client could rely on an ALTO-internal mapping mechanism, and the ALTO server would be sure that the ALTO client will not misinterpret the ALTO guidance due to using a wrong mapping table. Does this make sense? Thanks, Sebastian -- Sebastian Kiesel mailto:[email protected] Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
