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

From: Wendy Roome <[email-masked]>
Date: Mon, 29 Jul 2013 11:01:46 -0400

That works, but would other properties offered by that resource also
depend on the network map? For example, suppose two different EPS
resources, using different network maps, both return the "foo" property.
Would they necessarily return the same value for the same endpoint? Or
could the values be different?

I think the first interpretation is cleaner. So if an EPS resource returns
the "pid" property, it MUST depend on a network map. If an EPS resource
does not return "pid", it may or may not depend on a network map.

Conceptually that would mean there are N+1 spaces of property names: one
for each network map, plus one for "independent" properties.

Another approach would be to say to say except for "pid", properties are
independent of network maps. That would mean that an EPS resource that
returns "pid" MUST depend on a network map, and MUST NOT return any other
property. An EPS resource that does not return the "pid" property MUST NOT
depend on a network map.

I think either alternative is workable, but I think both are a little
messier than using "pid.network-map-id".

	- Wendy Roome

>
>Date: Sun, 28 Jul 2013 11:02:32 -0700
>From: Richard Alimi <[email-masked]>
>Subject: Re: [alto] Endpoint property service,	network maps and the
>	PID property
>
>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.
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 29 Jul 2013 13:58:21 -0400

Wendy,

On Monday, July 29, 2013, Wendy Roome wrote:

> I think the first interpretation is cleaner.

Agree that they should be the same.

> So if an EPS resource returns
Let me say a little bit more on my thinking. Personally, I feel that adding
the dependent
resource id as a parameter in the query is more general and flexible.

- For pid, if there are multiple network maps, and the client does want to
specify a network
map that is not the default, the query includes the network map id.
Thinking about your
syntax a bit more, I am starting to feel better, and can justify it, if we
do some reverse (see below):

In particular, I try to draw analogy with SQL syntax. Assume two tables
named netmap1 and netmap2,
in a DB, both with schema (ip, pid). It is ok to write:

select netmap1.pid
from netmap1
where netmap1.ip == query_ip

Note that SQL adds "from" to provide a default name space. Hence, one may
skip the first and third netmap1 in the preceding example.

Hence, I see the following analogy in endpoint property query (see
10.3.1.6):

{
  "properties": [ netmap1.pid, "example-prop"],
   "endpoints": [ "ipv4:128.1.1.1", "ipv4:136.1.1.1"]
}

with analogy that "properties" specifies the select clause, with
"example-property" in a global table; "endpoints" specifies the where
clause. Note that SQL writes tablename.attr, not the other way -:)

Now, consider the "funny" case of

  "properties": [netmap1.pid, netmap2.pid, "example-prop"]

This could theoretically happen as well unless we forbid it.

Now consider the response of the query. The current response can encounter
problems, for example two map-vtags. We encounter this problem because we
want to return the vtag, which is not specified in a SQL syntax. To make
full analogy with SQL, the client should not return the versions, but
we consider a meta reply that always indicate the vtag of used tables.
Hence, I see a response:

  "data" : {
      "vtags" : { "netmap1": "1266506239", "netmap2":"124657657"},
      "map" : {
           "ipv4:128.1.1.1": { netmap1.pid: "PID1", netmap2.pid: "pid3",
"example-prop" : " 1"
       }
   }

Note that we can still specify "uses" with analogy as the SQL "from"
semantics, to indicate the resources used. If there is a uses, the client
is limited to use only the specified resources, still achieving sharding.

- We can work out the details on filtered network and cost maps.

What do you think?

Richard

> >From: Richard Alimi <[email-masked] <javascript:;>>
> _______________________________________________
> alto mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 29 Jul 2013 17:05:57 -0400

Let's nail down some more on the details on what end point properties,
filtered network map and filtered cost map may look like, if we use the SQL
syntax/semantics as guide lines.

** End point properties:

IRD:
===
 "netmap1" : // network map

 "netmap2" : // network map

 "netmap3" : // network map

"endpoint-property",

    "uri" : "http://alto.example.com/endpointprop/lookup",
    "media-type" : "application/alto-endpointprop+json",
    "accepts" : "application/alto-endpointpropparams+json",
    "capabilities" : {
             "prop-types" : [ "pid", "example-prop" ]
    },
    "uses": [ "netmap1", "netmap2" ]  // query will have SQL equivalent of
                                      // using three tables in "from":

                                      // netmap1, netmap2, epp_global

 // there could be one entry with uses "netmap3"

}

Endpoint property query:
===================

 POST /endpointprop/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: 96
  Content-Type: application/alto-endpointpropparams+json
  Accept: application/alto-endpointprop+json,application/alto-error+json

  {
    "properties" : [ "netmap1.pid", "netmap2.pid", "example-prop" ],
    "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ]

}

Response:
========

  HTTP/1.1 200 OK
  Content-Length: TBA
  Content-Type: application/alto-endpointprop+json

  {
    "meta" : {

    },
    "data": {
      "map" : {
        "ipv4:192.0.2.34"    : { "netmap1.pid" : "PID1",
                                 "netmap2.pid" : "pidx",
                                 "example-prop": "1" },
        "ipv4:203.0.113.129" : { "netmap1.pid" : "PID3"

                                 "netmap2.pid" : "pidx"}

      }
    }
  }

