Subject: [alto] Endpoint property service, network maps and the PID property

From: Wendy Roome <[email-masked]>
Date: Fri, 26 Jul 2013 08:35:35 -0400

Two questions. First, must an endpoint property service depend on a
network map?  That is, can a server define one that doesn't "use" a
network map?  After all, except for the PID, endpoint properties are tied
to the endpoint address, not the network map.

Second, "{10.3.1} Endpoint Property" says:

"If an ALTO Server provides one or more Endpoint Property resources, then
at least one MUST provide the ¹pid¹ property."

What if there are several network maps? If a server provides that service
for one map, must it provide that for every map?

One possible restatement is,

"If an ALTO Server provides one or more Endpoint Property resources that
depend on a specific network map, then at least one of those resources
MUST provide the ¹pid¹ property for that network map."

Another possibility is just drop that requirement altogether, and let the
server decide if it wants to offer the "pid" property.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 26 Jul 2013 14:20:53 -0400

Hi Wendy,

> to the endpoint address, not the network map.

Agree with your assessment. It depends on the property. Some examples not
tied to a network map are Metered or not, subscribed bw, or rack number in
a previous DC example.
> server decide if it wants to offer the "pid" property.

Good observation. The requirement of adding pid came from a previous
review. Suppose we keep the requirement. I see your observed problem of
multiple network maps, and if the request specifies only pid, which network
map. Given that we will likely (1) require at least one network map, (2)
specify one as default, then the response to a pid property query returns
the result based on the default map. We should allow the pid query to
include the resource id of a specific network map to handle the general
case. Does this address the problem?

Thanks!
Richard
>
>         - Wendy Roome
>
>
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Wendy Roome <[email-masked]>
Date: Fri, 26 Jul 2013 15:04:35 -0400

Richard,

That would work, although adding a "network map resource ID" parameter to
the EPS resource begs the question of why  doesn’t a filtered cost map
resource have a similar parameter, as opposed to being bound to a specific
network map.

How about the following alternative: encode the network map name into the
property name. Eg,

     "pid"   means the endpoint's PID in the default network map (iff one is
defined)
     "pid.network-map-resource-id" means return the endpoint's PID in that
network map (iff it exists)

A complication is that EPS must return the vtag when it returns a pid
property, and it can only return one vtag for all pid properties. One
solution is to restrict each EPS request to PIDs from a single network map.
That's not elegant, but it's simple, and I don't think it would be a
hardship for any client.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Fri, July 26, 2013 14:20
To:  Wendy Roome <[email-masked]>
Cc:  IETF ALTO <[email-masked]>
Subject:  Re: [alto] Endpoint property service, network maps and the PID
property

Hi Wendy,

Agree with your assessment. It depends on the property. Some examples not
tied to a network map are Metered or not, subscribed bw, or rack number in a
previous DC example.
> server decide if it wants to offer the "pid" property.

Good observation. The requirement of adding pid came from a previous review.
Suppose we keep the requirement. I see your observed problem of multiple
network maps, and if the request specifies only pid, which network map.
Given that we will likely (1) require at least one network map, (2) specify
one as default, then the response to a pid property query returns the result
based on the default map. We should allow the pid query to include the
resource id of a specific network map to handle the general case. Does this
address the problem?

Thanks!
Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 26 Jul 2013 16:32:50 -0400

Hi Wendy,

Your cases do point out that it can be a better, more general solution that
filtering/some end point properties can include the resource id(s) in the
input parameter to indicate the base/scope.

Regarding the encoding pid.network-map-resource-id, its syntax is not
conventional, because the operator "." typically is not used in this way,
and hence could be confusing.

Richard
On Jul 26, 2013 3:04 PM, "Wendy Roome" <[email-masked]> wrote:

>      "pid"   means the endpoint's PID in the default network map (iff one
> is defined)

---

From: Richard Alimi <[email-masked]>
Date: Sun, 28 Jul 2013 11:02:32 -0700

An alternative would be to use the dependency mechanism in the IRD. Then,
if an ALTO Server provides two endpoint property services, it can
explicitly define which network map the endpoint property service is for
without needing resource IDs to be query parameters filled in by the client.

On Fri, Jul 26, 2013 at 1:32 PM, Y. Richard Yang <[email-masked]> wrote:

> Hi Wendy,
>
> Your cases do point out that it can be a better, more general solution
> that filtering/some end point properties can include the resource id(s) in
> the input parameter to indicate the base/scope.
>
>>      "pid.network-map-resource-id" means return the endpoint's PID in
>> that network map (iff it exists)
>>