On Thu, Jul 4, 2013 at 2:29 AM, Richard Alimi <[email protected]> wrote:
> > On Mon, Jul 1, 2013 at 11:37 PM, Ben Niven-Jenkins < > [email protected]> wrote: > >> Richard, >> >> > On Mon, Jul 1, 2013 at 4:01 PM, Ben Niven-Jenkins < >> [email protected]> wrote: >> > > Unless there are objections, I'll do the following: >> > > (1) Give each Information Resource an 'id' attribute which is a UUID >> > > (2) Define the 'refers-to' attribute which identifies the Information >> Resource on which it depends by its UUID >> > > (3) Define Version Tag to be: >> > > object { >> > > JSONString id; // UUID of the network map >> > > JSONString tag; // opaque identifier that changes with the >> version (as we have today) >> > > } VersionTag; >> > > >> > > How does this sound? >> > >> > BN:Why do we have to force a UUID? What value does that add? An opaque >> sequence of bytes (restrict it to string if you like) is sufficient IMO as >> the only think you are using it for is comparison. A string would allow >> alto maps to be named & configured easily by humans. >> > >> > >> > RY:For comparison to be effective, we need some kind of uniqueness of >> the ID, and uniqueness of ID should be defined in a domain (name space, >> scope). UUID implies uniqueness globally, in any name space, and hence >> unique in each specific domain. >> > My understanding is that you feel that this might be a too strong >> sufficient condition. In which scope should the opaque map id be unique >> then? URI, DNS names are the potential name space that comes to mind to >> define a scope. >> >> We don't need to ensure global uniqueness IMO, all that is required is >> all components that generate a particular network map and associated cost >> map use a consistent name/identifier. Even with UUIDs there needs to be a >> level of co-ordination between the different components to ensure they use >> the same UUID. If we use an opaque string there is nothing to stop folks >> using UUIDs as their names, we're just not forcing folks to do that which >> leaves flexibility to enable scenarios where UUIDs may be cumbersome. >> > > I'm fine with just relaxing it to be an opaque ID. I used UUID out of > simplicity, but I agree it doesn't need to be globally unique. > > >> >> >> > On 1 Jul 2013, at 19:34, Y. Richard Yang wrote: >> > > A quick question on a potential scenario. Suppose a client fetches a >> cost map (say costmapserver.alto.example.com), and hence obtains the >> UUID of the network map. How does the client map the UUID to where to fetch >> the network map, which might be hosted at networkmap.alto.example.com? >> > >> > To be useful you'd have to list the map name as part of the IRD entry >> for the network & cost maps. >> > >> > >> > So it will be an item defined in "meta" of the IRD. Similar to current >> "cost-types", which defines mapping of names to cost types, this mapping >> will be from network map name/ID to URI. Is this what you have in mind? >> >> Basically, yes. >> > > I was thinking something simpler (without the need for another lookup > table) - for each resource entry, we just add an 'id' attribute. > > This works for me too, and I like this approach better. > >> > The disadvantage is that the design in -16 has only one-way links, from >> IRD to individual resources only. Individual resources cannot use the >> cost-type names defined in IRD. Hence, a client can work, even without >> knowing the IRD. Imagine that IRD is hosted on a meta-data server, and >> individual resources are hosted on data servers. Then, if the meta-server >> is down, the client using -16 can still proceed. The new dependency on IRD >> to provide the mapping then requires that we provide a mechanism so that a >> client can always find the IRD, and the IRD server is always available. >> Will this be a problem or we feel comfortable with it? >> >> I'm not sure I see the problem. The IRD contains the map-name/id in the >> entries for the network-map and cost-map. The cost map and the network map >> both contain the network maps's name and the vtag. >> >> If the IRD is unavailable/nonexistent the client must have got the URIs >> for the network & cost map from somewhere and it can compare the names & >> vtags. >> > > I'd agree with Ben here. The ALTO Client must have the URIs for the > individual maps in this case (presumably from the IRD), and it would have > retrieved the IDs for those maps in that same IRD. > It could be from a different IRD. Imagine the following scenario: 1) master.alto.example.com provides an IRD which defines a resource entry of network map, but redirects costmap to another server costmap.alto.example.com (which lists only IRD as the resource type). 2) costmap.alto.example.com lists multiple cost maps based on the same network map. Client retrieving IRD of costmap.alto.example.com will not find the id of the network map, as this server does not provide the network map. This may sound contrived, but some SDN designs uses such an approach: storing topology in one server, and more dynamic data on a different server (scheme). The new design then would not allow such a deployment. Do I miss anything here? Richard > It should be able to rely on cached information here, right? > > Rich > > >> >> Ben >> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
