Re: [alto] Call for adoption: ALTO traffic engineering cost metrics

[Greg Bernstein]

Support.

Greg B.


On 8/1/2016 2:48 PM, Vijay K. Gurbani wrote:

Folks: As the (draft) minutes [1] of IETF 96 reflect, there was general
consensus on adoption of the ALTO traffic engineering cost metrics
(draft-wu-alto-te-metrics-08) draft as a deliverable towards protocol
extensions to convey a richer set of attributes.

Some concern was expressed on the list about the the privacy aspects
related to sharing some of the metrics.  These metrics remain optional,
and an ALTO server that does not want to provide these is not bound to
do so.

There was also advice from the AD to harmonize this work with the metric
registry work being done in IPPM.

The chairs would like the authors to ensure that the above two items are
reflected in any discussion that arises in the context of adopting this
draft as a working group item.

The call for adoption runs for two weeks, from Mon Aug 1, 2016 to Mon
Aug 15, 2016.  This will be a good time to comment on the list and
inform the working group of any issues with adopting this items, or
whether the working group was remiss in considering other documents.
Please post to the list.  (Even a simple "I support this document
towards charter deliverable" is a good indication.)

Thanks,

[1] https://www.ietf.org/proceedings/96/minutes/minutes-96-alto

- vijay


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Call for adoption: Adopting graph representation format deliverables

[Greg Bernstein]

Support.

Greg B.


On 8/1/2016 2:37 PM, Vijay K. Gurbani wrote:

Folks: As the (draft) minutes [1] of IETF 96 reflect, there was general
consensus on adoption of path vector and routing state abstraction
documents towards the charter deliverable of graph representation
formats in ALTO.

The chairs will like to start a call for adoption of the two documents
--- https://tools.ietf.org/html/draft-yang-alto-path-vector-03 and
https://tools.ietf.org/html/draft-gao-alto-routing-state-abstraction-03
--- as deliverables towards the charter item.

Note that there remains some ambiguity (in the chair's mind) on whether,
once adopted, these will proceed as two drafts or whether they will be
merged in one.  The authors of these drafts are urged to provide
clarity on the evolution of these documents.

The call for adoption runs for two weeks, from Mon Aug 1, 2016 to Mon
Aug 15, 2016.  This will be a good time to comment on the list and
inform the working group of any issues with adopting these items, or
whether the working group was remiss in considering other documents.
Please post to the list.  (Even a simple "I support these documents
towards charter deliverable" is a good indication.)

Thanks,

[1] https://www.ietf.org/proceedings/96/minutes/minutes-96-alto

- vijay


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Topology Use Cases

[Greg Bernstein]

Hi fellow ALTOers. It seems appropriate to revisit the ALTO topology use 
cases in a systematic fashion as it seemed the last time we did this was 
in 2012. In the following I focus on bandwidth considerations, since 
these can introduce mutual constraints among flows and were the original 
motivation for our ALTO topology work.


It seems useful to introduce the concepts of “source-destination” 
/choice/ made by the client and of “path” /choice/ which may or may not 
be supported by the network to help discern various use cases. Let me 
know if this breakdown is helpful. At the end I give a quick 
review/summary of the “path” and “graph” representations.


Cheers

Greg B.


   ALTO Topology Use Cases

1.

   Single or Multiple Paths between a given Source and Destination

1.

   Underlying technology only supports single path at a time
   between source and destination. For example IP, single spanning
   tree ethernet bridging.

2.

   Underlying network supports multiple paths between source and
   destination. For example MPLS, GMPLS, SDN.

1. Provider offers /path choice/ as a service. This is a form
   of /network virtualization/. Emerging SDN scenario.
2.

   Numbers and Choices of Sources and Destinations

1.

   Single source and Single destination
   Bandwidth between source and destination is a well defined
   notion. If network supports path choice then either
   “path-vector” or “graph” representation can be used mutual
   bandwidth constraint information isn’t needed since we only have
   one flow.

2.

   Single source and Multiple destinations simultaneously
   Bandwidth between a single source and multiple destinations is
   not well defined since we can have shared bottlenecks between
   paths. Knowing this information in the case with no path choice
   maybe useful for adjusting sending rates. If given path choice
   one can optimize chosen paths.

3.

   Single source, choice of one or more destinations out of a
   larger pool of destinations.

   This is almost a classic ALTO scenario with additional bandwidth
   information. Does not require mutual constraint information
   since only one flow. In path choice case multiple paths could
   allow for delay vs. bandwidth or other trade offs.

4.

   Multiple sources and Multiple destinations simultaneously

   Like cases 1. and 2. for no path choice. But with path choice
   mutual bandwidth constraints are important for optimization.

5.

   Choices of multiple source-destination pairs from a pool of
   possible sources and destinations.

   Even with no path choice mutual bandwidth information is key to
   the selection of optimum source-destination pairs. In case with
   path-choice we may prefer “graph” representation over
   “path-vector” which may need to furnish an abundance of possible
   paths.

3.

   Choice of Bandwidth Constraint Representation

1.

   “Path-Vector”: here we represent a path between a source and
   destination in terms of a list of “abstract” links. We associate
   bandwidth constraints with this abstract links so that the ALTO
   client can understand the mutual bandwidth constraints between
   paths. In networks where path choice is supported one may need
   give a large number of paths between a given source and
   destination to support good optimization. Note that our use of
   the term “path-vector” is particular to ALTO topology discussions.

2.

   “Graph”: Here we present an “abstraction” of the network in
   terms of nodes and links. With the links having capacity
   constraints. Client would obtain paths based on criteria
   furnished from the network (no path choice) or its own criteria
   (path choice). In the case of path choice the network would be
   responsible for taking a path request and realizing it (network
   virtualization implementation).

3.

   If multiple choices how well does provider understand clients
   application? If very well (or network simple) then lists of
   possible paths with mutual constraints (“path vector”) can be
   sufficient if not very well or the network is very meshy then a
   graph representation is better.

​
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF 96 agenda requests -- Topology extensions

[Greg Bernstein]

Hi Kai I think you make a very important point:

A major concern might be how ALTO can distinguish itself from the 
others.  I think the value of ALTO is that it comes with 
application-layer semantics.
ALTO has already come out with the first standards to bridge the 
application-network divide. It's a good time to enhance it for 
usefulness with a good set of topology (and in my interest bandwidth 
aware) extensions. If we wait too long then ALTO will miss the window to 
provide guidance to an important emerging segment of the networking 
community. Qiao et. al. will be publishing a draft on a protype system 
for big science (LHC) data transfers that makes use of such information 
and their example easily generalizes to other distributed "big data" 
applications. In addition we have applicability within the data center 
and as a key bandwidth/resource aware abstraction mechanism for SDN 
virtual networking services.


Cheers

Greg B.


On 7/7/2016 1:56 AM, Gao Kai wrote:

Hi Richard, Greg and all,

I think in some way, ALTO already has a graph representation.  
Consider the cost mapand the endpoint cost map provided by ECS, they 
are basically fullmesh graphs in the matrix representation, where the 
paths between certain endpoint groups or hosts can be seen as virtual 
links.If we look at the use casessuch as peer/replica selection, they 
can be seen as making "routing" decisions in those overlay graphs.So 
from my perspective, the "topology extensions" are more like the 
efforts to generalize the ALTO protocol.


As Greg has mentioned, there are quite a few works on the 
"topologyextension"and many of us are still looking forward to pushing 
it forwards.I'd very much like to contribute if the WG decides to go 
down the path.


A major concern might be how ALTO can distinguish itself from the 
others.  I think the value of ALTO is that it comes with 
application-layer semantics.  Right now we have endpoints and endpoint 
groups, identified by IP addresses and prefixes, maybe later we can 
have rendez-vous points (capacity regions, shared risk links, etc.), 
relaypoints(caches, NAT, VPN gateways, etc.) and even some NFV nodes.


Regards,
Kai

On 07/07/16 09:52, Y. Richard Yang wrote:

Let me add one note. Please see below.

On Wednesday, July 6, 2016, Y. Richard Yang <y...@cs.yale.edu> wrote:

Greg,

Nice discussion!

On Wednesday, July 6, 2016, Greg Bernstein
<gr...@grotto-networking.com> wrote:

Hi Richard, your coding of the initial design looks fine.
However we did  a lot of work in the past and the effort
within the ALTO WG stalled. This did not seem to be due to
technical disagreements by various draft authors (folks
seemed fairly flexible and in rough consensus), but rather to
the WG not wanting to move in this direction at the time.


My understanding is that other extensions may need to be handled
first. The timing on topology can be right.

I'm not sure what is the best way forward with topology
extensions. Various working group participants have  produced
drafts over the years that clarified the problem statement,
looked at and justified two major "architectural
alternatives", worked on some encoding details, and wrote up
some advanced work (the "A Routing State Abstraction Service
Using Declarative Equivalence" draft) based on the potential
topology extensions.

Before putting in a bunch more time and effort it would be
good to know where the WG wants to go with these extensions.
As we've discussed such extensions are very valuable in the
SDN realm for network virtualization (with flexible network
information disclosure). Either adopting a draft on topology
extensions as a WG document or chartering a design team to
write a series of documents would get my renewed participation.


Network graph is a chartered WG item, and hence is becoming a
higher priority, as other items move forward.

Here is my current thinking/reasoning on topology/routing state
abstraction for application traffic optimization:

1. alto is somehow not allowed to change network state, which
somehow (not fully but quite likely) imply that routing is given;

2. Given that routing is given, what application can do is its
traffic scheduling. Assume that the application has a set of
flows F = {f1, f2, ..., f_|F|}. If routing is given, many
properties (e.g., propagation delay) of flow i are given. What
application is given to control is x1, x2, ..., x_|F|, where xi
is the amount of traffic for flow i. Let x = [x1, ..., x_|F|] be
the vector. Then what application can do is to select the value
of x. Curren ALTO (rfc7285) already can provide the properties of
the routing path of each flow i. The main miss

Re: [alto] IETF 96 agenda requests -- Topology extensions

[Greg Bernstein]

Hi Richard, your coding of the initial design looks fine. However we 
did  a lot of work in the past and the effort within the ALTO WG 
stalled. This did not seem to be due to technical disagreements by 
various draft authors (folks seemed fairly flexible and in rough 
consensus), but rather to the WG not wanting to move in this direction 
at the time.


I'm not sure what is the best way forward with topology extensions. 
Various working group participants have  produced drafts over the years 
that clarified the problem statement, looked at and justified two major 
"architectural alternatives", worked on some encoding details, and wrote 
up some advanced work (the "A Routing State Abstraction Service Using 
Declarative Equivalence" draft) based on the potential topology extensions.


Before putting in a bunch more time and effort it would be good to know 
where the WG wants to go with these extensions. As we've discussed such 
extensions are very valuable in the SDN realm for network virtualization 
(with flexible network information disclosure). Either adopting a draft 
on topology extensions as a WG document or chartering a design team to 
write a series of documents would get my renewed participation.


Cheers

Greg B.


On 7/6/2016 9:52 AM, Y. Richard Yang wrote:

Greg, all,

I read the paper and found it highly relevant, for the convergence of 
our network graph/path vector design. Here, let us start with the 
initial design, before getting into the details of json encoding. Any 
feedback will be greatly appreciated.


- Path-vector request:
  src/dest pairs; and optionally, for each pair, additional hint 
information such as demand, requirement metrics

  Requested properties of network elements

- Path-vector response:
  Path vector for each src/dst pair, where each element in a path 
vector is an abstract network element

  A description of the properties of each network element.

Example:
  Req:
src/dst pairs: {s1 -> d1, demand = 10, latency < 20 ms}, {s2 -> 
d2, ...}

properties: available-bw, cost

  Response:
s1 -> d1: "e1", "e2", ...
...
"e1" properties: available-bw = 10, cost = 3,

...

The preceding does not handle the case of query topology, but I feel 
that path vector, which essentially assumes that routing is given and 
no need to worry about path compressions, is a good, clean start.


Does the preceding missing anything?
Richard

On Tue, Jul 5, 2016 at 1:55 PM, Greg Bernstein 
<gr...@grotto-networking.com <mailto:gr...@grotto-networking.com>> wrote:


Hi all since some of our original Internet Drafts association with
ALTO "topology extensions" our well out of date, those that are
interested may want to look at a technical paper that Young and I
put together back in 2012

(https://urldefense.proofpoint.com/v2/url?u=http-3A__www.grotto-2Dnetworking.com_files_BandwidthConstraintModeling.pdf=CwICAg=-dg2m7zWuuDZ0MUcV7Sdqw=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg=
). This has motivations, concepts, alternative representations and
color highlighted figures to aid in comprehension.  We also have
the short (11 slide) presentation that we gave at the Vancouver
2012 IETF for those that never saw it or need to job their memory.

Cheers

Greg B.


On 7/5/2016 10:27 AM, Vijay K. Gurbani wrote:

On 07/05/2016 12:25 PM, Y. Richard Yang wrote:

Vijay,

Please see inline. [...] OK. We should target posting a
spec by this
Friday so that we can discuss the spec before the meeting,
to remove
any confusion/bewilderment. Since the key piece is encoding
specification of (1) graph; and (2) path vector associated
w/ a
graph. We will target posting those spec, precisely first.


Richard: Awesome!  Thanks.

- vijay


___
alto mailing list
alto@ietf.org <mailto:alto@ietf.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto=CwICAg=-dg2m7zWuuDZ0MUcV7Sdqw=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw=-othJunl7gz_02BM9c1kqLPhFmI2iJr3vD6gu41kd_w=





--
--
 =
| Y. Richard Yang <y...@cs.yale.edu <mailto:y...@cs.yale.edu>>   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>|
 =


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF 96 agenda requests -- Topology extensions

[Greg Bernstein]

Hi all since some of our original Internet Drafts association with ALTO 
"topology extensions" our well out of date, those that are interested 
may want to look at a technical paper that Young and I put together back 
in 2012 
(http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf). 
This has motivations, concepts, alternative representations and color 
highlighted figures to aid in comprehension.  We also have the short (11 
slide) presentation that we gave at the Vancouver 2012 IETF for those 
that never saw it or need to job their memory.


Cheers

Greg B.


On 7/5/2016 10:27 AM, Vijay K. Gurbani wrote:

On 07/05/2016 12:25 PM, Y. Richard Yang wrote:

Vijay,

Please see inline. [...] OK. We should target posting a spec by this
Friday so that we can discuss the spec before the meeting, to remove
any confusion/bewilderment. Since the key piece is encoding
specification of (1) graph; and (2) path vector associated w/ a
graph. We will target posting those spec, precisely first.


Richard: Awesome!  Thanks.

- vijay


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IETF 96 agenda requests

[Greg Bernstein]

Hi Richard and all, for the last few years I've been teaching and 
working in the SDN space and mostly agree with Richard's assessment. The 
only disagreement is with his assessment of "slow" convergence of the 
network graph/(path vector) drafts. These drafts are basically in 
conceptual agreement and have been for quite some time (2012 Vancouver 
meeting). The exact encoding details were not worked out at the time, 
but could be quickly converged based on examples that have been given in 
the more recent drafts.



The applicability of such a feature to SDN virtualized networks 
hopefully should be clear but we can easily add it as another 
application/motivation.


On 7/4/2016 4:06 PM, Y. Richard Yang wrote:

Vijay, Jan, all,

I am replying this email publicly so that all of us can engage more in 
shaping the agenda in about three weeks.


A key item that the WG needs to discuss, in the potentially more 
productive f2f-meeting setting in Berlin, is how the WG should move 
forward. Can we allocate a slot, say at least 20 min, for this discussion?


Besides the general discussions, here are some comments on specific 
agenda items and the mission of the WG:


- Despite the substantial change of the networking landscape, I still 
believe that the foundational services of ALTO are sound: providing 
abstract network information to applications. I believe that this is 
also what many others see ALTO; for example see [1]. The key is what 
we do to go beyond the initial network abstractions.


- The first I see is Endpoint Cost Service (ECS), which is the 
foundation. It provides an interface to allow applications to know the 
routing costs. However, current ALTO is defined pre-SDN, and the 
emerging trend of SDN is going beyond simple destination routing, to 
be more application dependent. Hence, I see that we need to go beyond 
Endpoint Cost Service, to say Flow Cost Service. There is an extension 
draft [2], and I suggest that the WG finishes this to make the ALTO 
protocol complete. Make sense?


-  The next I see is network graph (path vector) abstraction. The more 
I think about it, the more I am convinced that this is the way we go. 
I am an author of the draft and multiple versions are evolving [3, 4, 
5], but we are relatively slow in convergence. I suggest that the WG 
gets a set of active participants to finish this draft, so that we 
have a relatively complete set of ALTO services.


Cheers,
Richard

[1] https://www.opendaylight.org/file/odl-beryllium-diagram02
[2] https://datatracker.ietf.org/doc/draft-wang-alto-ecs-flows/
[3] 
https://datatracker.ietf.org/doc/draft-gao-alto-routing-state-abstraction/

[4] https://tools.ietf.org/html/draft-yang-alto-topology-06
[5] https://tools.ietf.org/html/draft-scharf-alto-topology-00

On Wednesday, June 29, 2016, Vijay K. Gurbani > wrote:


Folks: Please send me and Jan agenda requests for the ALTO WG meeting
in IETF.  We have a 2 hour slot on Thu afternoon (July 21).

Specifically:

  - Presenter name
  - Time requested (in minutes)
  - Internet-Draft to be discussed

As usual, drafts that have seen list discussions will be given
precedence when scheduling the agenda.

As you are all aware, the deployment draft is now with the IESG.
As per our last meeting (virtual interm [1]), we need to move two
drafts ahead: (1) draft-ietf-alto-multi-cost-01 needs to be scheduled
for a WGLC, and (2) draft-randriamasy-alto-cost-calendar-05 needs
to be
open up to being adopted as a WG item.  Jan and I will like to start
proceeding on this perhaps as early as next week.

[1]

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_interim_2015_10_27_alto_minutes_minutes-2Dinterim-2D2015-2Dalto-2D1=CwICAg=-dg2m7zWuuDZ0MUcV7Sdqw=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA=ASHRozEgZvFCzydTsT-P7fLIy1RVC6ciNuTtWDmqNtM=ghe2Ca7B5zd4u_ZWbLeZZ5oexLFxV07x-MYfkipmAk4=

Thank you,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks

1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: v...@bell-labs.com / vijay.gurb...@nokia-bell-labs.com
Web:

https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_=CwICAg=-dg2m7zWuuDZ0MUcV7Sdqw=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA=ASHRozEgZvFCzydTsT-P7fLIy1RVC6ciNuTtWDmqNtM=TgjoQbo9aR1PTVWRY6Ydlw_khODlDN6l8OaFh4fS1ZA=
 | Calendar:

https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq=CwICAg=-dg2m7zWuuDZ0MUcV7Sdqw=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA=ASHRozEgZvFCzydTsT-P7fLIy1RVC6ciNuTtWDmqNtM=1Q7R5p_enzJxoGM_E41qNrEhCWmfOrjLsuv6jL-Sw64=

___
alto mailing list
alto@ietf.org

Re: [alto] A generalization of ALTO abstract path vector

[Greg Bernstein]

Looks interesting. Will review Richard. Here a link to an older writeup 
along similar lines by Young Lee and myself 
http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf.


Best Regards

Greg B.

On 6/29/2015 3:54 PM, Y. Richard Yang wrote:


Dear all,

Some of us worked on a more general foundation for the abstract path 
vector design. In particular, we studied a more general problem called 
routing state abstraction, and proposed a more general framework 
called routing state abstraction based on declarative equivalence. We 
plan to write up a draft to discuss the more general design at IETF 
93. More info on the paper is below. Any comments or feedback will be 
greatly appreciated!


Richard


Title: Routing-State Abstraction Based on Declarative Equivalence

Abstract: Providing abstract views on top of raw network state can 
provide substantial benefits to both the network OS, who manages the 
network state, and the network control applications, who consume the 
network state. In this paper, we conduct the first study to provide 
control applications with access to the routing state, which is a key 
component of the network state. We design a simple, efficient 
algorithm to look up a route query in a flow rule manager (FRM), which 
is a common data structure storing a network's routing state. More 
importantly, we design a simple, novel interface based on a principle 
called declarative equivalence for network control applications to 
query the routing state, and the network OS uses redundancy 
elimination to compute equivalent, but minimal routing state, 
providing the first, novel, systematic algorithm to compute abstract, 
compressed routing state. We implement our design in OpenDaylight and 
show substantial performance benefits.


A link to the paper:
http://www.cs.yale.edu/homes/yry/research/TechReports/GWY15.pdf


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto


​
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Work items for re-chartering

[Greg Bernstein]

Thanks for the detailed references Jan.  I've looked at the Yang network
topo draft and the OpenDaylight JSON format. This is very similar to
what we'd want. Though there are some more items that we'd like
included.  If there is sufficient interest we can put an extended
comparison of models and JSON formats into a draft.

Cheers

Greg
On 1/31/2014 2:48 PM, Jan Medved (jmedved) wrote:
 Network topology as a list of nodes and links is defined in
 http://datatracker.ietf.org/doc/draft-clemm-netmod-yang-network-topo/.
 This draft is implemented in the OpenDaylight controller as a part of the
 Hydrogen Service Provider edition. OpenDaylight supports RESTconf v02
 (http://datatracker.ietf.org/doc/draft-bierman-netconf-restconf) on its NB
 interface and can provide data (including topology graphs) to clients in
 both XML and JSON formats. OpenDaylight is open sourced under EPL.



 Thanks,
 /Jan


 On 1/31/14, 12:57 PM, Greg Bernstein gr...@grotto-networking.com wrote:

 Hi Vijay, see comments below.
 Cheers
 Greg
 On 1/29/2014 3:04 PM, Vijay K. Gurbani wrote:
 Michael, Greg: Great dialogue.

 I think as a general deliverable for An ALTO format for encoding
 graphs, this dialogue has shed some clarity on what could be the
 outcome of such a deliverable.  The scope of what goes into encoding
 the graph would be something that we should discuss as well.

 It appears that normal attributes associated with graph representation
 are in scope, and these include labels for vertices and edges, in-degree
 and out-degree for vertices, the pair of vertices an edge connects,
 and a set of properties associated with edges and vertices.  (This is
 essentially the property graph model you outline in [1].)

 I'd like to see what the thoughts are of you (and the working group)
 on whether we end up using an existing format (and how that will
 actually work with respect to the copyright holders, if any, of the
 existing format) or do we come up with a new one?
 -- NetworkX originated with a government research project is is open
 sourced under BSD
 (http://networkx.github.io/documentation/latest/overview.html#free-softwar
 e). 
 Hard to exactly say what the Tinkerpop open source license is
 (https://github.com/tinkerpop/blueprints). However, neither of these is
 formally defined at a sufficient level for standardization purposes,
 i.e., not even close to the JSON standardized in the current ALTO spec.
 As Michael pointed out the structure of a graph in JSON via node lists
 and link lists with properties is a fairly generic notion. We'd need to
 formalize it for interoperability sake. Note also that representing
 paths as a list of links (link-path representation) is also fairly
 generic.
 Another question to consider is whether this new format will subsume
 the existing topology map and cost map as well?  Or does this new
 format only model individual hosts and the links connecting them
 and stays away from representing the hosts in the aggregate (the PID
 concept)?  Usages of ALTO that will benefit from existing concepts
 (PIDs, pairwise costs) can continue to use the existing topologies and
 cost maps.  Usages of ALTO that need more detailed knowledge of
 individual hosts and link can use the new extension format for encoding
 graphs.
 -- Not sure if this is possible. Was having related discussions with
 Wendy and Richard, they may have more ideas on this.
 Regarding the second sub-issue on the need for reductionist algebra for
 graph transformations, I agree with you [1] that we leave that up to the
 ALTO client.  I believe that such a strategy will allow Greg to derive
 service-specific graphs that are transformed from an original graph.
 Since the specific need for such service-specific graphs will be a
 function of what the ALTO client wants, it seems reasonable to provide
 building blocks in the form of an extension for encoding graphs that
 can be coupled with the extensions for TE metrics
 (draft-wu-alto-te-metrics).  It is up to the ALTO client to put these
 together in some fashion that satisfies its constraints.
 -- Either the client or the server but not part of the standard. How a
 network provider wants to represent
 their network to a client is their business.  In the case of controlled
 environments (VPN) the provider may
 customize what they show to a particular client (based on pre-arranged
 information that is out of our scope).
 This will leave us with a reasonable and tractable problem to come up
 with an extension to encode graphs, hopefully in a short time frame.

 [1] http://www.ietf.org/mail-archive/web/alto/current/msg02365.html

 Looking forward to your responses and insights.

 Cheers,

 - vijay

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

 ___
 alto mailing list
 alto@ietf.org
 https://www.ietf.org/mailman/listinfo/alto




-- 
===
Dr Greg

Re: [alto] Work items for re-chartering

[Greg Bernstein]

Hi Michael good conversation, see responses in line below.
Cheers
Greg
On 1/29/2014 2:49 AM, Scharf, Michael (Michael) wrote:

 Hi Greg,

  

 Some comments inline [MS].

  

 Michael

  

 *From:*alto [mailto:alto-boun...@ietf.org] *On Behalf Of *Greg Bernstein
 *Sent:* Tuesday, January 28, 2014 4:54 PM
 *To:* alto@ietf.org
 *Subject:* Re: [alto] Work items for re-chartering

  

 Great points Michael.  In our paper available at
 http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf
 in section III we give a number of reduction/transformation
 procedures.  We looked at this from the point of view of lists of
 paths, most suitable when there are few path choices and a limited
 number of source-destination pairs of interest. And we looked at this
 from the point of view of a service specific graphs which were
 transformed from the original graph based on source-destination pairs
 of interest and limits on additive paths measures such as delay.

  

 [MS] I haven't digged through all the maths in the paper. I fully
 agree that there can be service specific graphs, similar to service
 specific ALTO maps, which are possible as of today. However, the key
 question to me is whether the ALTO protocol actually needs protocol
 primitives to deal with this. For instance, referring to the paper, if
 the ALTO server would expose the graph shown in Figure 6, the ALTO
 client could calculate the different views in Figure 7 without
 requiring ALTO functions for this (other than e.g. well-defined
 metrics, e.g., based on draft-wu-alto-te-metrics). As I already said,
 I am open to adding such functions to ALTO (as optional extensions),
 but we need something that is easy to understand as a starting point.

-- The idea (in a VPN or other somewhat controlled context) is that the
network provider would take its internal graph representation such as
shown in figure 6 and reduce it based on such items as a limited
collection of potential source-destination pairs of interest to the
client, previously agreed on QoS measures or metrics.  Such a process
would not be subject to standardization. However, the paper was trying
to show that such graph transformations could be as simple or
complicated as the provider chose (but also that they were viable).


 ---snip---

   * Path definitions
 Standardize a format for paths in terms of nodes or links. This
 allows for path only topology sharing and abstraction. This is
 also useful/needed for multi-layer network descriptions. OGF NML
 has a path in terms of links in its serial-compound link notion.

 [MS] What is the difference between a path and a link? How would an
 application use such a path?

-- When we first presented the high bandwidth use case (summer of
2012) we did it in terms of lists of abstract paths (see section III.A
of the paper) and their mutual dependencies via share links. This is
particularly effective if the number of source-destination pair
candidates is limited, and the number of paths choices between a
source-destination pair is limited (e.g., IP with OSPF based routing as
the underlying technology).

I'm getting set to teach a graduate course on network design course and
have been surveying texts and the literature. Depending upon the
underlying technology and constraints two general approaches are
typically used: (a) link-path formulation, and (b) node-link
formulation. Our proposed extensions to ALTO to deal with bandwidth
constraints (capacitated design problem) can benefit from both
formulations depending on the context. However we want to keep the JSON
encoding as simple as possible.

   * Ports on Nodes
 These should be supported but not required, similar to what is
 done in GraphML.

 [MS] I think I agree to that.


 Ports are useful in asymmetric switching nodes such as ROADMs.

   * Multi-Layer Modeling
 For this we need the adaptation concept. We can define this as an
 edge with properties if we are building on basic graph notions of
 vertices and edges.
 Note that OGF doesn't define layer networks, but just assigns
 encodings to links, ports, adaptations, and switching services.

 [MS] I don't understand this. What would be an ALTO-like example?

-- Once again I would use a VPN/private network example. For example
consider a campus of data centers with optical switches (WSON) used for
the inter-building network and SDN (OpenFlow) Ethernet switches for
intra building.  This would be a yet more sophisticated network
consumer, but not unreasonable given current networking trends. 
Although advanced I think we can allow for this type of extension via a
default single layer model with optional layer parameters as opposed to
required layer parameter  on very link, port, switching service as done
in the OGF.

   * Need to separate graph notions from network notions.
 Graphs only have vertices and edges. Graph description languages
 or frameworks (e.g. NetworkX) do allow for these to have

Re: [alto] Work items for re-chartering

[Greg Bernstein]

Support all 7.
Greg
On 1/23/2014 11:11 AM, Vijay K. Gurbani wrote:
 Folks: Over the last few IETFs, Enrico and I have solicited feedback
 during face-to-face meetings, WG sessions, hallway conversations, ALTO
 mailing list and private conversations on how to move ahead with respect
 to adopting new work items.

 As we begin the charter discussions, we have identified seven
 work items to propose as additions to the charter.  The first four of
 these work items are fairly uncontroversial.  The last three are work
 items that have a monumental mind share in the ALTO working group and
 have been found to be extremely useful in controlled networks (e.g.,
 VPNs).  However, we have to take some care in defining these such that
 we do not duplicate the functionality available elsewhere (e.g., general
 routing) in ALTO, nor do we take on an aspect that the working group
 does not fully understand.

 Here are the seven items up for discussion:

 1. Anycast-based server discovery
(Presented by Reinaldo Penno in IETF 86 and appears to have
some support for adoption.)

 2. Third-party server discovery
(Sebastian Kiesel et al. have been driving this work and it
also appears to have support.)

 3. Incremental ALTO map updates
(Side meeting held during IETF 86; two proposals have been
studied.  One way forward is to use an ALTO-specific incremental
update that may be more efficient, and the second approach is to
simply use JSON patch.)

 4. Server-initiated update notifications
(Jan Seedorf and Enrico Marocco have suggested the use of
Websockets; HTTP/2.0 may provide some mitigation as well.)

 5. Extensions to annotate PIDs with properties (e.g., geographical
locations).
(Useful as an extension in controlled environments, e.g., VPNs
where IP addresses are not the only form of identification.
Some drafts, including draft-roome-alto-pid-properties
has already started work in this direction.)

 6. Extensions for cost metrics.
(Some drafts, including draft-wu-alto-json-te, have started work
in this direction.)

 7. An ALTO format for encoding graphs.
(draft-ietf-alto-protocol already recognizes the need to provide
topology details that are useful in controlled environments.
Richard Yang, Greg Bernstein and others have been working on the
need and use cases for such an encoding.  draft-yang-alto-topology
is a good start.  Projects like OpenDayLight and NetworkX (Python)
have JSON models for graph representation.  Some concrete examples
of how we envision encoding graphs will be useful during list
discussion.)

 We will like to understand whether the working group believe such
 additional deliverables, if included in an updated charter proposal,
 would allow people to do the extension work that has been repeatedly
 proposed. (Clarification: we are explicitly asking whether people could
 find such an update acceptable. We understand that anyone will have a
 preferred flavor of the above.)

 We are at a point where show of support by whoever is interested is
 essential for moving forward. If it turns out to be positive, Enrico
 and I will subsequently circulate actual text, including milestones, for
 a rechartering request.

 Thanks.

 - vijay


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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Work items for re-chartering

[Greg Bernstein]

-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?
 Yes, at least this is my understanding. GML is, as well as GraphML (XML), 
 widely used on open source tools, but both are not JSON based. 

 An example for a JSON format that available in the well-known tinkerpop open 
 source graph processing tool suite would be GraphSON: 

 https://github.com/tinkerpop/blueprints/wiki/GraphSON-Reader-and-Writer-Library

 While I have no preference regarding the specific JSON syntax, I think that 
 we look for a property graph model. According to 
 https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model,
 a property graph has these elements:

 a set of vertices
 each vertex has a unique identifier.
 each vertex has a set of outgoing edges.
 each vertex has a set of incoming edges.
 each vertex has a collection of properties defined by a map from key 
 to value.
 a set of edges
 each edge has a unique identifier.
 each edge has an outgoing tail vertex.
 each edge has an incoming head vertex.
 each edge has a label that denotes the type of relationship between 
 its two vertices.
 each edge has a collection of properties defined by a map from key to 
 value.


 In your GML example, the key question is thus how to deal with the value 
 property of the edges. Similar to the ALTO maps, I'd argue that an ALTO graph 
 must support a default cost metric (routingcost), but extensions should be 
 possible.


 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
 Section 4 of [1] contains some pretty advanced concepts. I am not sure if in 
 the current re-chartering we should aim at that level of complexity.

 In my opinion, a more low-hanging fruit - as a starting point for a 
 discussion - would be the question whether ALTO would have protocol 
 primitives to do SPF (and CSPF) queries on the graph. That would be an 
 equivalent to the endpoint cost service. In my view, there are two 
 alternatives:

 a) Corresponding ALTO primitives are specified along with the graph format

 b) As a first step, such queries would be left up to the ALTO client, i.e., 
 the ALTO server only provides the maps (=graph), but it is up to the ALTO 
 client to perform advanced logic using that data

 I personally think that b) might be an easier first step for the 
 re-chartering, but if somebody comes up with a good ALTO API extension for 
 a), I'd be interested in it as well.

 Michael

 ___
 alto mailing list
 alto@ietf.org
 https://www.ietf.org/mailman/listinfo/alto



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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] extension questions and comments

[Greg Bernstein]

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 (510) 573-2237

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Extension: A document defining multi-metrics filtering?

[Greg Bernstein]

Hi Richard, in our expired draft on  large bandwidth uses
cases,http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02,
we were counting on some type of multi-cost extension (see section 5).
Hence, I concur with your assessment of the need and usefulness of such
an extension.
Cheers

Greg B.
On 10/13/2013 4:57 PM, Y. Richard Yang wrote:
 Dear all,

 The base ALTO protocol
 (http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) is mostly a
 single-cost-metric centric:

 - The Cost Map filtering service uses only one cost-type (Sec. 11.3.2.3):

  object {
  CostType   cost-type;
  [JSONString constraints0..*;]
  [PIDFilter  pids;]
} ReqFilteredCostMap;

object {
  PIDName srcs0..*;
  PIDName dsts0..*;
} PIDFilter;

 ...
  constraints  Defines a list of additional constraints on which
   elements of the Cost Map are returned.  This parameter MUST NOT be
   specified if this resource's capabilities (Section 11.3.2.4)
   indicate that constraint support is not available.  A constraint
   contains two entities separated by whitespace: (1) an operator,
   'gt' for greater than, 'lt' for less than, 'ge' for greater than
   or equal to, 'le' for less than or equal to, or 'eq' for equal to;
   (2) a target cost value. 

 - The Endpoint Cost service allows filtering (Sec. 11.5.1.3) as well,
 and is similar to Cost Map Filtering:

object {
  CostType  cost-type;
  [JSONString   constraints0..*;]
  EndpointFilterendpoints;
} ReqEndpointCostMap;

object {
  [TypedEndpointAddr srcs0..*;]
  [TypedEndpointAddr dsts0..*;]
} EndpointFilter;

constraints  Defined equivalently to the constraints input
   parameter of a Filtered Cost Map (see Section 11.3.2).

 In other words, in the base protocol, the filtering condition and the
 output are based on the same Cost Metric. It is natural that the
 filtering and the output are based on different Cost metrics. For
 example, a Client asks for routingcost for only pairs whose latency is
 below a threshold (see use cases in
 http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07). 

 One may argue that the filter-metric-no-equal-to-output-metric
 function can be implemented on top of the
 filter-and-output-using-one-metric function:

 In particular, suppose the filtering is based on metrics M1 and M2,
 and the output is M3, for a set src to a set dsts. The Client can use
 the following three queries:

 - Q1: Use single metric M1, filter on M1, srcs, dsts and obtains
 srcs1, dsts1 in return;
 - Q2: Use single metric M2, filter on M2, srcs1, dsts1 and obtains
 srcs2, dsts2 in return;
 - Q3: Use single metric M3, no filter, srcs2, dsts2 to get the final
 result.

 Although this is not too bad, it is inconvenient. Note that preceding
 is first discussed by Sabine, Wendy, Nico in:
 http://tools.ietf.org/html/draft-randriamasy-alto-multi-cost-07

 I saw that this is also the issue discussed in  
 - http://tools.ietf.org/html/draft-wu-alto-json-te-01
 - http://tools.ietf.org/html/draft-lee-alto-app-net-info-exchange-02

 Hence, I propose that the WG extends the base protocol with this
 capability, as I see that it is quite useful. One issue is that I see
 three designs, and I am wondering if the authors are preparing on
 discussing their designs at the coming IETF, and if there is a
 possibility for a single, unified document, focusing on this issue.

 Thanks a lot!

 Richard


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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Draft agenda for Berlin

[Greg Bernstein]

I'm not seeing anything posted at the IETF's remote participation site 
(http://www.ietf.org/meeting/87/remote-participation.html)
is there any place else I should be looking?  For skype my user name is: 
wind4dad

Cheers
Greg B.

On 7/26/2013 10:21 AM, Y. Richard Yang wrote:


Hi Greg,

A backup plan is that we use Skype to add remote participants. How 
does this sound?


Richard

On Jul 26, 2013 10:12 AM, Greg Bernstein 
gr...@grotto-networking.com mailto:gr...@grotto-networking.com wrote:


Is there a way to make this session available for remote
participation?
Thanks
Greg B.
On 7/24/2013 1:30 AM, Enrico Marocco wrote:

The request for an additional evening session has been approved. Here
are the details:

Assigned Room: Tegel
Assigned Date: 07/31/2013
Assigned Start Time: 20:00:00

As in Orlando, the plan is to use the time to discuss the five drafts on
the bottom of the agenda in a loosely structured way (i.e. with short
presentations and room discussion with no mic queue, if not practically
required).

If people have additional topics they would like to discuss, please send
a note to the chairs.

Enrico and Vijay

On 7/17/13 11:52 AM, Enrico Marocco wrote:

Hi all,

here's the draft agenda for the upcoming IETF meeting:
http://www.ietf.org/proceedings/87/agenda/agenda-87-alto

As we did in Orlando, we'll keep discussions in the Monday session
focused on charter deliverable, and we'll request an additional evening
session (tentatively on Wednesday) for extensive discussion of the
proposed extensions.

If you have sent a request for a slot, please check that it has properly
been accommodated on the agenda.

Enrico and Vijay




___
alto mailing list
alto@ietf.org  mailto:alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



-- 
===

Dr Greg Bernstein, Grotto Networking(510) 573-2237  
tel:%28510%29%20573-2237


___
alto mailing list
alto@ietf.org mailto:alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto




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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Draft agenda for Berlin

[Greg Bernstein]

Is there a way to make this session available for remote participation?
Thanks
Greg B.
On 7/24/2013 1:30 AM, Enrico Marocco wrote:

The request for an additional evening session has been approved. Here
are the details:

Assigned Room: Tegel
Assigned Date: 07/31/2013
Assigned Start Time: 20:00:00

As in Orlando, the plan is to use the time to discuss the five drafts on
the bottom of the agenda in a loosely structured way (i.e. with short
presentations and room discussion with no mic queue, if not practically
required).

If people have additional topics they would like to discuss, please send
a note to the chairs.

Enrico and Vijay

On 7/17/13 11:52 AM, Enrico Marocco wrote:

Hi all,

here's the draft agenda for the upcoming IETF meeting:
http://www.ietf.org/proceedings/87/agenda/agenda-87-alto

As we did in Orlando, we'll keep discussions in the Monday session
focused on charter deliverable, and we'll request an additional evening
session (tentatively on Wednesday) for extensive discussion of the
proposed extensions.

If you have sent a request for a slot, please check that it has properly
been accommodated on the agenda.

Enrico and Vijay





___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Draft agenda for Berlin

[Greg Bernstein]

Sounds great. The meeting time is equivalent to 11:00AM PST so is quite 
convenient.

I posted two fairly complete examples of using  topology information to my
web site:
(a) Video on Demand example using abstract topology graph: 
http://www.grotto-networking.com/VoDExample.html
(b) Data Center backup scheduling using abstract paths with 
dependencies: http://www.grotto-networking.com/BackupExample.html
-- The above have some interactive features that utilize JavaScript, so 
if ya can't run those see the paper below --
(c) A paper that summarizes some of our previous work and these 
examples:http://www.grotto-networking.com/files/BandwidthConstraintModeling.pdf. 
Which relates to Richard's draft.

Cheers
Greg B.
http://www.grotto-networking.com/BackupExample.html
On 7/26/2013 10:21 AM, Y. Richard Yang wrote:


Hi Greg,

A backup plan is that we use Skype to add remote participants. How 
does this sound?


Richard

On Jul 26, 2013 10:12 AM, Greg Bernstein 
gr...@grotto-networking.com mailto:gr...@grotto-networking.com wrote:


Is there a way to make this session available for remote
participation?
Thanks
Greg B.
On 7/24/2013 1:30 AM, Enrico Marocco wrote:

The request for an additional evening session has been approved. Here
are the details:

Assigned Room: Tegel
Assigned Date: 07/31/2013
Assigned Start Time: 20:00:00

As in Orlando, the plan is to use the time to discuss the five drafts on
the bottom of the agenda in a loosely structured way (i.e. with short
presentations and room discussion with no mic queue, if not practically
required).

If people have additional topics they would like to discuss, please send
a note to the chairs.

Enrico and Vijay

On 7/17/13 11:52 AM, Enrico Marocco wrote:

Hi all,

here's the draft agenda for the upcoming IETF meeting:
http://www.ietf.org/proceedings/87/agenda/agenda-87-alto

As we did in Orlando, we'll keep discussions in the Monday session
focused on charter deliverable, and we'll request an additional evening
session (tentatively on Wednesday) for extensive discussion of the
proposed extensions.

If you have sent a request for a slot, please check that it has properly
been accommodated on the agenda.

Enrico and Vijay




___
alto mailing list
alto@ietf.org  mailto:alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



-- 
===

Dr Greg Bernstein, Grotto Networking(510) 573-2237  
tel:%28510%29%20573-2237


___
alto mailing list
alto@ietf.org mailto:alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto




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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [irs-discuss] About ALTO, BGP-LS, IRS

[Greg Bernstein]

information base with a
specialized format for network topology,
and every OpenFlow controller
requires this. Having a standardized way
to represent it might
foster a
common topology database package. Another
application is network
management. Every network management
system needs some kind of
topology
representation. Finally, though I am not
an expert in PCE
construction,
it would seem to me that a PCE would need
some kind of topology
representation in order to perform path
calculations. Having a way,for
example, for the OpenFlow controller and
the PCE to exchange topology
information would be really useful. I
would say to start with physical
topology because that is fundamental, but
make the format flexible
enough
to support
virtual topology representation.

jak
___
irs-discuss mailing list
irs-disc...@ietf.org
mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss


___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss


___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [irs-discuss] About ALTO Vs. BGP-LS

[Greg Bernstein]

to support
virtual topology representation.

jak
___
irs-discuss mailing list
irs-disc...@ietf.org
mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss


___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss


___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss

___
irs-discuss mailing list
irs-disc...@ietf.org mailto:irs-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss



___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto



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

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [altoext] i2aex BOF - Large Bandwidth Use Case

[Greg Bernstein]

Hi Richard good questions and comments see below for a few more comments.
Folks remember to talk clearly into the microphones at the meeting. A 
number of use will be remote!

Cheers
Greg
On 3/24/2012 4:27 PM, Y. R. Yang wrote:

Hi Young,

Very nice deck of slides with some very interesting use cases!

A quick comment/question on using approximate graphs to address the interesting issues of 
shared bottlenecks that may not be exposed by e2e links. In a dynamic, interactive 
constraint solving/joint optimization setting, such internal coupling will show up as 
cost increase on one source-dest pair, when using another independent pair.
-- When Young and I have formulated multi-commodity flow problems for 
TDM and wavelength networks we usually start by keeping the constraint 
notions of bandwidth (timeslots, wavelength) separate from cost 
notions.  In some formulations we will allow for overcapacity (generally 
to see where to light up more fiber) by adding a severe cost penalty for 
over utilized links.


But your use case does show another way to expose infrastructure info. We 
consider the use case that the path for a source, destination pair is computed 
by the infrastructure, not by the app (otherwise, it is a different story).
-- We consider the case where an app may have some control/preference 
over route choices. In GMPLS we have the notion of loose routes/paths. 
In the optical world, particularly high reliability, there may be more 
factors in the app wanting to have some say over the routes.

Then one issue of exposing only a graph is ambiguity for an app to determine 
the path for a source, destination pair, unless the underlying graph has no 
loop, since then the computed path then will depend on the policy of the 
infrastructure.
-- The tree graph in the draft was easiest to draw but the slides 
show more realistic graphs with rings and meshes. If the app will not 
have a choice in path or has no way to tell the infrastructure the path, 
then I'm not sure of need of a graph over a cost map or a distance vector.

For example, consider a graph, where each s1, s2, rs, r1, r2, rd, d1, d2 is a 
pid, si is source ER, and di is destination ER in your example:

s1 -  rs
s2 -  rs
rs -  r1
rs -  r2
r1 -  rd
r2 -  rd
rd -  d1
rd -  d2

Then the app may not be able to figure out the path for s1 to d1, or s2 to d2.
-- From the perspective of ambiguity since there are multiple paths 
that could be taken?


One possibility is to expose the node path in a cost map, where the value of 
each entry is a (bgp style) path vector, in addition to a graph topology map. I get a 
feeling that others may have better, more compact representation, but the preceding seems 
simple.  What do you think?
-- Hmm, interesting. Are you suggesting to use both a graph to capture 
bottlenecks and a path vector to show costs and provider selected 
routes? Hmm, this sounds useful without the reservation interface that 
we would also like ;-) .


Thanks!

Richard

On Mar 23, 2012, at 1:40 PM, Leeyoungleeyo...@huawei.com  wrote:


WARNING: contains banned part
This message cannot be displayed because of the way it is formatted. Ask the 
sender to send it again using a different format or email program. 
multipart/mixed
___
altoext mailing list
alto...@ietf.org
https://www.ietf.org/mailman/listinfo/altoext

___
altoext mailing list
alto...@ietf.org
https://www.ietf.org/mailman/listinfo/altoext





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


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Background on draft-bernstein-alto-large-bandwidth-cases-00.txt

[Greg Bernstein]

Hi ALTO folks, a bit of background on this draft.  I'm a network 
plumber, i.e., someone that has been dealing with optical pipes for the 
last 12 years or so. Initially, we applied GMPLS techniques to SONET/SDH 
networks and more recently wavelength division multiplexing (WDM) networks.


The application of GMPLS like techniques to SONET/SDH has seen wide 
deployment by carriers in core networks world wide. GMPLS and PCE are 
great control techniques within a network (sometimes segmented by 
particular network layers), but do not make a good interface to the 
application layer. Some carriers offer web portals to allow optical 
VPN customers to change the optical connectivity (bandwidth allocations) 
amongst their sites. However such an interface would be both optical 
transport layer and carrier specific.


The current ALTO protocol work contains many concepts and mechanisms 
that would be useful for dealing with applications layer entities that 
need to find out about large bandwidth availability to various locations 
and the costs. The draft illustrates some use cases and additional 
information and interfaces for large bandwidth users.


Best Regards

Greg B.

On 6/29/2011 10:49 AM, Leeyoung wrote:

Hi,

We have submitted a new I-D:
http://www.ietf.org/internet-drafts/draft-bernstein-alto-large-bandwidth-cases-00.txt

This draft addresses use cases/applicability of the ALTO concept that would 
allow network query, high bandwidth reservation to request network resources 
from application stratum in data center/cloud networking environments.

We'd appreciate your input to this draft.

Regards,
Greg  Young

--snip--

Abstract:
This draft describes two generic use-cases that illustrate
application layer traffic optimization concepts applied to high
bandwidth core networks. For the purposes here high bandwidth will
mean bandwidth that is significant with respect to the capacity of a
wavelength in a wavelength division multiplexed optical transport
system, e.g., 10-40Gbps or more. For each of these generic use cases,
we present a generic optimization problem, look at the type of
information needed (query interface) to perform the optimization,
investigate a reservation interface to request network resources, and
also consider enhanced availability and recovery scenarios.



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


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto