On 01/25/2014 10:45 PM, Y. Richard Yang wrote:
How about give different milestones to different items, with some later
milestones? The chairs enforce more strictly the deadlines.

For a recharter to be successful, we need to understand in sufficient
detail what we want to do.  The value proposition of the 7 items [0] is
not under dispute, as is evident by the rather strong show of support
thus far.  (Reinaldo's reticence duly noted and appreciated.)

Let's do a second order analysis on what we expect to have as an
outcome of the work item, "An ALTO format for encoding graphs."
Personally, I think that this is the most intriguing of the lot.

So, in order to ensure a common understanding such that we are
forearmed with answers to the questions we know we will get when
we recharter and assign milestones, let's do a bit of armchair
analysis on the encoding format for graphs.

Consider the following ALTO triangle:


                PID-1
                /   \
              2/     \ 3
              /       \
         PID-2--------PID-3
                  6

Today, ALTO knows the pair-wise cost (i.e., {PID-1,PID2}, {PID-2,PID-3}
and {PID-1,PID-3}) from the cost map.  So if a resource consumer is in
PID-2 and there are two resource producers, one in PID-1 and the second
in PID-3, ALTO will choose the producer in PID-1 because of the low
cost to get to PID-1.

The network map will be encoded as:

   "network-map" : {
     "PID3" : { "ipv4" : [ "0.0.0.0/0" ] },
     "PID1" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
     "PID2" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
   }

and a cost map as:

     "cost-map" : {
       "PID1": { "PID1": 1,  "PID2": 2,  "PID3": 3 },
       "PID2": { "PID1": 2,  "PID2": 1,  "PID3": 6 },
       "PID3": { "PID1": 3,  "PID2": 6  }
     }

Here, by design of the current ALTO protocol, the underlying network
(switches, links) are abstracted behind PIDs.

Issue 7 of the proposed rechartering effort [0] deals with a suitable
format for encoding graphs in ALTO.  My impression is that there
are two distinct capabilities we are looking for: graph
representation and graph transformation.  The representation part
appears easy enough (I think).

Taking some liberties with the syntax, a coarse JSON GML encoding
can be approximated as follows:

graph [
  node [
     id 0
     label "PID-1"
     address-type "ipv4"
     hosts ""192.0.2.0/24, 198.51.100.0/24"
  ]
  node [
     id 1
     label "PID-2"
     address-type "ipv4"
     hosts ""192.0.2.0/25, 192.0.2.128/25"
  ]
  node [
     id 2
     label "PID-3"
     address-type "ipv4"
     hosts "0.0.0.0/0"
  ]
  edge [
     source 0
     target 1
     value  2
     type  "undirected"
  ]
  edge [
     source 0
     target 2
     value  3
     type  "undirected"
  ]
  edge [
     source 1
     target 2
     value  6
     type  "undirected"
  ]
]

Two questions:

1) Is the encoding above close to what we have been calling the
 "multiple-switch" model?  Is something like this encoding one possible
 outcome of a work item related to Issue 7?
2) The harder part is graph transformation.  What sort of algebraic
 formulations do we expect to turn into protocol primitives that will
 allow us to transform graphs as is outlined in Section 4 of [1]?

[0] http://www.ietf.org/mail-archive/web/alto/current/msg02345.html
[1] http://tools.ietf.org/html/draft-yang-alto-topology-00

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

Reply via email to