Re: [alto] Review of draft-ietf-alto-path-vector-11

[Vijay Gurbani]

Dear Kai: Thank you.  I will perform a chair review of -13 as part of the
shepherd writeup.
Thanks,
- vijay

On Thu, Nov 19, 2020 at 3:47 AM  wrote:

> Hi Jan, Vijay and Qin,
>
>
> As we discussed in the ALTO meeting today, -12 has addressed the comments
> of both Qiao and Luis but the revision proposed by Richard was not
> integrated. Also, Qin mentioned that a shorter and more concise abstract is
> expected.
>
>
> I have integrated the revisions of Richard and written a new abstract as
> below. Could you please take a look and see if the abstract makes sense? If
> it does, I will upload -13 once the submit tool is available.
>
>
> Thanks for the comments and looking forward to your feedback!
>
>
> Best,
>
> Kai
>
>
> --
>
>The performance of many applications, such as large-scale data
>transfers and/or mobile applications, depends on the properties of
>different components of networks.  Thus, such information is useful
>to help clients better determine the choices of delivering traffic,
>e.g., by avoiding shared bottlenecks.  This document extends the base
>Application-Layer Traffic Optimization (ALTO) protocol with a graph
>representation format using path vectors.  It 1) complements existing
>path-based ALTO cost map representation with the ability to specify
>components of networks for a source and a destination, and 2) uses
>the ALTO property map to associate these components to their
>properties.  Together, this extension provides a more complete but
>still abstract representation of networks for informed traffic
>optimization among endpoints.
>
>
> 2020-11-03 06:04:06"'Richard Yang'" wrote:
>
> H Luis,
>
> Thanks a lot for the wonderful review! As we upload the revision, here is
> a summary of the changes that we make. Please see inline to see if you are
> OK. After you approve, we will finalize all.
>
> On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO <
> luismiguel.contrerasmuri...@telefonica.com> wrote:
>
>> Hi all,
>>
>>
>>
>> I have performed a review of the draft, with comments as follows:
>>
>>
>>
>> /* Technical comments */
>>
>> .- Section III Terminology – Path Vector bullet. Please, rephrase the
>> description, it is hard to understand, especially the second sentence. Not
>> clear.
>>
>
> OLD
>  Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
>   of ANE Names.  It conveys the information that the path between a
>   source and a destination traverses the ANEs in the same order as
>   they appear in the Path Vector.
>
> NEW
>
> Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
>   of ANE Names.  This extension (i.e., ALTO path vector extension)
> generalizes
>   BGP path vector, where a standard BGP path vector specifies the
> sequence of
>   autonomous systems from a source to a destination. In this
> extension, the path
>   vector specifies the sequence of general ANEs computed according to
> a user
>   request.
>
> .- Section 4.2 – it refers to recent use cases, but it is not relevant how
>> recent are the use cases (in fact, for this, see my next comment). So I
>> would suggest to remove any reference to recent either in the title or the
>> text. Simply refer to use cases.
>>
>
> Very good point. We have removed the word "recent" in the title and the
> text.
>
>
>
>> .- Section 4.2 – there is a reference to an expired I-D which last from
>> 2013 (so pretty old). I would suggest to remove such a reference since
>> somehow the potential use cases it refers should be present here.
>>
>
> Sounds good. Yes. Removed.
>
>
>> .- Section 5.1.3, 2nd paragraph – “… and the response must return and
>> only return the selected properties …” – two comments here: (1) must should
>> be MUST in this context?; (2) “… and only return …” – probably redundant,
>> better either remove or rephrase as “MUST/must only return”.
>>
>
> Good point.
>
> OLD
>"... and the
>response must return and only return the selected properties for the
>ANEs in the response."
>
> NEW
>   "... and the
>response MUST include and only include the selected properties
> specified in the filter. "
>
> .- Figure 4 – the figure shows two response messages, but some questions
>> arise in this respect: (1) what happens if second response is not
>> received?; (2) what happens if only the second response is received? Is it
>> silently discarded?; (3) is there some expected timer for accounting
>> time-out in the responses? It is mentioned in bullet 2 that there could be
>> some processing among messages, so it can be assumed that some maximum
>> delay could happen between both responses.
>>
>
> Good point.
>
> OLD
>   Specifically, the
>Path Vector extension requires the ALTO client to include the source
>and destination pairs and the requested ANE properties in a single
>request, and encapsulates both Path Vectors and properties associated
>

Re: [alto] Review of draft-ietf-alto-path-vector-11

[Qin Wu]

发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2020年11月20日 13:39
收件人: Qin Wu 
抄送: alto@ietf.org; Jan Seedorf ; Vijay Gurbani 

主题: Re: RE: Re: [alto] Review of draft-ietf-alto-path-vector-11


Hi Qin,



Thanks for the comments.



I took a look at the new RFCs (SSE and Cost Calendar). My impression is that 
their abstract mainly focuses on the benefits and high-level ideas of the 
extension. I try to follow the same structure and modify the abstract based on 
your proposed text:



This document is an extension to the base Application-Layer Traffic

Optimization (ALTO) protocol. It extends the ALTO Cost Map service

and ALTO Property Map service so that the application can decide

which endpoint(s) to connect based on not only numerical/ordinal cost

values but also details of the paths. This is useful for applications whose

performance is impacted by specified components of a network on the

end-to-end paths, e.g., they may infer that several paths share common

links and prevent traffic bottlenecks by avoiding such paths. This extension

introduces a new abstraction called Abstract Network Element (ANE) to

represent these components and encodes a network path as a vector of

ANEs. Thus, it provides a more complete but still abstract graph representation

of the underlying network(s) for informed traffic optimization among endpoints.



Also, I feel it might be a good idea to add a sentence in the end to link to 
the corresponding charter item (e.g., "Together, they provide a more complete, 
potentially more compact, but still abstract representation of networks for 
informed traffic optimization among endpoints.").



Does the proposed text make sense? Looking forward to your feedback!

[Qin]: Kai, the proposed change looks good, thanks for polishing it.

Thanks!



Best,

Kai


-Original Messages-
From:"Qin Wu" mailto:bill...@huawei.com>>
Sent Time:2020-11-19 20:18:34 (Thursday)
To: "kai...@scu.edu.cn<mailto:kai...@scu.edu.cn>" 
mailto:kai...@scu.edu.cn>>, 
"alto@ietf.org<mailto:alto@ietf.org>" mailto:alto@ietf.org>>
Cc: "Jan Seedorf" 
mailto:jan.seed...@hft-stuttgart.de>>, "Vijay 
Gurbani" mailto:vijay.gurb...@gmail.com>>
Subject: RE: Re: [alto] Review of draft-ietf-alto-path-vector-11
Thanks Kai Gao for heads up.

I feel the abstract in the path vector is too long, I propose to have the 
following changes to the abstract:

"

   This document is an extension to the base Application-Layer Traffic

   Optimization (ALTO) protocol. It extends the ALTO Cost Map service and

   ALTO property Map service so that the application can decide which endpoint

   to connect but also which connection path to select.



   This is useful for applications whose performance is impacted by specified 
Network Elements of end to end path

   they traverse or by their properties, e.g., they may infer that several 
paths share common links

   and prevent traffic bottlenecks by avoiding such paths. Examples of such 
Elements include

   physical devices such as routers, cables and

   interfaces, and aggregations of devices such as subnetworks and data

   centers. Example of such properties include network elements id, link id.



   This extension introduces a new cost type called Path Vector.  A Path Vector 
is

   an array of entities that each identifies an Abstract Network Element (ANE).

   Each ANE is associated with a set of properties.  ANE properties are 
introduced and conveyed by

   an ALTO information resource called "Property Map", that can be

   packed together with the Path Vectors in a multipart response.  They

   can also be obtained via a separate ALTO request to a Property Map.

"

-Qin
发件人: kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> [mailto:kai...@scu.edu.cn]
发送时间: 2020年11月19日 17:47
收件人: alto@ietf.org<mailto:alto@ietf.org>
抄送: Jan Seedorf 
mailto:jan.seed...@hft-stuttgart.de>>; Vijay 
Gurbani mailto:vijay.gurb...@gmail.com>>; Qin Wu 
mailto:bill...@huawei.com>>
主题: Re: Re: [alto] Review of draft-ietf-alto-path-vector-11


Hi Jan, Vijay and Qin,



As we discussed in the ALTO meeting today, -12 has addressed the comments of 
both Qiao and Luis but the revision proposed by Richard was not integrated. 
Also, Qin mentioned that a shorter and more concise abstract is expected.



I have integrated the revisions of Richard and written a new abstract as below. 
Could you please take a look and see if the abstract makes sense? If it does, I 
will upload -13 once the submit tool is available.



Thanks for the comments and looking forward to your feedback!



Best,

Kai



--

   The performance of many applications, such as large-scale data
   transfers and/or mobile applications, depends on the properties of
   different components of networks.  Thus, such information is useful
   to help clients b

Re: [alto] Review of draft-ietf-alto-path-vector-11

[kaigao]

Hi Qin,




Thanks for the comments.




I took a look at the new RFCs (SSE and Cost Calendar). My impression is that 
their abstract mainly focuses on the benefits and high-level ideas of the 
extension. I try to follow the same structure and modify the abstract based on 
your proposed text:




This document is an extension to the base Application-Layer Traffic

Optimization (ALTO) protocol. It extends the ALTO Cost Map service

and ALTO Property Map service so that the application can decide

which endpoint(s) to connect based on not only numerical/ordinal cost

values but also details of the paths. This is useful for applications whose

performance is impacted by specified components of a network on the

end-to-end paths, e.g., they may infer that several paths share common

links and prevent traffic bottlenecks by avoiding such paths. This extension

introduces a new abstraction called Abstract Network Element (ANE) to

represent these components and encodes a network path as a vector of

ANEs. Thus, it provides a more complete but still abstract graph representation

of the underlying network(s) for informed traffic optimization among endpoints.




Also, I feel it might be a good idea to add a sentence in the end to link to 
the corresponding charter item (e.g., "Together, they provide a more complete, 
potentially more compact, but still abstract representation of networks for 
informed traffic optimization among endpoints.").




Does the proposed text make sense? Looking forward to your feedback!




Thanks!




Best,

Kai


-Original Messages-
From:"Qin Wu" 
Sent Time:2020-11-19 20:18:34 (Thursday)
To: "kai...@scu.edu.cn" , "alto@ietf.org" 
Cc: "Jan Seedorf" , "Vijay Gurbani" 

Subject: RE: Re: [alto] Review of draft-ietf-alto-path-vector-11



Thanks Kai Gao for heads up.

I feel the abstract in the path vector is too long, I propose to have the 
following changes to the abstract:

"

   This document is an extension to the base Application-Layer Traffic

   Optimization (ALTO) protocol. It extends the ALTO Cost Map service and

   ALTO property Map service so that the application can decide which endpoint

   to connect but also which connection path to select.


 

   This is useful for applications whose performance is impacted by specified 
Network Elements of end to end path

   they traverse or by their properties, e.g., they may infer that several 
paths share common links

   and prevent traffic bottlenecks by avoiding such paths. Examples of such 
Elements include

   physical devices such as routers, cables and

   interfaces, and aggregations of devices such as subnetworks and data

   centers. Example of such properties include network elements id, link id.

  

   This extension introduces a new cost type called Path Vector.  A Path Vector 
is

   an array of entities that each identifies an Abstract Network Element (ANE).

   Each ANE is associated with a set of properties.  ANE properties are 
introduced and conveyed by

   an ALTO information resource called "Property Map", that can be

   packed together with the Path Vectors in a multipart response.  They

   can also be obtained via a separate ALTO request to a Property Map.

"

 

-Qin

发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2020年11月19日 17:47
收件人: alto@ietf.org
抄送: Jan Seedorf ; Vijay Gurbani 
; Qin Wu 
主题: Re: Re: [alto] Review of draft-ietf-alto-path-vector-11

 

Hi Jan, Vijay and Qin,

 

As we discussed in the ALTO meeting today, -12 has addressed the comments of 
both Qiao and Luis but the revision proposed by Richard was not integrated. 
Also, Qin mentioned that a shorter and more concise abstract is expected.

 

I have integrated the revisions of Richard and written a new abstract as below. 
Could you please take a look and see if the abstract makes sense? If it does, I 
will upload -13 once the submit tool is available.

 

Thanks for the comments and looking forward to your feedback!

 

Best,

Kai

 

--

   The performance of many applications, such as large-scale data
   transfers and/or mobile applications, depends on the properties of
   different components of networks.  Thus, such information is useful
   to help clients better determine the choices of delivering traffic,
   e.g., by avoiding shared bottlenecks.  This document extends the base
   Application-Layer Traffic Optimization (ALTO) protocol with a graph
   representation format using path vectors.  It 1) complements existing
   path-based ALTO cost map representation with the ability to specify
   components of networks for a source and a destination, and 2) uses
   the ALTO property map to associate these components to their
   properties.  Together, this extension provides a more complete but
   still abstract representation of networks for informed traffic
   optimization among endpoints.

 

2020-11-03 06

Re: [alto] Review of draft-ietf-alto-path-vector-11

[Qin Wu]

Thanks Kai Gao for heads up.

I feel the abstract in the path vector is too long, I propose to have the 
following changes to the abstract:

"

   This document is an extension to the base Application-Layer Traffic

   Optimization (ALTO) protocol. It extends the ALTO Cost Map service and

   ALTO property Map service so that the application can decide which endpoint

   to connect but also which connection path to select.



   This is useful for applications whose performance is impacted by specified 
Network Elements of end to end path

   they traverse or by their properties, e.g., they may infer that several 
paths share common links

   and prevent traffic bottlenecks by avoiding such paths. Examples of such 
Elements include

   physical devices such as routers, cables and

   interfaces, and aggregations of devices such as subnetworks and data

   centers. Example of such properties include network elements id, link id.



   This extension introduces a new cost type called Path Vector.  A Path Vector 
is

   an array of entities that each identifies an Abstract Network Element (ANE).

   Each ANE is associated with a set of properties.  ANE properties are 
introduced and conveyed by

   an ALTO information resource called "Property Map", that can be

   packed together with the Path Vectors in a multipart response.  They

   can also be obtained via a separate ALTO request to a Property Map.

"

-Qin
发件人: kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
发送时间: 2020年11月19日 17:47
收件人: alto@ietf.org
抄送: Jan Seedorf ; Vijay Gurbani 
; Qin Wu 
主题: Re: Re: [alto] Review of draft-ietf-alto-path-vector-11


Hi Jan, Vijay and Qin,



As we discussed in the ALTO meeting today, -12 has addressed the comments of 
both Qiao and Luis but the revision proposed by Richard was not integrated. 
Also, Qin mentioned that a shorter and more concise abstract is expected.



I have integrated the revisions of Richard and written a new abstract as below. 
Could you please take a look and see if the abstract makes sense? If it does, I 
will upload -13 once the submit tool is available.



Thanks for the comments and looking forward to your feedback!



Best,

Kai



--

   The performance of many applications, such as large-scale data
   transfers and/or mobile applications, depends on the properties of
   different components of networks.  Thus, such information is useful
   to help clients better determine the choices of delivering traffic,
   e.g., by avoiding shared bottlenecks.  This document extends the base
   Application-Layer Traffic Optimization (ALTO) protocol with a graph
   representation format using path vectors.  It 1) complements existing
   path-based ALTO cost map representation with the ability to specify
   components of networks for a source and a destination, and 2) uses
   the ALTO property map to associate these components to their
   properties.  Together, this extension provides a more complete but
   still abstract representation of networks for informed traffic
   optimization among endpoints.



2020-11-03 06:04:06"'Richard Yang'" wrote:
H Luis,

Thanks a lot for the wonderful review! As we upload the revision, here is a 
summary of the changes that we make. Please see inline to see if you are OK. 
After you approve, we will finalize all.

On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Hi all,

I have performed a review of the draft, with comments as follows:

/* Technical comments */
.- Section III Terminology – Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.

OLD
 Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  It conveys the information that the path between a
  source and a destination traverses the ANEs in the same order as
  they appear in the Path Vector.

NEW

Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  This extension (i.e., ALTO path vector extension) 
generalizes
  BGP path vector, where a standard BGP path vector specifies the sequence 
of
  autonomous systems from a source to a destination. In this extension, the 
path
  vector specifies the sequence of general ANEs computed according to a user
  request.

.- Section 4.2 – it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.

Very good point. We have removed the word "recent" in the title and the text.


.- Section 4.2 – there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.

Sou

Re: [alto] Review of draft-ietf-alto-path-vector-11

[kaigao]

Hi Jan, Vijay and Qin,




As we discussed in the ALTO meeting today, -12 has addressed the comments of 
both Qiao and Luis but the revision proposed by Richard was not integrated. 
Also, Qin mentioned that a shorter and more concise abstract is expected.




I have integrated the revisions of Richard and written a new abstract as below. 
Could you please take a look and see if the abstract makes sense? If it does, I 
will upload -13 once the submit tool is available.




Thanks for the comments and looking forward to your feedback!




Best,

Kai




--

   The performance of many applications, such as large-scale data
   transfers and/or mobile applications, depends on the properties of
   different components of networks.  Thus, such information is useful
   to help clients better determine the choices of delivering traffic,
   e.g., by avoiding shared bottlenecks.  This document extends the base
   Application-Layer Traffic Optimization (ALTO) protocol with a graph
   representation format using path vectors.  It 1) complements existing
   path-based ALTO cost map representation with the ability to specify
   components of networks for a source and a destination, and 2) uses
   the ALTO property map to associate these components to their
   properties.  Together, this extension provides a more complete but
   still abstract representation of networks for informed traffic
   optimization among endpoints.




2020-11-03 06:04:06"'Richard Yang'" wrote:

H Luis,


Thanks a lot for the wonderful review! As we upload the revision, here is a 
summary of the changes that we make. Please see inline to see if you are OK. 
After you approve, we will finalize all.


On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO 
 wrote:


Hi all,

 

I have performed a review of the draft, with comments as follows:

 

/* Technical comments */

.- Section III Terminology – Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.



OLD
 Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  It conveys the information that the path between a
  source and a destination traverses the ANEs in the same order as
  they appear in the Path Vector.


NEW


Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  This extension (i.e., ALTO path vector extension) 
generalizes
  BGP path vector, where a standard BGP path vector specifies the sequence 
of
  autonomous systems from a source to a destination. In this extension, the 
path
  vector specifies the sequence of general ANEs computed according to a 
user 
  request.




.- Section 4.2 – it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.



Very good point. We have removed the word "recent" in the title and the text.


 

.- Section 4.2 – there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.



Sounds good. Yes. Removed.
 

.- Section 5.1.3, 2nd paragraph – “… and the response must return and only 
return the selected properties …” – two comments here: (1) must should be MUST 
in this context?; (2) “… and only return …” – probably redundant, better either 
remove or rephrase as “MUST/must only return”.



Good point. 


OLD 
   "... and the
   response must return and only return the selected properties for the
   ANEs in the response."

NEW
  "... and the
   response MUST include and only include the selected properties specified in 
the filter. "



.- Figure 4 – the figure shows two response messages, but some questions arise 
in this respect: (1) what happens if second response is not received?; (2) what 
happens if only the second response is received? Is it silently discarded?; (3) 
is there some expected timer for accounting time-out in the responses? It is 
mentioned in bullet 2 that there could be some processing among messages, so it 
can be assumed that some maximum delay could happen between both responses.



Good point.


OLD
  Specifically, the
   Path Vector extension requires the ALTO client to include the source
   and destination pairs and the requested ANE properties in a single
   request, and encapsulates both Path Vectors and properties associated

   with the ANEs in a single response, as shown in Figure 4.


NEW


  Specifically, the
   Path Vector extension requires that (1) the ALTO client include the source
   and destination pairs and the requested ANE properties in a single
   request; (2) the ALTO server MUST return a single response with the Path 
Vectors followed by the
   properties associated with the ANEs in the Path Vectors, 

Re: [alto] Review of draft-ietf-alto-path-vector-11

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Richard,

Thanks for the summary. It is ok for me.

Best regards

Luis

De: Y. Richard Yang 
Enviado el: lunes, 2 de noviembre de 2020 23:04
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: alto@ietf.org
Asunto: Re: [alto] Review of draft-ietf-alto-path-vector-11

H Luis,

Thanks a lot for the wonderful review! As we upload the revision, here is a 
summary of the changes that we make. Please see inline to see if you are OK. 
After you approve, we will finalize all.

On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
 wrote:
Hi all,

I have performed a review of the draft, with comments as follows:

/* Technical comments */
.- Section III Terminology – Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.

OLD
 Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  It conveys the information that the path between a
  source and a destination traverses the ANEs in the same order as
  they appear in the Path Vector.

NEW

Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  This extension (i.e., ALTO path vector extension) 
generalizes
  BGP path vector, where a standard BGP path vector specifies the sequence 
of
  autonomous systems from a source to a destination. In this extension, the 
path
  vector specifies the sequence of general ANEs computed according to a user
  request.

.- Section 4.2 – it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.

Very good point. We have removed the word "recent" in the title and the text.


.- Section 4.2 – there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.

Sounds good. Yes. Removed.

.- Section 5.1.3, 2nd paragraph – “… and the response must return and only 
return the selected properties …” – two comments here: (1) must should be MUST 
in this context?; (2) “… and only return …” – probably redundant, better either 
remove or rephrase as “MUST/must only return”.

Good point.

OLD
   "... and the
   response must return and only return the selected properties for the
   ANEs in the response."



NEW
  "... and the
   response MUST include and only include the selected properties specified in 
the filter. "

.- Figure 4 – the figure shows two response messages, but some questions arise 
in this respect: (1) what happens if second response is not received?; (2) what 
happens if only the second response is received? Is it silently discarded?; (3) 
is there some expected timer for accounting time-out in the responses? It is 
mentioned in bullet 2 that there could be some processing among messages, so it 
can be assumed that some maximum delay could happen between both responses.

Good point.

OLD
  Specifically, the
   Path Vector extension requires the ALTO client to include the source
   and destination pairs and the requested ANE properties in a single
   request, and encapsulates both Path Vectors and properties associated
   with the ANEs in a single response, as shown in Figure 4.

NEW

  Specifically, the
   Path Vector extension requires that (1) the ALTO client include the source
   and destination pairs and the requested ANE properties in a single
   request; (2) the ALTO server MUST return a single response with the Path 
Vectors followed by the
   properties associated with the ANEs in the Path Vectors, as shown in Figure 
4.

In addition, in 5.3.3, we add the specification on the essential completeness 
issue:

OLD
5.3.3. Order of Part Message

NEW
5.3.3. Order and Completeness of Part Message

We add a sentence at the end of 5.3.3

   The ALTO server MUST always send the complete response including both parts. 
The client should check the completeness of response and implementing a timeout 
mechanism to avoid hanging issues.


.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, 
rephrase/review.

OLD
   Specifically, the defining resource of ephemeral ANEs is the Property
   Map part of the multipart response.  The defining resource of
   persistent ANEs is the Property Map on which standalone queries for
   properties of persistent ANEs are made.

NEW
   Note that there are two types of ANEs (see Section 5.1.2): ephemeral ANEs and
   persistent ANEs. For ephemeral ANEs, the defining resource is the Property
   Map part of the multipart response; the defining resource of
   persistent ANEs is the Property Map on which standalone queries for
   properties of persistent ANEs are made.

.- Section 6.4.2, Intended semantics text – it is not clear the associat

Re: [alto] Review of draft-ietf-alto-path-vector-11

[Y. Richard Yang]

H Luis,

Thanks a lot for the wonderful review! As we upload the revision, here is a
summary of the changes that we make. Please see inline to see if you are
OK. After you approve, we will finalize all.

On Sun, Oct 25, 2020 at 5:01 PM LUIS MIGUEL CONTRERAS MURILLO <
luismiguel.contrerasmuri...@telefonica.com> wrote:

> Hi all,
>
>
>
> I have performed a review of the draft, with comments as follows:
>
>
>
> /* Technical comments */
>
> .- Section III Terminology – Path Vector bullet. Please, rephrase the
> description, it is hard to understand, especially the second sentence. Not
> clear.
>

OLD
 Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  It conveys the information that the path between a
  source and a destination traverses the ANEs in the same order as
  they appear in the Path Vector.

NEW

Path Vector: A Path Vector, or an ANE Path Vector, is a JSON array
  of ANE Names.  This extension (i.e., ALTO path vector extension)
generalizes
  BGP path vector, where a standard BGP path vector specifies the
sequence of
  autonomous systems from a source to a destination. In this extension,
the path
  vector specifies the sequence of general ANEs computed according to a
user
  request.

.- Section 4.2 – it refers to recent use cases, but it is not relevant how
> recent are the use cases (in fact, for this, see my next comment). So I
> would suggest to remove any reference to recent either in the title or the
> text. Simply refer to use cases.
>

Very good point. We have removed the word "recent" in the title and the
text.



> .- Section 4.2 – there is a reference to an expired I-D which last from
> 2013 (so pretty old). I would suggest to remove such a reference since
> somehow the potential use cases it refers should be present here.
>

Sounds good. Yes. Removed.


> .- Section 5.1.3, 2nd paragraph – “… and the response must return and
> only return the selected properties …” – two comments here: (1) must should
> be MUST in this context?; (2) “… and only return …” – probably redundant,
> better either remove or rephrase as “MUST/must only return”.
>

Good point.

OLD
   "... and the
   response must return and only return the selected properties for the
   ANEs in the response."


NEW
  "... and the
   response MUST include and only include the selected properties specified
in the filter. "

.- Figure 4 – the figure shows two response messages, but some questions
> arise in this respect: (1) what happens if second response is not
> received?; (2) what happens if only the second response is received? Is it
> silently discarded?; (3) is there some expected timer for accounting
> time-out in the responses? It is mentioned in bullet 2 that there could be
> some processing among messages, so it can be assumed that some maximum
> delay could happen between both responses.
>

Good point.

OLD
  Specifically, the
   Path Vector extension requires the ALTO client to include the source
   and destination pairs and the requested ANE properties in a single
   request, and encapsulates both Path Vectors and properties associated
   with the ANEs in a single response, as shown in Figure 4.

NEW

  Specifically, the
   Path Vector extension requires that (1) the ALTO client include the
source
   and destination pairs and the requested ANE properties in a single
   request; (2) the ALTO server MUST return a single response with the Path
Vectors followed by the
   properties associated with the ANEs in the Path Vectors, as shown in
Figure 4.

In addition, in 5.3.3, we add the specification on the essential
completeness issue:

OLD
5.3.3. Order of Part Message

NEW
5.3.3. Order and Completeness of Part Message

We add a sentence at the end of 5.3.3

   The ALTO server MUST always send the complete response including both
parts. The client should check the completeness of response and
implementing a timeout mechanism to avoid hanging issues.


.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please,
> rephrase/review.
>

OLD
   Specifically, the defining resource of ephemeral ANEs is the Property
   Map part of the multipart response.  The defining resource of
   persistent ANEs is the Property Map on which standalone queries for
   properties of persistent ANEs are made.

NEW
   Note that there are two types of ANEs (see Section 5.1.2): ephemeral
ANEs and
   persistent ANEs. For ephemeral ANEs, the defining resource is the
Property
   Map part of the multipart response; the defining resource of
   persistent ANEs is the Property Map on which standalone queries for
   properties of persistent ANEs are made.

.- Section 6.4.2, Intended semantics text – it is not clear the association
> of persistent to ephemeral. Why is this? What is the purpose?
>
.- Section 6.4.2, last paragraph – The value of ephemeral is provided, but
> what would be the value of persistent one?
>

It looks that we need a bit more update. We will finalize the update

Re: [alto] Review of draft-ietf-alto-path-vector-11

[kaigao]

Hi Luis,

Thank you very much for the review. We will address the comments accordingly.

Best,
Kai

2020-10-26 05:01:25"LUIS MIGUEL CONTRERAS MURILLO" 
wrote:

Hi all,

 

I have performed a review of the draft, with comments as follows:

 

/* Technical comments */

.- Section III Terminology – Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.

.- Section 4.2 – it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.

.- Section 4.2 – there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.

.- Section 5.1.3, 2nd paragraph – “… and the response must return and only 
return the selected properties …” – two comments here: (1) must should be MUST 
in this context?; (2) “… and only return …” – probably redundant, better either 
remove or rephrase as “MUST/must only return”.

.- Figure 4 – the figure shows two response messages, but some questions arise 
in this respect: (1) what happens if second response is not received?; (2) what 
happens if only the second response is received? Is it silently discarded?; (3) 
is there some expected timer for accounting time-out in the responses? It is 
mentioned in bullet 2 that there could be some processing among messages, so it 
can be assumed that some maximum delay could happen between both responses.

.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, 
rephrase/review.

.- Section 6.4.2, Intended semantics text – it is not clear the association of 
persistent to ephemeral. Why is this? What is the purpose?

.- Section 6.4.2, last paragraph – The value of ephemeral is provided, but what 
would be the value of persistent one?

.- Section 9.3, 1st and past paragraph – they seem inconsistent since in one 
hand the first claims incompatibility while the second claims compatibility. 
Please, review them.

