Re: [alto] extension questions and comments

["Reinaldo Penno (repenno)" <[e-mail]>]

Inline

From: "Y. Yang" <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 28, 2013 8:50 PM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>
Cc: Greg Bernstein <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [alto] extension questions and comments


On Mon, Oct 28, 2013 at 1:54 PM, Reinaldo Penno (repenno) <[e-mail]<mailto:[e-mail]>> wrote:
I also think seedorf-lmap is a very interesting draft.


Share the opinion. It is quite interesting indeed! At a first quick look, it defines another set of metrics (http://data.fcc.gov/download/measuring-broadband-america/2013/Technical-Appendix-feb-2013.pdf Page 26, which the te-metrics doc may need to look into as well).

It looks like that the draft is still evolving. I can see several possibilities in defining network maps: one is the geo-location already well defined in the draft; Table 5 of the Technical-Appendix-feb-2013.pdf suggests that many maps can be constructed. This is interesting and also shows that we will need to think more on how to handle a wealth of such information. Good work!

But what I'm most interested in a way to make maps writable.  I want an app to be be able to write to a map therefore influencing its own cost and attributes.

In the particular fcc MBA context, a concrete example is to change the subscriber tier (end point property). But since you mentioned map, I guess you are saying e2e (e.g.,  more narrowly bounded app flow).

[RP] hummm…Not necessarily e2e. If I write to a map and change the cost of reaching  the IP address associated with my application,  I need to be put in a different PID.  I believe the same is true for endpoint properties if you want to actually influence the cost map.

In addition to flow meta data, Lingli pointed out OneAPI in the context of mobile devices as another related work: http://www.gsma.com/oneapi/faq/restful-api-specifications

[RP] My impression is that a lot of the oneapi is already encapsulated by Android and iPhone SDKs.  There is also http://cordova.apache.org which IMO is extremely interesting. Of course, you know, Javascript is like the Borg.

Richard


From: Greg Bernstein <[e-mail]<mailto:[e-mail]>>
Date: Monday, October 28, 2013 10:48 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [alto] extension questions and comments

Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( , here are some questions/comments.
These comments/questions are from the perspective of creating an ALTO topology service (suitable for large bandwidth and SDN applications).

http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01
ALTO for VPNs: Way back when we started talking about "topology" like extensions. The concept of ALTO for "controlled or partially controlled" environments was floated. It seems that a VPN type of service would be the exemplar of such an environment and hence pave the way for "restricted environment" use of ALTO.  Questions:  Are there specific additions to the REST API to offer this some kind of security, i.e., to keep others from gaining information about a customers VPN? Or would a general approach to security of this interface be specified?
http://tools.ietf.org/html/draft-song-alto-overlay-routing-00
Extensions for Multiple path choices: In our large bandwidth work we considered both path representations as well as graph representations. This proposal would extend ALTO by reporting costs on multiple possible paths between a source and destination. Hence could also work for the large bandwidth case with appropriate extensions.  Both in this draft and the VPN draft, we may have the situation where the client uses ALTO information to not only make a choice but then relay that choice back to the network via some type of "reservation interface".
http://tools.ietf.org/html/draft-wu-alto-te-metrics-00
Defines costs metrics based on OSPF-TE. We would need for such metrics for the "general" topology service.
http://tools.ietf.org/html/draft-roome-alto-pid-properties-00
PID properties -- Comments: This is a step on the way to a "NID" that we would use in a graph topology (multi-switch) representation, i.e., where we'd define a Node with Id and properties.
http://tools.ietf.org/html/draft-seedorf-lmap-alto-02, http://tools.ietf.org/html/draft-seedorf-cdni-fci-alto-00
Very interesting applications. Any interest from the authors of these drafts in bandwidth/topology type information?

Best Regards

Greg B.


On 10/22/2013 1:02 PM, Vijay K. Gurbani wrote:
Folks: As you prepare slides, etc. for your ALTO extensions, please
consult the latest institutional memory on how to taxonomize or classify
the extensions; this was captured rather succinctly and successfully
during the Berlin IETF side meeting [1].

Enrico and I will be looking to see how we can group the various
extensions under this ontology.  It will make it tractable to understand
and appreciate the extensions as we grapple with them.

Thanks,

[1] http://www.ietf.org/proceedings/87/minutes/minutes-87-alto#ad-hoc

- vijay



--
===================================================
Dr Greg Bernstein, Grotto Networking [phone]<tel:%28510%29%20573-2237>

_______________________________________________
alto mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/alto




--
--
 =====================================
| Y. Richard Yang <[e-mail]<mailto:[e-mail]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================