Subject: [alto] Starting the ALTO extension discussion

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Nov 2013 13:45:08 -0600

Folks:

Enrico and I have put together some thoughts on how to direct our
energies into making sense of the ALTO extensions so we can reasonably
differentiate the extensions that are possible with the current base
ALTO protocol from those that may require an updated charter.

Here is the general extension taxonomy without resorting to listing each
extension draft; we hope this will guide the list discussions.

- Pub/sub (asynchronous notification) extension.

- Incremental updates. (Nominally, this is a subset of pub/sub, but the
   exact format for the incremental update needs to be agreed upon.  At
   hand are two methods to do incremental updates, one is using JSon
   Patch [RFC6902] and the other is through an ALTO-specific patch
   extension [draft-schwan-alto-incr-updates-02]).

- Property extensions (endpoint property and PID property) to aid in
   representing network attachments in terms other than IP addresses.
   For instance, the current charter notes that geographical distance
   could be used as network preference.  The extension related to
   VPN expresses network attachment points in terms of a geolocated
   URL.

- Topology based decision model extensions: moving from a "single
   node" network model to an topology model featuring link and node
   abstractions to facilitate end point and path selection guidance.

- Cost metric extensions: moving beyond the base "routingcost" metric.

We think that the above five buckets subsume most of the mature
extension drafts that we saw presented at Vancouver and before that,
Berlin and Orlando.

The first three extensions are fairly easy to reason about.  The first
two are agreed upon by many, and the third one (property extension) can,
we believe, be supported through the ALTO address type registry
mechanism defined in the base draft (http://tools.ietf.org/html/draft-
ietf-alto-protocol-20#section-14.4). The discussion we expect to have
on the list regarding property extension is whether the registry fits
our needs or whether we need to do something more.

Similarly, we believe we generally know what we want from the topology
reasoning extension, but we should discuss the exact nature of this on
the list.  For example, do we want to represent links and transit points
in a multi-switch topology?  What sort of graph transformations to raw
network information do we intend to apply?  It will not suffice to say
simply that we intend to do so, we need to be more granular now and say
*how* we intend to do so.

Regarding the cost metrics, in draft-wu-alto-te-metrics, there are
certain cost metrics like delay, delayjitter and pktloss, that do not
need the WG to do anything special beyond documenting these in an I-D,
having an Expert Review before IANA adds these to the ALTO Cost metric
registry (c.f. http://tools.ietf.org/html/draft-ietf-alto-protocol-
20#section-14.2).  No extensions needed here.

However, in the same draft (draft-wu-...) there are other metrics like
maxbw and maxreservbw that define a new ALTO object type.  We would need
to figure out how to handle this new type, especially since it requires
an update to the filtering mechanism.  It is, at the very least, worth
having a discussion on the list on what type (if any) extension
mechanism would be needed here.

We will like to start a larger dialogue in the working group to
determine the next steps in the direction of moving ALTO ahead.

Proponents of individual extensions should note:

   1. Where in the above taxonomy their extension fits in.
   2. Whether the base protocol supports the said extension?
      a. If yes, what is needed to get the extension moving, i.e.,
         consensus on list that the extension is of importance,
         an expert review required (see Section 14 of the ALTO
         protocol).  Maybe we term these as "simple" extensions.
      b. If no, gather consensus on the mailing list for these
         "complex" extension and determine how to approach a
         solutin space.

As was mentioned in the Vancouver meeting, the working group interest
in extensions and the capability of a core set of people to commit to
seeing the extensions through will inform what extensions can now
proceed as the base protocol matures.

So, let's go at it and see where we arrive before the London IETF.

Thanks,

Vijay K. Gurbani and Enrico Marocco

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 18 Nov 2013 16:47:38 -0500

Hi Vijay, Enrico,

Thanks for posting the thoughts on ALTO extensions! Should we reply to this
email, or start a separate thread for each extension to answer the
questions?

Richard

On Mon, Nov 18, 2013 at 2:45 PM, Vijay K. Gurbani <[email-masked]> wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Nov 2013 16:34:36 -0600

On 11/18/2013 03:47 PM, Y. Richard Yang wrote:
> Hi Vijay, Enrico,
>
> Thanks for posting the thoughts on ALTO extensions! Should we reply to
> this email, or start a separate thread for each extension to answer the
> questions?

Richard: Good question; I am not sure what will work.

Let's do this --- we have a broad taxonomy into four categories
(I am assuming that incremental updates falls as a sub-category under
pub/sub).

So go ahead and open up a thread for the category of your interest.

We'll see how far we go.

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-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 21 Nov 2013 10:20:23 -0800

Hi all interested in ALTO topology extensions. I've been trying to
organize the topology
enhancements along some themes to better enable requirements analysis. 
Here is a first cut via a tentative
abstract for an update to the topology framework draft:

*Abstract*
This document is concerned with ALTO topology extensions needed to
model: (a) additional network imposed constraints such as link
bandwidth, (b) furnish additional information to satisfy application
resilience or policy requirements, and  (c) furnish guidance in the case
where the network can furnish multiple paths between sources and
destinations.

Exposing additional topology information of networks to applications and
users beyond that of the current ALTO protocol can enable many important
existing and emerging use cases, and many network providers already
provide additional information about their networks. At the same time,
there is no standard for exposing network topology in a manner that
provides simplification via abstraction to the application layer and
information hiding via abstraction to the network provider. In this
document, we derive topology enhancement requirements, provide a
framework including processes and information models for delivering
enhanced topology information, and furnish some possible information
encodings to establish scalability and processing bounds.

For (a) we've got examples from the large bandwidth use-case draft.  For
(b) in the resilience area we are thinking about "shared fate" concepts
such as SRLGs and such suitably abstracted. For (b) in the policy areas
we were thinking about information related to geo-political requirements
on data transit and such. Finally for (c) we are thinking about VPN,
SDNs and those circuit like technologies.

Let me know if you find this breakdown helpful, have other examples, or
if we missed something.
Cheers

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237