.- Section 9.4 – When used with the calendar extension, should the ANE be 
always persistent? I mean, same ANE for all the time views, otherwise could not 
properly work. Please, clarify.

 

/* Editorial comments */

.- Section I Introduction, pag. 5, penultimate paragraph – “… Path Vector 
response involve two ALTO …” -> “… Path Vector response involves two ALTO …”

.- Section I Introduction, pag. 5, last paragraph – “… the rest of the document 
are organized …” -> “… the rest of the document is organized …”

.- Section III Terminology stands that the document extends the terminology 
used in RFC 7285 and in Unified Properties draft. This implies some precedence 
in the edition of the documents as RFCs, if they finally progress to that 
stage. So I would recommend to add a note for RFC Editor mention that 
precedence (note to be remove once the document becomes a RFC).

.- Section 5.1 – the text (2nd paragraph) auto-refers to section 5.1. 
Redundant, better to remove.

.- Section 5.2 – 1st paragraph – correct -> correctly

.- Section 5.3, last sentence before Figure 4 – “… the ANEs in a single 
response …” -> “… the ANEs in an additional response …”

.- Section 6.6 – The second paragraph starts with NOTE; probably better to 
rephrase writing it as a normal paragraph.

.- Section 9.2, last sentence – “compatible” -> “compatibility”

 

Best regards

 

Luis

 

__

Luis M. Contreras

 

Technology and Planning

Transport, IP and Interconnection Networks

Telefónica I+D / Global CTIO unit / Telefónica

 

Distrito Telefónica, Edificio Sur 3, Planta 3

28050 Madrid

España / Spain

 

Skype (Lync): +34 91 312 9084

Mobile: +34 680 947 650

luismiguel.contrerasmuri...@telefonica.com

 

 




Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus 

[alto] Review of draft-ietf-alto-path-vector-11

[LUIS MIGUEL CONTRERAS MURILLO]

Hi all,

I have performed a review of the draft, with comments as follows:

/* Technical comments */
.- Section III Terminology - Path Vector bullet. Please, rephrase the 
description, it is hard to understand, especially the second sentence. Not 
clear.
.- Section 4.2 - it refers to recent use cases, but it is not relevant how 
recent are the use cases (in fact, for this, see my next comment). So I would 
suggest to remove any reference to recent either in the title or the text. 
Simply refer to use cases.
.- Section 4.2 - there is a reference to an expired I-D which last from 2013 
(so pretty old). I would suggest to remove such a reference since somehow the 
potential use cases it refers should be present here.
.- Section 5.1.3, 2nd paragraph - "... and the response must return and only 
return the selected properties ..." - two comments here: (1) must should be 
MUST in this context?; (2) "... and only return ..." - probably redundant, 
better either remove or rephrase as "MUST/must only return".
.- Figure 4 - the figure shows two response messages, but some questions arise 
in this respect: (1) what happens if second response is not received?; (2) what 
happens if only the second response is received? Is it silently discarded?; (3) 
is there some expected timer for accounting time-out in the responses? It is 
mentioned in bullet 2 that there could be some processing among messages, so it 
can be assumed that some maximum delay could happen between both responses.
.- Section 6.2.4, last paragraph - Hard to understand, not clear. Please, 
rephrase/review.
.- Section 6.4.2, Intended semantics text - it is not clear the association of 
persistent to ephemeral. Why is this? What is the purpose?
.- Section 6.4.2, last paragraph - The value of ephemeral is provided, but what 
would be the value of persistent one?
.- Section 9.3, 1st and past paragraph - they seem inconsistent since in one 
hand the first claims incompatibility while the second claims compatibility. 
Please, review them.
.- Section 9.4 - When used with the calendar extension, should the ANE be 
always persistent? I mean, same ANE for all the time views, otherwise could not 
properly work. Please, clarify.

/* Editorial comments */
.- Section I Introduction, pag. 5, penultimate paragraph - "... Path Vector 
response involve two ALTO ..." -> "... Path Vector response involves two ALTO 
..."
.- Section I Introduction, pag. 5, last paragraph - "... the rest of the 
document are organized ..." -> "... the rest of the document is organized ..."
.- Section III Terminology stands that the document extends the terminology 
used in RFC 7285 and in Unified Properties draft. This implies some precedence 
in the edition of the documents as RFCs, if they finally progress to that 
stage. So I would recommend to add a note for RFC Editor mention that 
precedence (note to be remove once the document becomes a RFC).
.- Section 5.1 - the text (2nd paragraph) auto-refers to section 5.1. 
Redundant, better to remove.
.- Section 5.2 - 1st paragraph - correct -> correctly
.- Section 5.3, last sentence before Figure 4 - "... the ANEs in a single 
response ..." -> "... the ANEs in an additional response ..."
.- Section 6.6 - The second paragraph starts with NOTE; probably better to 
rephrase writing it as a normal paragraph.
.- Section 9.2, last sentence - "compatible" -> "compatibility"

Best regards

Luis

__
Luis M. Contreras

