[alto] Topology enhancement discussion -- Re: Starting the ALTO extension discussion

[Greg Bernstein <[e-mail]>]

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.



On 11/18/2013 11:45 AM, Vijay K. Gurbani wrote:
> 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
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]