Hi Piotr,
Hi Richard,
all,
first of all do you have any specific multi-domain ("partitioned") use
case in mind? Our original P2P use case certainly was, but it has become
quiet around it. For the newer use cases such as CDN or VPN optimization
or stuff related to SDN im am not so sure whether we need that.
I remember that many years ago we had detailed discussions how the
partitioned-knowledge-problem could be solved. We had several approaches:
1. all ALTO servers have the same knowledge
1.1. ensure synchronization in the provisioning protocol (cf.
RFC 5693, Fig 1), which is currently not standardized
1.2. standardize an inter-ALTO-server data replication protocol
2. different ALTO servers operated by different organizations (e.g.
ISPs) do NOT have the same (global) knowledge
2.1 ALTO clients can connect to any server and that first server
will fetch the data (similar to an iterative DNS query) on behalf
of the client, based on some kind of inter-ALTO-server
request forwarding protocol
2.2 ALTO clients can connect to any server and that first server
will redirect the client to the "right" ALTO server that has the
desired information, based on some kind of inter-ALTO-server
authority information exchange protocol
2.3 ALTO clients need to use some kind of "search engine" that
indexes ALTO servers and redirects and/or gives cached results
2.4 ALTO clients need to use an external discovery mechanism (e.g.
based on a DHT or on DNS) to discover the ALTO server that has
the desired information
My opinion is that for a small scenario with only a rather limited
number of federated domains, approach 1.1 should be sufficient. No
need to standardize anything here.
For a true Internet-scale scenario (e.g., the P2P use case), I do not
like the 1.? approaches, and I think that 2.4 is more realistic, for
reasons that I already outlined in this post:
http://www.ietf.org/mail-archive/web/alto/current/msg02547.html
One possible solution that follows the 2.4 approach is the xdom-disc
draft (currently expired, I'm working on a new version).
Thanks
Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