Technology and Planning
Transport, IP and Interconnection Networks
Telefónica I+D / Global CTIO unit / Telefónica

Distrito Telefónica, Edificio Sur 3, Planta 3
28050 Madrid
España / Spain

Skype (Lync): +34 91 312 9084
Mobile: +34 680 947 650
luismiguel.contrerasmuri...@telefonica.com





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou 

[alto] Review for draft-ietf-alto-path-vector-11

[Qiao Xiang]

Dear all,

The following is my review of the current version of the path vector draft.
I do not have major objection about the design. The review consists of two
parts: presentation and clarity of the draft, and design issues. Hope it
helps.

*Presentation and clarity of the draft*:

1. In Abstract: "on particular network components or elements", it looks
like the word element is no longer used in the remaining of the draft,
hence should be removed.

2. What is network component? The draft did not give a clear definition. In
Abstract, it says "Examples of such abstracted components are networks,
data centers or links.", and later in Section 3, it says "An Abstract
Network Element is a representation of network components. It can be a
link, a middlebox, a virtualized network function (VNF), etc., or their
aggregations." I would suggest a clear definition about network component
in Section 3.

3. Mixed use of "network component" and "intermediate network component".
For example, in Section 3, it says "An Abstract Network Element is a
representation of network components.", but in Section 5, it says
"introduces Abstract Network Element (ANE) as the abstraction of
intermediate network components". There are a couple of more spots of this
mixed use throughout the draft.

4. In Abstract: "Each ANE is defined by a set of properties.", but in
Section 3: "In a response, each ANE is represented by a unique ANE Name."
Which one is the intended definition? My understanding is that the one in
Section 3 seems more appropriate.

5. In the example in Section 4.1, eh3 does not seem to be used anywhere. I
would suggest removing it to make things simple and clean.


*Design issues*:

The first two issues I have are the questions I asked previously in the
mailing list under the thread "[alto] Comments on the Path-Vector draft
during IETF 102" in August, 2018 (
https://mailarchive.ietf.org/arch/msg/alto/rt0t_K-PuWcTiIlEn6XuTdpGL48/). I
did not see these two comments appropriately addressed/discussed in the
current draft:

  6. The semantics of "array of ANEs". In particular, in Section 3, it says
"(The path vector) conveys the information that the path between a
source and a destination traverses the ANEs in the same order as
they appear in the Path Vector." Must we require this traversal order in
the response? Taking the maximal bandwidth example we have always been
using, does the user need the traversal order of ANEs? Would enforcing such
an order increase the implementation complexity of the PV extension? In a
response email from Jensen in the same thread, he said we may add strong
use cases to motivate the necessity of "array" semantics, but it does not
seem to be added in this draft.

  7. Handle multipath (and potentially multicast).
In my previous email, I give a proposal to address this issue in PV, which
is motivated by RFC7911 ("Advertisement of Multiple Paths in BGP"). Jensen
replied that it may be better to consider handling multipath in a separate
document, but I want to use this review opportunity to ask the opinion of
all WG members about this issue.

Next, in Section 11 (security consideration), I have two more comments.

  8. For the measures to mitigate the risk of exposing fine-grained
internal network structure, in some earlier papers by our WG members [1, 2,
3, 4], we already proposed certain mechanisms to mitigate this risk, i.e.,
a minimal-feasible region compression algorithm [1, 2] and a
feasible-region obfuscation protocol. I would suggest the draft adding
these references.

  9. for the discussion on the availability of ALTO services, I disagree
with the sentence "It is known that the computation of Path Vectors is
unlikely to be cacheable, in that the results will depend on the particular
requests (e.g., where the flows are distributed)." In [3, 4], we already
proposed a precomputation-and-projection mechanism to improve the
scalability and availability of the PV service. As such, I feel this issue
is not introduced by PV, but rather an inherent issue of the ATLO protocol.


[1] Kai Gao, Qiao Xiang, Xin Wang, Yang Richard Yang, Jun Bi:
NOVA: Towards on-demand equivalent network view abstraction for network
optimization. IWQoS 2017: 1-10
[2] Kai Gao, Qiao Xiang, Xin Wang, Yang Richard Yang, Jun Bi:
An Objective-Driven On-Demand Network Abstraction for Adaptive
Applications. IEEE/ACM Trans. Netw. 27(2): 805-818 (2019)
[3] Qiao Xiang, J. Jensen Zhang, X. Tony Wang, Y. Jace Liu, Chin Guok,
Franck Le, John MacAuley, Harvey Newman, Yang Richard Yang:
Fine-grained, multi-domain network resource abstraction as a fundamental
primitive to enable high-performance, collaborative data sciences. SC 2018:
5:1-5:13
[4] Qiao Xiang, Jingxuan Jensen Zhang, Xin Tony Wang, Yang Jace Liu, Chin
Guok, Franck Le, John MacAuley, Harvey Newman, Yang Richard Yang:
Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network
Resource Discovery. IEEE J. Sel. Areas Commun. 37(8): 1924-1940 (2019)



Best
Qiao
--