Hi Ben, On Tue, Jul 23, 2013 at 7:03 PM, Ben Niven-Jenkins <[email protected]>wrote:
> Richard, Colleagues, > > On 23 Jul 2013, at 18:39, Y. Richard Yang wrote: > > > Hi Vijay, > > > > Let me try to summarize your proposed strategy: > > > > Syntax > > ===== > > For the root IRD (the one discovered from the discovery protocol) > obtained by a client, if there are *more than one* network map resources > listed in the IRD, one and only one of the network maps MUST be marked with > a "default" attribute. > > > > Footnotes: (1) in the general case, an IRD may have 0 network maps > (e.g., only endpoint properties); (2) consider the deployment cases where > the ALTO Service provides multiple "orthogonal" network maps (i.e. harder > to argue which one is more "default" than the other, the IRD can choose to > mark one as default. > > I can't help but wonder if you're over-thinking this. > > Clearly I am trying to think over whether we should introduce the default attribute :-) > As I see it clients that are only expecting a single network map need a > mechanism to decide which network map to use. A default name provides that > purpose. For clients that are expecting multiple maps, the default name is > really just like any other map name - the client knows which maps it is > interested in and retrieves them accordingly. For ALTO services that are > offering multiple maps where no default makes sense then clients that only > handle a single map aren't going to be able to make use of that ALTO > service anyway so it doesn't matter. > Good summary of the cases. The complexity is the last case: multiple network maps and not clear which one should be marked as the default. The "agony" was that we still require that the operator mark one network map as default, if we introduce default, which can then become operational confusing. By thinking it through, we plan to add a sentence to indicate that when such a case happens, the marking is essentially irrelevant, as you suggested. Thanks! Richard > > Do we need anything more complex than putting the above into better words? > > Ben > > > > > > Q: should we change "more than one" to "at least one" in the preceding? > If not, the interpretation is that when only one network map, it has a > default attribute automatically marked. > > > > Semantics > > ======== > > 1. If a client uses only network map as guidance for traffic > localization, it should use the default network map, as the default > behavior; > > > > 2. If a client uses both network map and cost map, it should use the > "routingcost" cost map based on the default network map, as the default > behavior. > > > > Q: what if there are multiple "routingcost" cost maps based on the same > network map? I would say Forbidden. > > > > Is this what you have in mind? > > > > Richard > > > > > > On Mon, Jul 22, 2013 at 7:14 PM, Vijay K. Gurbani <[email protected]> > wrote: > > On 07/19/2013 06:10 PM, Y. Richard Yang wrote: > > > Hi Wendy, > > > > > > Personally, I prefer that we do not limit to one network map per IRD, > > > because I see use cases where multiple network maps are more natural. > [...] > > > > Richard, Wendy: This has been an invigorating discussion. > > > > I believe that the semantics in -17 are quite flexible and allow us to > > represent one or more network maps in an IRD. This is all good. > > > > I believe what is missing in -17 is the notion of a default network > > map, which will allow a client to stay simple if it does not want to > > deal with the complexity of understanding multiple maps by following the > > delegation URL or even the complexity of handling multiple network > > map resources in the same IRD. > > > > Let me be more clear. > > > > From early on, ALTO has assumed that an IRD provides a network map and > > one or more cost maps. It was also implicitly assumed that the cost > > maps referenced the network map that was received in the IRD. This was > > a simple and effective model. The IRD could be generated dynamically > > after HTTP-digesting a client so as to provide a different view to a > > different client, or the IRD could be generated by traversing an > > acyclic dependency graph [1] where network maps are modeled as > > vertices with out-degree of 0 (leaf) and cost maps are modeled as > > vertices with at an out-degree of at least 1 (non-leaf) [1]. > > > > But regardless how you derive an IRD, the sacrosanct assumption was > > that the IRD contained a network map and one or more cost maps. We now > > have a situation where there may be multiple network maps, either in > > the same IRD or through delegation, and cost maps that refer to > > different network maps. > > > > Opinions have been expressed that the client becomes complex or that > > the server becomes complex since the costs have to be cross-referenced > > to the appropriate network map. No doubt, there is additional > > complexity that needs to be understood in sufficient detail to deliver > > the protocol document to the IESG in short time. > > > > I believe that a reasonable way to tame the complexity while allowing > > for future flexibility is to designate one network map in the parent > > IRD as the default network map. (As a definition of the parent IRD, I > > mean the IRD that is obtained through the ALTO server discovery > > process.) I note that S8.5.3 of -17 contains a resource whose id is > > "default-network-map", but this is different than *choosing* one > > resource that is the *authoritative* default network map. Today, this > > normative text is missing from the draft; there is nothing in the text > > that names a network map in the IRD as a default map. > > > > Perhaps an attribute could be assigned to such a network map to > > indicate its usage as a default network map, or perhaps we can choose > > to represent the default network map with a reserved id. Either method > > is fine as long as there is normative text in the draft that ensures > > the existence of a single network map that is considered the default > > network map. > > > > Why is the notion of this default network map so important? Well, it > > allows for simpler clients. Clients that choose not to deal with the > > complexity of multiple network maps spread out in different subdomains > > (delegation) simply look for the default network map in the parent > > IRD and apply the mandatory 'routingcost' cost metric to the default > > network map. Clients that are prepared to deal with additional > > complexity can do so by supporting multiple network maps spread out in > > different subdomains (delegation). > > > > One can argue that the ALTO server is forced to deal with simple > > clients by ensuring that a reasonable default network map and a cost > > map corresponding to it are always available. But that is not a new > > onus on the ALTO server, it always did that. > > > > In summary, it seems to me that we can easily support multiple network > > maps through one IRD semantic as well as allow the latent notion that > > an IRD contains an authoritative network map simply by designating a > > default network map more explicitly. This allows clients to stay > > simple if they desire and does not add any additional burden on the > > server beyond providing one network map and one cost map as it has > > always done. > > > > Thoughts? > > > > [1] http://www.ietf.org/mail-archive/web/alto/current/msg02054.html > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > > Email: vkg@{bell-labs.com,acm.org} / [email protected] > > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq > > > > _______________________________________________ > > alto mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
