On Feb 1, 2012, at 12:18 PM, Ben Niven-Jenkins wrote:
> Vijay,
>
> On 31 Jan 2012, at 15:08, Vijay K. Gurbani wrote:
>
>> On 01/31/2012 05:14 AM, stefano previdi wrote:
>> ben> This might be a case where we'd need a PID property to distinguish
>> ben> "transit" PIDs from "End Host" PIDs.
>> ben>
>> stefano> sounds pretty reasonable to me.
>>
>> Ben: I suspect that your question had a foundation of some sort
>> and was not simply a fishing expedition ;-)
>
> The question does have a foundation :-) Partly I'm trying to understand
> precisely what I can & can not infer from an ALTO map and Bill & Rich's
> follow-up confirm a lot of that for me. We probably want to add some text to
> the protocol spec to clarify that because I suspect if I'm asking the
> question then someone else looking to use ALTO for a purpose that wasn't
> originally in scope and who hasn't been involved with ALTO from day 1 might
> have similar questions.
>
> At the same time I'm trying to think through the applicability of ALTO to a
> number of CDN-related scenarios.
>
> One scenario is whether I can get enough "resolution" out of an ALTO map to
> represent the network topology (as it pertains to a CDN) sufficiently.
Yes you can. ALTO servers providing this functionality have been designed,
implemented and some of them are in production.
> If I need to augment what I can get from ALTO with raw IGP/BGP routing to get
> a sufficient (for the CDN) topology then it negates a good chunk of the value
> provided by ALTO IMO.
You don't need to augment ALTO with IGP/BGP data. The ALTO data model has
enough flexibility to convey sufficient topology information from IGP/BGP to a
CDN. Again, ALTO servers that do this have been designed, implemented and some
of them are in production. CDN Request Routers that utilize topology
information from an ALTO Server have been designed, implemented and some of
them are in production.
> It's worth clarifying here that by "sufficient topology for a CDN" I don't
> mean being able to translate a network map back into the raw network
> topology, I only need enough topology to overlay a CDN topology on top of.
> After thinking a bit more about this I think ALTO as-is probably provides
> sufficient information for the purpose although not in the most efficient
> form (but that's not showstopper).
>
We are in agreement here. Even the efficiency is good enough, especially if you
use the Endpoint Cost Interface.
> The other scenarios relate to using ALTO maps for more than just CDN cache
> selection and in those scenarios I'm thinking that ALTO is still probably OK
> and I can achieve a lot of what I need without needing ALTO to expose me a
> graph, provided there are some common constraints applied by the ALTO server
> (like not renaming PIDs) but I need to give those scenarios some more
> thought. I might have a couple of ideas for extensions once I'm done (like
> enabling entries in the IRD to be given a name/ID) but that's a separate
> topic.
>
>> Let me ask you this: is the PID property that you would like to put
>> in useful for CDN-usage in ALTO? If so, and since others
>> (Stefano) appear to agree, then it is worth a larger discussion on
>> the need of such a property to support emerging usages of ALTO.
>
> I'm starting to conclude I don't need the PID property to achieve what I want
> but I haven't 100% convinced myself of that yet. I think the idea of PID
> properties is interesting though so if there's a discussion on them I'll get
> involved. I might have some other use cases but I haven;t really given them
> any thought yet.
>
PID properties (a.k.a PID attributes) are a good idea. "Transit" PIDs are not.
> Ben
>
/Jan
>>
>> Thanks,
>>
>> - vijay
>> --
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>> Email: vkg@{bell-labs.com,acm.org} / [email protected]
>> Web: http://ect.bell-labs.com/who/vkg/
>
> _______________________________________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
