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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 1 Aug 2016 16:37:35 -0500

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
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: [email-masked] / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Leeyoung <[email-masked]>
Date: Mon, 1 Aug 2016 22:07:14 +0000

Yes, support for adoption.

Young

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Monday, August 01, 2016 4:38 PM
To: IETF ALTO
Cc: [email-masked]; [email-masked]
Subject: Call for adoption: Adopting graph representation format deliverables

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.

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,

- vijay

---

From: Jensen Zhang <[email-masked]>
Date: Tue, 2 Aug 2016 10:24:06 +0800

Support.

Jensen

On Tue, Aug 2, 2016 at 6:07 AM, Leeyoung <[email-masked]> wrote:

> documents towards the charter deliverable of graph representation formats
> in ALTO.
>
> 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.
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 2 Aug 2016 09:04:37 +0000

I think the path vector format is a valuable addition to ALTO. Sorry, I have not followed the routing state abstraction recently but looking at the document right now I find the current wording rather difficult to read. For instance, it lacks intuitive engineering examples. But clarity could possibly be improved after WG adoption.

Michael  

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Monday, August 01, 2016 11:38 PM
To: IETF ALTO
Cc: [email-masked]; [email-masked]
Subject: Call for adoption: Adopting graph representation format deliverables

Thanks,

- vijay

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 2 Aug 2016 07:07:18 -0700

Support.

Greg B.

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Wed, 3 Aug 2016 13:58:15 +0000

I support these documents towards charter deliverable. 

Sabine

>>-----Message d'origine-----
>>De : alto [mailto:[email-masked]] De la part de Vijay K. Gurbani
>>Envoyé : lundi 1 août 2016 23:38
>>À : IETF ALTO
>>Cc : [email-masked]; draft-
>>[email-masked]
>>Objet : [alto] Call for adoption: Adopting graph representation format
>>deliverables
>>
>>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.
>>
>>Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane,
>>Rm. 9C-533, Naperville, Illinois 60563 (USA)

---

From: Chen Guohai <[email-masked]>
Date: Fri, 5 Aug 2016 14:22:45 +0000

I support these documents towards charter deliverables.

G.Robert

???: Vijay K. Gurbani
???: 8?2? ??? 05:37
??: [alto] Call for adoption: Adopting graph representation formatdeliverables
???: IETF ALTO
??: [email-masked], [email-masked]

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 -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: [email-masked] / [email-masked] Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ alto mailing list [email-masked] https://www.ietf.org/mailman/listinfo/alto

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 6 Aug 2016 11:09:38 +0530

Support!

---

From: Christian Esteve Rothenberg <[email-masked]>
Date: Sun, 7 Aug 2016 08:54:42 -0300

Support towards charter deliverables.

---

From: Qin Wu <[email-masked]>
Date: Wed, 10 Aug 2016 02:40:18 +0000

Support and also agree with Michale's observation.

-Qin
-----邮件原件-----
发件人: alto [mailto:[email-masked]] 代表 Scharf, Michael (Nokia - DE)
发送时间: 2016年8月2日 17:05
收件人: Gurbani, Vijay (Nokia - US); IETF ALTO
抄送: [email-masked]; [email-masked]
主题: Re: [alto] Call for adoption: Adopting graph representation format deliverables

Michael  

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]]
Sent: Monday, August 01, 2016 11:38 PM
To: IETF ALTO
Cc: [email-masked]; [email-masked]
Subject: Call for adoption: Adopting graph representation format deliverables

Thanks,

- vijay
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq _______________________________________________

---

From: Hans Seidel <[email-masked]>
Date: Thu, 11 Aug 2016 15:08:42 +0200

Hi Richard, all,

after the ALTO session in Berlin, we shortly talked with Ingmar about 
the impact of path-vector on the size of cost maps especially in 
large-scale networks.

I carried out some tests with path-vector cost maps based on our data. 
Our cost maps are already very large but path-vector maps are about 
three times larger (~50 MB vs. ~150 MB in uncompressed state). In 
average we have round about 4 hops between two PIDs which leads to an 
average path-vector of the same length. ECMP was not considered in the 
test but it will certainly further increase the size of the map.

Our idea to reduce cost map size is to provide topology information, 
e.g. with the property map presented in the unified-props draft, and let 
the client carry out the path determination. This means, the ALTO server 
provides the network, cost and property map to enable clients to get 
their desired level of detail for the path costs.

I also think this approach can coexist with path-vector cost maps. An 
ALTO server can provide both cost maps with and without path vector and 
a property map providing the topology. This way it is up to the client 
whether it wants to save bandwidth and invests some processing time to 
perform path determination by itself or it fetches the full path-vector 
cost map.

Any thoughts on this?

Cheers
Hans

---

From: Jensen Zhang <[email-masked]>
Date: Fri, 12 Aug 2016 01:16:31 +0800

