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
<[email protected] <mailto:[email protected]>> 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&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=I_FGEj7wmGCRa-fWF84rtryfbW8a3WpXu1nXnSeaSBg&e=
). 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
[email protected] <mailto:[email protected]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=bzkMATE853C7mq8KpSsYfQ4CVhl2BqBpdPkKwCmbjvw&s=-othJunl7gz_02BM9c1kqLPhFmI2iJr3vD6gu41kd_w&e=
--
--
=====================================
| Y. Richard Yang <[email protected] <mailto:[email protected]>> |
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/> |
=====================================
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
