Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 1 Jul 2013 10:20:28 +0100

Rich,

Comments inline, sorry they are a little late.

On 20 Jun 2013, at 08:45, Richard Alimi wrote:

> [ We would like to hear feedback on this.  We are planning to revise and submit a new version ASAP, so please voice opinions on this within the next few days, by Monday, June 24th. ]
> 
> Background:
> 
> Today, the ALTO protocol as a 'version tag' to indicate which version of a network map is used by a particular cost map.
> 
> In a particularly simple case, a single ALTO server is served by a single hostname (or IP address, whatever), and it exposes a single network map and one or more cost maps.  There is no ambiguity here - a client automatically knows that any version tag refers to the single network map that is hosted by the server.
> 
> There are two alternate scenarios where ambiguities arrive:
> 
> (Scenario 1) An IRD hosted by alto.isp1.example.com refers cost maps provided by some third-party, say alto.third-party.example.com.  In this scenario, do version tags exposed by alto.third-party.example.com correspond to the network map provided by alto.isp1.example.com?
> 
> (Scenario 2) A single ALTO server (single hostname) wishes to provide two different network maps (say, different levels of aggregation) and wants to provide cost maps for each of them.  Currently, the version tag accompanying a cost map is not sufficient for a client to determine which network map a particular cost map is based on.

I think these two scenarios should be treated separately as they're separate problems - they may both be solved by the same solution but I wouldn't want us to stall the document because we can't agree on a solution for one of them. I've only considered scenario 2 in my response.

> Proposal:
> 
> To resolve these problems, we'd like to propose a simple change to the version tag accompanying the cost map - it would now include the URI to the network map in addition to an opaque ID.

I don;t like the idea of using a URI as it introduces a high level of coupling - the component generating the cost map needs to know the public facing URI that the client used to access the component that generated the network map. That may be cumbersome as the component generating the cost map may not even know the URI it was accessed through.

Instead, can we specify that instead of a URI the server sends an opaque 'name' for the map. In the IRD and network map it would include the appropriate name and the cost map would have the map-name and map-vtag so a client can associated a cost map with a set of network maps to determine which one is the right one?

(Using a name doesn't prevent people using URIs it just means you cannot rely on it being a URI, which shouldn't matter as you are only using the URI currently as an identifier for comparison) 

Ben

> Compared to the current approach we have in draft -16 (which is for a version tag to be consistent within resources served by the same hostname), this has the following advantages:
> - It provides a more flexible solution to Scenario 1

> - It allows us to handle Scenario 2
> 
> An possible addition to this approach would be explicitly declare the dependency between the cost map and the network map in the IRD.
> 
> Feedback would be great.  The editors believe this would be a strong improvement to the draft.
> 
> Thanks,
> Rich
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Richard Alimi <[email-masked]>
Date: Mon, 1 Jul 2013 08:29:19 -0700

On Sun, Jun 30, 2013 at 11:43 PM, Richard Alimi <[email-masked]> wrote:

>
> On Mon, Jun 24, 2013 at 12:19 PM, Scharf, Michael (Michael) <
> [email-masked]> wrote:
>
>> I agree that in particular scenario 2 is relevant and should be addressed.
>>
>> Like Sabine, I wonder how a client would actually deal with two different
>> network maps if we don't provide any hint in the IRD (probably IRD entries
>> can be entirely optional if there is only one network map). Should the
>> client query all candidate cost maps in that case?
>>
>
> One possibility would be to first grab for the desired cost map, and then
> retrieve the network map it depends on.  There is a potential loss in
> efficiency since the client could fetch the network map and cost map in
> parallel.
>
> This seems to point in favor of listing the dependency explicitly in the
> IRD, and I'm okay with that.  IIRC, Richard Yang was in favor of this as
> well.
>
> All that said, I was sitting down to write the text, and it turns out to
> be a bit tricky.  In particular, when one specifies the URI for the network
> map in the "refers-to" attribute, which URI is it?  Is it the exact same
> URI present in the Network Map's entry in the IRD, or is it some canonical
> (absolute) URI for that Network Map resource?  If the former, then those
> URIs may be relative and this doesn't handle Scenario 1 very well.  If the
> latter, then the ALTO Server generating the IRD has to know the series of
> redirects that the client may experience (since the client may get relative
> URIs for each Information Resource, and Section 5 of RFC3986 indicates that
> the result of the relative -> absolute conversion may be dependent on
> redirects that were followed).  These solutions get to be kind of ugly.
>
> Two ideas come to mind for what we can do:
> (1) Give each Information Resource a UUID, and refer to the dependencies
> by UUID instead of a URI.
> (2) Consider the addition of metadata to the IRD to declare dependencies
> to be an extension (but we must still change Version Tags to declare the
> URI for the Network Map in the base protocol).
>
> I do think this is a nice-to-have optimization, but I don't think its
> strictly necessary to satisfy this use case.  I could be persuaded either
> way.
>
> [ The change to the Version Tags ends up being straightforward, since the
> server specifies all of them explicitly and can enforce that a single
> Network Map URI be returned; there is no ambiguity introduced by relative
> URIs in that case. ]
>

Thinking about this some more, even changing the Version Tag to have a
unique name (e.g., a UUID) instead of the Network Map URI would be quite a
bit cleaner.

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?
Thanks,
Rich

>
>
>> For what it is worth, at first sight, an alternative to the proposed
>> "refers-to" solution on slide 8 of the interim meeting slide deck would be
>> an extended IRD entry for each network map:
>>
>>        {
>>          "uri" : "http://alto.example.com/networkmap1",
>>          "media-type" : "application/alto-networkmap+json",
>>          "used-by": {
>>            "http://alto.example.com/costmap/num/routingcost_lowres"
>>          }
>>        },
>>        {
>>          "uri" : "http://alto.example.com/networkmap2",
>>          "media-type" : "application/alto-networkmap+json",
>>          "used-by": {
>>            "http://alto.example.com/costmap/num/routingcost_highres"
>>          }
>>        },
>>
>> One motivation for that syntax would be to better explain the differences
>> between the several network maps. I don't have any strong preference,
>> though.
>>
>>
> Interesting idea.  I'm trying to think about what would be more natural
> from an implementation standpoint.  If I were writing a client, I think I
> would primarily be interested in the cost map, and then I would need to
> figure out which Network Map is required to interpret that Cost Map.  From
> that standpoint, it seems like listing the dependency along with the Cost
> Map seems more natural.  I have a slight preference for the "refers-to"
> approach but beyond what I just mentioned I don't have any strong technical
> reasons.
>
>
>> Another potential solution would be to define network map capabilities
>> (such as "resolution" for scenario 2). Has this been discussed already?
>> That approach alone might not solve scenario 1.
>>
>>
> I don't think the notion of network map capabilities has been discussed
> yet, but given that we need to finish up the protocol ASAP, perhaps that
> could be an extension?
>
>
>>
>> Finally, after having re-read some parts of -16, I wonder if some
>> sections implicitly assume that there is only a single network map (notable
>> exception: Section 6.3). For instance:
>>
>> "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."
>>
>> "It" is a little bit unclear to me. More explicit would be something like
>> "An ALTO server MUST provide at least one network map."
>>
>
> Yes - agreed. We'll adjust the text here.  Thanks for pointing this out.
>
> Thanks!
> Rich
>
>
>>
>> Best regards
>>
>> Michael
>>
>>
>>
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]] On
>> > Behalf Of Richard Alimi
>> > Sent: Thursday, June 20, 2013 9:45 AM
>> > To: [email-masked]
>> > Subject: [alto] Clarifying Cost Map Dependencies on a Network Map
>> >
>> > [ We would like to hear feedback on this.  We are planning to
>> > revise and submit a new version ASAP, so please voice
>> > opinions on this within the next few days, by Monday, June 24th. ]
>> >
>> > Background:
>> >
>> > Today, the ALTO protocol as a 'version tag' to indicate which
>> > version of a network map is used by a particular cost map.
>> >
>> > In a particularly simple case, a single ALTO server is served
>> > by a single hostname (or IP address, whatever), and it
>> > exposes a single network map and one or more cost maps.
>> > There is no ambiguity here - a client automatically knows
>> > that any version tag refers to the single network map that is
>> > hosted by the server.
>> >
>> > (Scenario 1) An IRD hosted by alto.isp1.example.com refers
>> > cost maps provided by some third-party, say
>> > alto.third-party.example.com.  In this scenario, do version
>> > tags exposed by alto.third-party.example.com correspond to
>> > the network map provided by alto.isp1.example.com?
>> >
>> > (Scenario 2) A single ALTO server (single hostname) wishes to
>> > provide two different network maps (say, different levels of
>> > aggregation) and wants to provide cost maps for each of them.
>> >  Currently, the version tag accompanying a cost map is not
>> > sufficient for a client to determine which network map a
>> > particular cost map is based on.
>> >
>> > Proposal:
>> >
>> > To resolve these problems, we'd like to propose a simple
>> > change to the version tag accompanying the cost map - it
>> > would now include the URI to the network map in addition to
>> > an opaque ID.
>> >
>> > OLD (what we have now):
>> >
>> > {
>> >  "meta" : {},
>> >  "data" : {
>> >    "cost-type" : {"cost-mode"  : "numerical",
>> >                   "cost-metric": "routingcost"},
>> >    "map-vtag"  : "1266506139",
>> >    "map" : {
>> >      "PID1": { "PID1": 1,  "PID2": 5,  "PID3": 10 },
>> >      "PID2": { "PID1": 5,  "PID2": 1,  "PID3": 15 },
>> >      "PID3": { "PID1": 20, "PID2": 15  }
>> >    }
>> >  }
>> > }
>> >
>> > NEW PROPOSAL:
>> >
>> > {
>> >  "meta" : {},
>> >  "data" : {
>> >    "cost-type" : {"cost-mode"  : "numerical",
>> >                   "cost-metric": "routingcost"},
>> >    "network-map" : {
>> >      "uri": "http://alto.example.com/networkmap1"
>> >      "vtag": "1266506139"
>> >
>> >
>> >      }
>> >    "map" : {
>> >      "PID1": { "PID1": 1,  "PID2": 5,  "PID3": 10 },
>> >      "PID2": { "PID1": 5,  "PID2": 1,  "PID3": 15 },
>> >      "PID3": { "PID1": 20, "PID2": 15  }
>> >    }
>> >  }
>> > }
>> >
>> > Compared to the current approach we have in draft -16 (which
>> > is for a version tag to be consistent within resources served
>> > by the same hostname), this has the following advantages:
>> > An possible addition to this approach would be explicitly
>> > declare the dependency between the cost map and the network
>> > map in the IRD.
>> >

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 1 Jul 2013 14:34:51 -0400

On Mon, Jul 1, 2013 at 11:29 AM, Richard Alimi <[email-masked]> wrote:

>
>
> On Sun, Jun 30, 2013 at 11:43 PM, Richard Alimi <[email-masked]>wrote:
>
>>
>>> Like Sabine, I wonder how a client would actually deal with two
>>> different network maps if we don't provide any hint in the IRD (probably
>>> IRD entries can be entirely optional if there is only one network map).
>>> Should the client query all candidate cost maps in that case?
>>>
>>
>     JSONString tag;  // opaque identifier that changes with the version
> (as we have today)
>   } VersionTag;
>
> How does this sound?
>

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?

Thanks.

Richard

>>> One motivation for that syntax would be to better explain the
>>> differences between the several network maps. I don't have any strong
>>> preference, though.
>>>
>>>
>>> "It" is a little bit unclear to me. More explicit would be something
>>> like "An ALTO server MUST provide at least one network map."
>>>
>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 1 Jul 2013 21:01:06 +0100

Rich & Richard,