Hi Hans,

Is it possible to compress the cost map by using routing state abstraction?
I think it is a potential solution.

Another solution may be to add a proxy layer to compress and decompress
ALTO protocol messages. It will reduce the communication time and not
change the implementation of ALTO servers and clients. But compression and
decompression will increase extra processing time.

We haven't test such large-scale networks, but it is indeed a problem which
need to be handled.

Best,
Jensen

On Thu, Aug 11, 2016 at 9:08 PM, Hans Seidel <[email-masked]> wrote:

> Hi Richard, all,
>
> after the ALTO session in Berlin, we shortly talked with Ingmar about the
> impact of path-vector on the size of cost maps especially in large-scale
> networks.
>
> I carried out some tests with path-vector cost maps based on our data. Our
> cost maps are already very large but path-vector maps are about three times
> larger (~50 MB vs. ~150 MB in uncompressed state). In average we have round
> about 4 hops between two PIDs which leads to an average path-vector of the
> same length. ECMP was not considered in the test but it will certainly
> further increase the size of the map.
>
> Our idea to reduce cost map size is to provide topology information, e.g.
> with the property map presented in the unified-props draft, and let the
> client carry out the path determination. This means, the ALTO server
> provides the network, cost and property map to enable clients to get their
> desired level of detail for the path costs.
>
> I also think this approach can coexist with path-vector cost maps. An ALTO
> server can provide both cost maps with and without path vector and a
> property map providing the topology. This way it is up to the client

---

From: Hans Seidel <[email-masked]>
Date: Fri, 12 Aug 2016 15:41:52 +0200

Hi Jensen,

Thank you for your response.

see comments inline.

On 11.08.2016 19:16, Jensen Zhang wrote:
> Hi Hans,
>
> Is it possible to compress the cost map by using routing state 
> abstraction? I think it is a potential solution.
As far as I understand the routing state abstraction draft, it can be 
used to eliminate links e.g. from path-vectors regarding client defined 
conditions to reduce the size of the cost-map.
However, I see two potential limitations of routing state abstraction in 
full cost maps.

1. Assuming a full mesh cost map where costs from every PID to every PID 
are provided, so we have a flow from every PID to every PID. The more 
flows, the more fine grained is the routing state abstraction, since the 
number of shared links among different flows increases. If no 
information should be lost, I think the number of links that could be 
eliminated decreases with the number of flows. So, having many flows 
will result in little to no size reduction. Please correct me, if I got 
this wrong.
2. The computation effort for a large number of PIDs in large networks 
might exceed an acceptable limit.

> Another solution may be to add a proxy layer to compress and 
> decompress ALTO protocol messages. It will reduce the communication 
> time and not change the implementation of ALTO servers and clients. 
> But compression and decompression will increase extra processing time.

Yes, compression is a way to reduce the size at the cost of extra 
processing. It reduces the map size to 3.7MB without and 11MB with 
path-vector but keeps the size ratio at 1:3.

Hans

>
> We haven't test such large-scale networks, but it is indeed a problem 
> which need to be handled.
>
> Best,
> Jensen
>
> On Thu, Aug 11, 2016 at 9:08 PM, Hans Seidel <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Richard, all,
>
>     after the ALTO session in Berlin, we shortly talked with Ingmar
>     about the impact of path-vector on the size of cost maps
>     especially in large-scale networks.
>
>     I carried out some tests with path-vector cost maps based on our
>     data. Our cost maps are already very large but path-vector maps
>     are about three times larger (~50 MB vs. ~150 MB in uncompressed
>     state). In average we have round about 4 hops between two PIDs
>     which leads to an average path-vector of the same length. ECMP was
>     not considered in the test but it will certainly further increase
>     the size of the map.
>
>     Our idea to reduce cost map size is to provide topology
>     information, e.g. with the property map presented in the
>     unified-props draft, and let the client carry out the path
>     determination. This means, the ALTO server provides the network,
>     cost and property map to enable clients to get their desired level
>     of detail for the path costs.
>
>     I also think this approach can coexist with path-vector cost maps.
>     An ALTO server can provide both cost maps with and without path
>     vector and a property map providing the topology. This way it is
>     up to the client whether it wants to save bandwidth and invests
>     some processing time to perform path determination by itself or it
>     fetches the full path-vector cost map.
>
>     Any thoughts on this?
>
>     Cheers
>     Hans
>
>
>         --- https://tools.ietf.org/html/draft-yang-alto-path-vector-03
>         <https://tools.ietf.org/html/draft-yang-alto-path-vector-03> and
>         <https://tools.ietf.org/html/draft-gao-alto-routing-state-abstraction-03>
>         [1]
>         https://www.ietf.org/proceedings/96/minutes/minutes-96-alto
>         <https://www.ietf.org/proceedings/96/minutes/minutes-96-alto>
>
>         - vijay
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/alto>
>
>