** Filtered Network Map

IRD:
===
  "netmap1" :

  "netmap2" : ...

  "netmap3" :

 "filtered-network-map": {
         "uri" : "http://custom.alto.example.com/networkmap/filtered",
         "media-type" : "application/alto-networkmap+json",
         "accepts" : "application/alto-networkmapfilter+json",

         "uses" : ["netmap1", "netmap3"] // can select from 2 network tables

 }

Indicates that the URI can filter two network maps: "netmap1" and "netmap3".

Query:
=====

POST /networkmap/filtered HTTP/1.1
   Host: custom.alto.example.com
   Content-Length: TBA
   Content-Type: application/alto-networkmapfilter+json
   Accept: application/alto-networkmap+json,application/alto-error+json

   {
     "netmap1.pid": [ "PID1", "PID2" ]

}

Note that I changed "pids" to pid in the line right above to be consistent
with SQL syntax.

Note that I do not see value of filtering on two networks (which general
SQL syntax can allow, but I do not see value.) In particular, should we
support generic SQL syntax, the query could be:

   {
     "netmap1.pid": [ "PID1", "PID2" ],

     "netmap2.pid": [ "pidx" ]

}

Response (one network map filtering only):
========

  HTTP/1.1 200 OK
   Content-Length: TBA
   Content-Type: application/alto-networkmap+json

   {
     "meta" : {

       "vtags" : { "netmap1" : 1266506139 },

     },
     "data" : {
       "map" : {
         "PID1" : {    // no need to write netmap1.PID1
           "ipv4" : [
             "192.0.2.0/24",
             "198.51.100.0/24"
           ]
         },
         "PID2" : {
           "ipv4": [
             "198.51.100.128/24"
           ]
         }
       }
     }
   }

** Filtered Cost Map

IRD:

"filtered-cost-map" : {
         "uri" : "http://custom.alto.example.com/costmap/filtered",
         "media-type" : "application/alto-costmap+json",
         "accepts" : "application/alto-costmapfilter+json",
         "capabilities" : {
           "cost-constraints" : true,
           "cost-type-names" : [ "num-routing", "num-hop",
                                 "ord-routing", "ord-hop" ]
         },
         "uses": [ "netmap1", "netmap2" ]

Semantics: it can query filtered cost map for network map based on either
netmap1 or netmap2, for 4 cost type names

Query (limit to filter on one network map):
=====

   POST /costmap/filtered HTTP/1.1
   Host: custom.alto.example.com
   Content-Type: application/alto-costmapfilter+json
   Accept: application/alto-costmap+json,application/alto-error+json

   {
     "cost-type" : {"cost-mode": "numerical",
                    "cost-metric": "routingcost"},
     "netmap1.pid" : {   // if it is netmap2.pid, it will be based on netmap2
       "srcs" : [ "PID1" ],
       "dsts" : [ "PID1", "PID2", "PID3" ]
     }
   }

Response:
========

  HTTP/1.1 200 OK
   Content-Length: TBA
   Content-Type: application/alto-costmap+json

   {
     "meta" : {

       "cost-type": {"cost-mode" : "numerical",
                     "cost-metric" : "routingcost"},
       "vtags" : {
         "netmap1": "1266506139"
       },

      },

     "data" : {
       "map" : {
         "PID1": { "PID1": 0,  "PID2": 1,  "PID3": 2 }
       }
     }
   }

Do they address all problems? Are they necessary?

Richard

---

From: Richard Alimi <[email-masked]>
Date: Mon, 29 Jul 2013 23:17:32 -0700

My personal opinion when looking at these options is that we're making it
too complicated in the base protocol, and going past the point of fixing
bugs. Apologies for not being able to make it to the session on Monday, but
I personally would prefer the IRD to be more verbose and just have each
filtered cost map or endpoint property service be allowed to specify at
most one network map.  Would it then be reasonable to treat optimizations
(such as querying across multiple network maps, and reducing number of
entries in the IRD) as extensions?

On Mon, Jul 29, 2013 at 2:05 PM, Y. Richard Yang <[email-masked]> wrote:

> [email-masked]

---

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

The examples show that we have two options:

1. Limit "uses" to one network map for end point properties, filtered
network map, and filtered cost map;

2. Allow "uses" to include multiple network maps for the preceding case,
and allow <network-map-id>.pid notation in
    - "properties" of end point property query,
    - the queried PIDs in network and cost map filtering,
    - response in end point property.

You are right on that the notation can then allow querying cross network
maps, e.g., in hierarchical topology.

My personal vote is to go the second path, setting the path for general SQL
syntax and semantics, and the complexity appears to be reasonable, to me. I
am willing to go along 1 as well if others prefer it.

Richard

On Tuesday, July 30, 2013, Richard Alimi wrote:

> On Mon, Jul 29, 2013 at 2:05 PM, Y. Richard Yang <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> Note that I changed "pids" to pid in the line right above to be
>> consistent with SQL syntax.
>>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>