> Thinking about this some more, even changing the Version Tag to have a unique name (e.g., a UUID) instead of the Network Map URI would be quite a bit cleaner.
> 
> (2) Define the 'refers-to' attribute which identifies the Information Resource on which it depends by its UUID
>     JSONString tag;  // opaque identifier that changes with the version (as we have today)
>   } VersionTag;
> 
> How does this sound?

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.
  
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.

Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 1 Jul 2013 17:25:36 -0400

On Mon, Jul 1, 2013 at 4:01 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> 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.
>
>
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.

> > 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?
>
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?

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?

Richard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 2 Jul 2013 07:37:43 +0100

Richard,

> On Mon, Jul 1, 2013 at 4:01 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> 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.

> 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.

> 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.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Wed, 3 Jul 2013 23:22:16 -0700

On Mon, Jul 1, 2013 at 11:34 AM, Y. Richard Yang <[email-masked]> wrote:

>>> One possibility would be to first grab for the desired cost map, and
>>> then retrieve the network map it depends on.  There is a potential loss in
>>> [ The change to the Version Tags ends up being straightforward, since
>>> the server specifies all of them explicitly and can enforce that a single
> 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

Presumably the IRD that pointed the user at
costmapserver.alto.example.comwould have listed the UUID for that
network map as one of its other
resource entries.

If the ALTO Client arrived at costmapserver.alto.example.com without any
other knowledge of other maps, then I'm not sure there is much we can do.
 That seems to be a problematic deployment scenario with the ALTO Server
Discovery pointing to the wrong place.  In fact, i think this would violate
the requirement that the Network Map must be provided since the ALTO Client
wasn't given a path to locate it.

---

From: Richard Alimi <[email-masked]>
Date: Wed, 3 Jul 2013 23:29:12 -0700

On Mon, Jul 1, 2013 at 11:37 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> > BN:Why do we have to force a UUID? What value does that add? An opaque
> > 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.

> will be from network map name/ID to URI. Is this what you have in mind?

I was thinking something simpler (without the need for another lookup
table) - for each resource entry, we just add an 'id' attribute.

>
> > 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 should be able to
rely on cached information here, right?

Rich

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 5 Jul 2013 23:19:04 -0400

On Thu, Jul 4, 2013 at 2:29 AM, Richard Alimi <[email-masked]> wrote:

>
> On Mon, Jul 1, 2013 at 11:37 PM, Ben Niven-Jenkins <
> [email-masked]> wrote:
>
>> Richard,
>>
>> 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.
>>
>
>> 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?
>> >

This works for me too, and I like this approach better.

> 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
>>
>>
>

---

From: Richard Alimi <[email-masked]>
Date: Fri, 5 Jul 2013 20:51:34 -0700

On Fri, Jul 5, 2013 at 8:19 PM, Y. Richard Yang <[email-masked]> wrote:

>>> > > (2) Define the 'refers-to' attribute which identifies the
>>> Information Resource on which it depends by its UUID
>>> > The disadvantage is that the design in -16 has only one-way links,
>>> from IRD to individual resources only. Individual resources cannot use the

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

   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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 6 Jul 2013 00:27:51 -0400

On Fri, Jul 5, 2013 at 11:51 PM, Richard Alimi <[email-masked]> wrote:

>>>> > 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.
>>>> >
>>>> >
>>>> > > A quick question on a potential scenario. Suppose a client fetches
>>>> a cost map (say costmapserver.alto.example.com), and hence obtains the
>>>> > 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.
>>>>
>>>
>> 1) master.alto.example.com provides an IRD which defines a resource
>> entry of network map, but redirects costmap to another server
>> 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
> 10.1.1 <http://tools.ietf.org/html/draft-ietf-alto-protocol-16#section-10.1.1>.  Network Map
>
>
> 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'.

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

---

From: Richard Alimi <[email-masked]>
Date: Sat, 6 Jul 2013 10:19:46 -0700

On Fri, Jul 5, 2013 at 9:27 PM, Y. Richard Yang <[email-masked]> wrote:

>>> On Thu, Jul 4, 2013 at 2:29 AM, Richard Alimi <[email-masked]>wrote:
>>>
>>>>
>>>>> > 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,
>>>>> 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?
>>>>> >
>>>>> 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.
>>>>>
>>>>
>> 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

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.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 7 Jul 2013 11:39:00 +0100

Rich & Richard,

On 6 Jul 2013, at 18:19, Richard Alimi wrote:
> RY: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'.
> 
> RA: 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:
> 
> - easier for a client to "correct" itself if it somehow discovered an IRD with the cost map
> 
> - 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.

The difference is that both the networkmap-generator and the costmap-generator have to deterministically produce the same Version Tag for the same map input/generation, they don't need to know anything about each other, so version tag generation can be loosely coupled. Backlinks require the generator to know which (of possibly many) URIs it was called from and therefore which backlink to use and are therefore more tightly coupled. 
 
> 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.
> 
> 
> RY: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. 

I'm struggling to see the problem and wonder if you are over thinking it.

There is no requirement to get one map before the other. The IRD entries and the network & cost maps themselves each contain the map "id" (along with a map-vtag in the maps themselves) so network & cost maps can be used in unison.

How the client determines how to get maps is up to the client. The 'normal' process would be to retrieve an IRD that points at both and follow the links. 

The links in the IRD may redirect to another server on the same or a different domain. The client needs a policy for how to determine it if trusts a cost-map with the same id/vtag as a network-map from a different server. Whether it's followed the link from the IRD or discovered the link some other way doesn't really matter, the client still needs to decide whether to use the cost-map in unison with the network-map obtained from a different source (or server).

I don't think the protocol specification should go down the rat hole of specifying exactly what scenarios should lead the client to trust the cost-map  actually contains the right costs for the network-map the client has. At most it should note the implications in the security considerations sections and note some simple advice e.g. apply a same origin policy (RFC6454) unless the client has some other mechanism to trust the cost-map is the true cost-map associated with the network-map the client has (user configuration, client has some other trust relationship with the network map & cost map providers/servers, etc).

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 7 Jul 2013 11:40:40 +0100

Rich,

On 4 Jul 2013, at 07:29, Richard Alimi wrote:
> On Mon, Jul 1, 2013 at 11:37 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> I was thinking something simpler (without the need for another lookup table) - for each resource entry, we just add an 'id' attribute.

I think we're saying the same thing (when I replied to Richard I was working from memory and forget "meta" applies to the whole IRD), what I'm thinking is that an existing entry of:

"resources" : [
      {
        "uri" : "http://alto.example.com/networkmap",
        "media-type" : "application/alto-networkmap+json"
      }, {
        "uri" : "http://alto.example.com/costmap/num/routingcost",
        "media-type" : "application/alto-costmap+json",
        "capabilities" : {
          "cost-type-names" : [ "num-routing" ]
        }
      }]

would become:

"resources" : [
      {
        "uri" : "http://alto.example.com/networkmap",
        "media-type" : "application/alto-networkmap+json",
        "id" : "default-map"
      }, {
        "uri" : "http://alto.example.com/costmap/num/routingcost",
        "media-type" : "application/alto-costmap+json",
        "id" : "default-map",
        "capabilities" : {
          "cost-type-names" : [ "num-routing" ]
        }
      }]

Which I think is the same as what you are suggesting.

Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Jul 2013 14:52:42 -0400

On Sun, Jul 7, 2013 at 6:39 AM, Ben Niven-Jenkins
<[email-masked]>wrote:

> > 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'.
> >
> > RA: 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:
> >
> [BN] The difference is that both the networkmap-generator and the
> costmap-generator have to deterministically produce the same Version Tag
> for the same map input/generation, they don't need to know anything about
> each other, so version tag generation can be loosely coupled. Backlinks
> require the generator to know which (of possibly many) URIs it was called
> from and therefore which backlink to use and are therefore more tightly
> coupled.

Interesting point that networkmap and costmap can be generated in different
servers, as long as they are consistent. In other words, the VTAG
generation must be deterministic from a given network.

