On Fri, Jul 5, 2013 at 9:27 PM, Y. Richard Yang <[email protected]> wrote:
> > > On Fri, Jul 5, 2013 at 11:51 PM, Richard Alimi <[email protected]> wrote: > >> >> 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? >> >> The exact requirement will be: > If a Server s provides a cost map c, then its IRD must provide the network > map used by c, to avoid the case that s provides a network map n, but c > uses network map n'. > I tend to think its okay if the a particular IRD provides only the cost map but not link back to the network map. I see the tradeoffs as the following: Advantages of having a link to the network map (in addition to its ID): - easier for a client to "correct" itself if it somehow discovered an IRD with the cost map Disadvantages of having a link to the network map (in addition to its ID): - server is responsible for keeping track of back-references and redundant information (as you point out) In general, I'm in favor of reducing the coupling as much as possible, though admittedly a cost map and network map are coupled already by a Version Tag. Would it be reasonable to allow an IRD entry for a Cost map to optionally point back to an IRD containing the network map? The advantage to pointing back to the IRD (and not the network map itself) would be that any metadata attached to the network map resource entry (such as media types) would also be discovered by the client, and that IRD could also provide info for a filtered network map. > This discussion reminds me about the foundation of RESTful thinking: the > visit of web pages is stateful, and hence there are requirements that a > client should not visit URI u2 before it visits URI u1, if u1 provides > background for u2. An "eager" client may jump (bookmark) to u2, and hence > may get confused when encountering terms defined in u1. A "more friendly" > page u2 will provide a link back to u1, but at the risk of introducing > redundancy. The approach of always using IRD is to require that each > "reader" must know the ToC or index page. > > Richard > > > >> 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
