On Fri, Jul 5, 2013 at 8:19 PM, Y. Richard Yang <[email protected]> wrote:
> > 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? > We have a requirement in the draft that an ALTO Server must provide a network map: 10.1.1 <http://tools.ietf.org/html/draft-ietf-alto-protocol-16#section-10.1.1>. Network Map The Network Map Information Resource lists for each PID, the network locations (endpoints) within the PID. It MUST be provided by an ALTO Server. ALTO Server is defined as (in RFC2693): ALTO Server: A logical entity that provides interfaces to the queries to the ALTO service. The ALTO Server discovery draft documents how a client figures out the URI for an IRD. Thus, the above requirements taken together I believe mean that the resulting IRD has to provide (or link to) a network map. Thus, in the example above, the ALTO Client would have learned about master.alto.example.com first (which linked to the network map). If the client learned about costmap.alto.example.com via the discovery protocol and that IRD didn't have any link to a network map, then I don't believe that this "ALTO Server" complies with the requirements. Does that sound reasonable? Rich > > 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
