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

[Y. Richard Yang]

Great discussion! I agree that the key value of ALTO services is that they
are from the perspective of the application layer, hiding complexities due
to those of the underlining network layer technologies, through ALTO
abstractions.

I will post the new capacity region design schema shortly, as capacity
region can be an important concepts for applications.

Richard

On Thu, Jul 7, 2016 at 12:50 PM, Greg Bernstein  wrote:

> 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 map and the endpoint cost map provided by ECS, they are
> basically full mesh 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 cases such 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 "topology
> extension" 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.), relay points (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  wrote:
>
>> Greg,
>>
>> Nice discussion!
>>
>> On Wednesday, July 6, 2016, Greg Bernstein 
>> 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., 

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  wrote:

Greg,

Nice discussion!

On Wednesday, July 6, 2016, Greg Bernstein
 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 missing is the
**capacibity region** of x due to correlation among flows. The

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

[Y. Richard Yang]

Let me add one note. Please see below.

On Wednesday, July 6, 2016, Y. Richard Yang  wrote:

> Greg,
>
> Nice discussion!
>
> On Wednesday, July 6, 2016, Greg Bernstein  > 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 missing is the **capacibity region**
> of x due to correlation among flows. The motivating example we presented is
> always this case. For example, the dumbbell example is this case: flow 1
> can get 10, flow 2 can get 10, but what if the two flows together? In other
> words, the capacity region can be a complex polytope. What we mean routing
> path abstraction is mostly to provide this info, which is a
> highly important network info for application optimization.
>

The only other case beyond capacibity region is shared risk link group. But
this may not need to reveal topology---each flow reveals the set of risk
labels can do. Make sense?

Richard


> If we agree with the preceding essence, we can have a pretty precise,
> concise spec. Make sense?
>
> Richard
>
>> 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> 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
>>> 

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

[Y. Richard Yang]

Greg,

Nice discussion!

On Wednesday, July 6, 2016, Greg Bernstein 
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 missing is the **capacibity region**
of x due to correlation among flows. The motivating example we presented is
always this case. For example, the dumbbell example is this case: flow 1
can get 10, flow 2 can get 10, but what if the two flows together? In other
words, the capacity region can be a complex polytope. What we mean routing
path abstraction is mostly to provide this info, which is a
highly important network info for application optimization.

If we agree with the preceding essence, we can have a pretty precise,
concise spec. Make sense?

Richard

> 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
> > 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 (
>> 
>> 

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 
> 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 

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 >   |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/ |
 =


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

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

[Y. Richard Yang]

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 
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
>
> 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    |
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
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