| 59 | === Community Agreement from the meeting === |
| 60 | The session concluded with community agreement on three points: |
| 61 | - GENI stitching will follow the described architecture |
| 62 | - Details will be worked out |
| 63 | - Next steps as outlined below |
| 64 | |
| 65 | === Next steps === |
| 66 | - Schema: Jon Duerig of ProtoGENI is iterating on a PG-compatible stitching schema that preserves ION compatibility. |
| 67 | - Functions: The community will continue discussion points as described below, particularly working out how chain & tree interoperate, and working though some use cases. |
| 68 | - API to be proposed for adoption at GEC11 |
| 69 | - Interoperability demonstration at GEC12 |
| 70 | |
| 71 | === Selected points from the discussions === |
| 72 | - Don't make use of all functions mandatory |
| 73 | - Functions are not necessarily new architectural boxes |
| 74 | - Tom suggested some functions could have an implementation which exists as a central GENI service (eg Topology Service), available to all for use as desired. Although use would not required. |
| 75 | - The architecture should not force CFs to redo work they've already done |
| 76 | - We must support both chain and tree workflows |
| 77 | - can they work together? Is 1 a subset of the other, modulo security? |
| 78 | - How much direct negotiation between aggregates is required: this adds complexity, but without VLAN translation may be necessary |
| 79 | - How prevalent should we expect translation to be? do we optimize for it? |
| 80 | - Work out some use cases. For example, make sure a large topology that loops back (A -> B -> A) is explicitly worked through as an example and supported. |
| 81 | - Updating of information in the topology service is a question: keeping it up to date is hard, but 'static' data may change very often |
| 82 | - perhaps support both a push&pull AM auto-update mechanism? |
| 83 | - At the high level of this discussion, all speakers expressed their support for this effort and basic design |
| 84 | |