The scenario that I have in mind, which I assumed to be more typical, is
that a control server computes a topology from the base network topology,
extracts the nodes as the network map, and computes the pairwise cost
(attributes) as the cost map.

I agree with the comment on backlinks at the cost map.

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Jul 2013 15:03:31 -0400

> table) - for each resource entry, we just add an 'id' attribute.
Just to confirm. The ID is for the resource, not the dependent resource. I
feel that this is more consistent.

> I think we're saying the same thing (when I replied to Richard I was
> working from memory and forget "meta" applies to the whole IRD), what I'm
> thinking is that an existing entry of:
>
> "resources" : [
>       {

If we make the consistent usage that each resource has an id, then the line
right above will be:

"id": "default-costmap"

Overall, I support that we add an "id" field for each resource entry. I
would also like to add a "uses" attribute, just as a software package
system will do. Hence, the preceding example becomes:

"resources" : [
      {
        "uri" : "http://alto.example.com/networkmap",
        "media-type" : "application/alto-networkmap+json",
        "id" : "default-networkmap"
      }, {
        "uri" : "http://alto.example.com/costmap/num/routingcost",
        "media-type" : "application/alto-costmap+json",
        "id" : "default-costmap",
        "uses": ["default-map"]
        "capabilities" : {
          "cost-type-names" : [ "num-routing" ]
        }
      }]

For the content of each individual resource, we include both the id and
version tag, as Rich's earlier proposal. In other words, now costmap can
also have version tags. The use case that I am thinking is that
applications can build on top of cost maps, and hence can know if the cost
map has changed from the previous version fetched.

Richard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Jul 2013 22:22:57 +0100

Richard,

On 9 Jul 2013, at 19:52, "Y. Richard Yang" <[email-masked]> wrote:

> 
> 
> 
> On Sun, Jul 7, 2013 at 6:39 AM, Ben Niven-Jenkins <[email-masked]> wrote:
>> Rich & Richard,
>> 
>> [BN] The difference is that both the networkmap-generator and the costmap-generator have to deterministically produce the same Version Tag for the same map input/generation, they don't need to know anything about each other, so version tag generation can be loosely coupled. Backlinks require the generator to know which (of possibly many) URIs it was called from and therefore which backlink to use and are therefore more tightly coupled.
> 
> Interesting point that networkmap and costmap can be generated in different servers, as long as they are consistent. In other words, the VTAG generation must be deterministic from a given network.
> 
> The scenario that I have in mind, which I assumed to be more typical, is that a control server computes a topology from the base network topology, extracts the nodes as the network map, and computes the pairwise cost (attributes) as the cost map. 

Even if a single server is calculating both the network & cost maps then you are likely to have multiple servers for resiliency or due to demand load and might put them behind a load balancer. Because the network map and cost map are retrieved via separate requests you cannot guarantee both requests hit the same backend server (e.g. Because a server may fail or be removed from the load balancer pool) so you need to be able to deterministically generate vtags across different servers even for your use case I think. 

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Jul 2013 22:35:47 +0100

Richard,

On 9 Jul 2013, at 20:03, "Y. Richard Yang" <[email-masked]> wrote:

> 
> On Sun, Jul 7, 2013 at 6:40 AM, Ben Niven-Jenkins <[email-masked]> wrote:
>> Rich,
>> 
> Just to confirm. The ID is for the resource, not the dependent resource.

I don't know what this means. 

> I feel that this is more consistent.
>  
> If we make the consistent usage that each resource has an id, then the line right above will be:
> 
> "id": "default-costmap"
> 
> 
> Overall, I support that we add an "id" field for each resource entry. I would also like to add a "uses" attribute, just as a software package system will do.

Ah I think I see what you mean. Let's take a step back as we may be heading off on a tangent. 

The original problem was how to "link" a cost map to a network map in the presence of multiple choices. Therefore the IRD entry for the cost map (and the cost map itself) needs to include an identifier for the network map it is associated with and the IRD entry for the associated network map (and the network map itself) needs to include the same identifier. 

If you want to call the property in the cost map/IRD map something other than id to make the different semantics clear (it is identifying the associated network map and is not the identifier of the cost map itself) I'm OK with that. 

Introducing an identifier for each resource may make the entries look more "consistent" but it's not clear to me how (or whether) they'd be used. If folks think it's worthwhile I won't object but keeping things simple helps keep the usage clear. 

Ben
> Hence, the preceding example becomes:
> 
> "resources" : [
>       {
> For the content of each individual resource, we include both the id and version tag, as Rich's earlier proposal. In other words, now costmap can also have version tags. The use case that I am thinking is that applications can build on top of cost maps, and hence can know if the cost map has changed from the previous version fetched.
> 
> Richard
> 
> 
> 
> 
>  
>>         "capabilities" : {

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Jul 2013 17:41:35 -0400

On Tue, Jul 9, 2013 at 5:22 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

>
> [BN] Even if a single server is calculating both the network & cost maps
> then you are likely to have multiple servers for resiliency or due to
> demand load and might put them behind a load balancer. Because the network
> map and cost map are retrieved via separate requests you cannot guarantee
> both requests hit the same backend server (e.g. Because a server may fail
> or be removed from the load balancer pool) so you need to be able to
> deterministically generate vtags across different servers even for your use
> case I think.
>
>
Agree that different requests can hit different servers, and I interpret
"deterministically" as the following:

two network maps have the same vtag => they are the same map

Note that the preceding condition allows some usage of random variables;
for example, in the case of only a master who computes the vtag, and the
other load balancers are just data/storage servers, then the master can use
random variables, or nonce...

Of course, the preceding is internal implementation. We just need to
specify the semantics, as the preceding "deterministically" mean. Agree?

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Jul 2013 17:48:54 -0400

Hi Ben,

On Tue, Jul 9, 2013 at 5:35 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> On Sun, Jul 7, 2013 at 6:40 AM, Ben Niven-Jenkins <[email-masked]
> > wrote:
>
>> Rich,
>>
> system will do.
> The original problem was how to "link" a cost map to a network map in the
> presence of multiple choices. Therefore the IRD entry for the cost map (and
> the cost map itself) needs to include an identifier for the network map it
> is associated with and the IRD entry for the associated network map (and
> the network map itself) needs to include the same identifier.
>
> If you want to call the property in the cost map/IRD map something other
> than id to make the different semantics clear (it is identifying the
> associated network map and is not the identifier of the cost map itself)
> I'm OK with that.
>
>
Good to know that you are OK with this. Let's proceed this way then.

> Introducing an identifier for each resource may make the entries look more
> "consistent" but it's not clear to me how (or whether) they'd be used. If
> folks think it's worthwhile I won't object but keeping things simple helps
> keep the usage clear.
>

One usage that I have in mind is that later, when we build up more
services, for example, on top of cost map, then the application or
higher-level service can use the costmap id to identify the costmap that
serves as the base.

More specifically, one item that I am working on is topology service and
even make ALTO as a base for actions. For example, an app fetches a
topology, and computes a route. When the app submits the request to
instantiate the route, the app should identify the map used (by using both
id and vtag) so that the network can retrieve the corresponding topology.

At this moment, we can take down the path of allowing every resource entry
with an id, but if an id is not used, it may not need to appear. How does
this sound?

Richard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Jul 2013 23:16:42 +0100

Agreed. Ben

On 9 Jul 2013, at 22:41, "Y. Richard Yang" <[email-masked]> wrote:

> 
> On Tue, Jul 9, 2013 at 5:22 PM, Ben Niven-Jenkins <[email-masked]> wrote:
>> 
>> [BN] Even if a single server is calculating both the network & cost maps then you are likely to have multiple servers for resiliency or due to demand load and might put them behind a load balancer. Because the network map and cost map are retrieved via separate requests you cannot guarantee both requests hit the same backend server (e.g. Because a server may fail or be removed from the load balancer pool) so you need to be able to deterministically generate vtags across different servers even for your use case I think. 
> 
> Agree that different requests can hit different servers, and I interpret "deterministically" as the following:
> 
> Note that the preceding condition allows some usage of random variables; for example, in the case of only a master who computes the vtag, and the other load balancers are just data/storage servers, then the master can use random variables, or nonce...
> 
> Of course, the preceding is internal implementation. We just need to specify the semantics, as the preceding "deterministically" mean. Agree?
> 
> Richard
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Jul 2013 23:22:13 +0100

Richard

On 9 Jul 2013, at 22:48, "Y. Richard Yang" <[email-masked]> wrote:
> One usage that I have in mind is that later, when we build up more services, for example, on top of cost map, then the application or higher-level service can use the costmap id to identify the costmap that serves as the base.
> 
> More specifically, one item that I am working on is topology service and even make ALTO as a base for actions. For example, an app fetches a topology, and computes a route. When the app submits the request to instantiate the route, the app should identify the map used (by using both id and vtag) so that the network can retrieve the corresponding topology.

The app may need to identify the map used but why does it need to identify the cost map separately to the network map?

Ben

>  
> 
> At this moment, we can take down the path of allowing every resource entry with an id, but if an id is not used, it may not need to appear. How does this sound?
> 
> Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 9 Jul 2013 19:11:44 -0400

Hi Ben,

On Tuesday, July 9, 2013, Ben Niven-Jenkins wrote:

> Richard
>
> On 9 Jul 2013, at 22:48, "Y. Richard Yang" <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
>
>
>
>> Introducing an identifier for each resource may make the entries look
>> more "consistent" but it's not clear to me how (or whether) they'd be used.
>> If folks think it's worthwhile I won't object but keeping things simple
>> helps keep the usage clear.
>>
>
> The app may need to identify the map used but why does it need to identify
> the cost map separately to the network map?
>

Good question. Let me elaborate more. The use case is that the network
gives an app a topology to allow the app to choose paths according to
the app's policy. Different apps/users can be given different abstract
topologies, due to access control and simplification considerations. Assume
a base network G0. The service provider transforms the base network to
obtain an abstract network topology. One of the transformation primitives
is to add virtual links. For example, there is no link between A and B, but
the ALTO server adds a virtual link from A to B representing a path
A->C-E->B, which can be implemented using a tunnel. The server deletes the
physical links A->C, C->E, and E->B. Given its abstract topology, the app
chooses paths for its origin-destination pairs. As an example, the app
may chose a path that uses the A-B link in the topology that it is
given. Another app may also be given a virtual A->B link, but this virtual
link is for a different path. Hence, when the network gets a route request
that contains the A->B link, the network needs to know the cost map to map
back to physical links to implement the request. Each abstract topology can
have different nodes and different links. Given that the current
ALTO encodes the node (network) map used by the (link) cost map, the app
only needs to identify the topology (link map), which points to the
corresponding node map. To summarize, app identifies the cost (link) map is
enough, and no need for including the network (node) map, as you pointed
out. Does this clarify or become more confusing?

Richard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Jul 2013 08:53:24 +0100

Richard,

On 10 Jul 2013, at 00:11, Y. Richard Yang wrote:

> RY: Good question. Let me elaborate more.

If I understood your elaboration, you have multiple cost maps associated with a single network map and you want to be able to distinguish between the different cost maps for identification purposes, which isn't a case I'd considered but seems reasonable.

Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 10 Jul 2013 09:31:13 -0400

Hi Ben,

On Wednesday, July 10, 2013, Ben Niven-Jenkins wrote:

> > The app may need to identify the map used but why does it need to
> identify the cost map separately to the network map?
> >
> If I understood your elaboration, you have multiple cost maps associated
> with a single network map and you want to be able to distinguish between
> the different cost maps for identification purposes, which isn't a case I'd
> considered but seems reasonable.

Yes. I am writing up something and then definitely want to get more
feedback from you.

Thanks!

Richard