Re: [alto] Review of draft-ietf-alto-path-vector-11 Thu, 19 November 2020 09:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FB193A12FA for <>; Thu, 19 Nov 2020 01:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSNp6plgzdww for <>; Thu, 19 Nov 2020 01:47:37 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 9A78C3A12F6 for <>; Thu, 19 Nov 2020 01:47:34 -0800 (PST)
Received: by ajax-webmail-app1 (Coremail) ; Thu, 19 Nov 2020 17:47:25 +0800 (GMT+08:00)
X-Originating-IP: []
Date: Thu, 19 Nov 2020 17:47:25 +0800 (GMT+08:00)
X-CM-HeaderCharset: UTF-8
To: "" <>
Cc: "Jan Seedorf" <>, "Vijay Gurbani" <>, "Qin Wu" <>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT5.0.13 build 20200820(b2b8cba1) Copyright (c) 2002-2020 mail
In-Reply-To: <>
References: <> <>
Content-Type: multipart/alternative; boundary="----=_Part_356536_2088030796.1605779245496"
MIME-Version: 1.0
Message-ID: <>
X-Coremail-Locale: en_US
X-CM-SenderInfo: 5ndlwt3r6vu3oohg3hdfq/1tbiAQIFB138kkbUbQABsM
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <>
Subject: Re: [alto] Review of draft-ietf-alto-path-vector-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2020 09:47:41 -0000

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!




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

 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.


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 

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

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

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

  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.


  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: 

5.3.3. Order of Part Message 

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.

   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.

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


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

As SSE is finalized now, we will update this part shortly.

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

It should. We will update.


/* Editorial comments */

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

Good catch. Fixed.

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

Good catch. Fixed.

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

Good idea. Unified, which is newer, should have precedence. 

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

Chaned to "Note that ..."

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


Good catch. Fixed.

Thank you so so much!!


Best regards





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



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 confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

alto mailing list


| Y. Richard Yang <>   |
| Professor of Computer Science       |
|        |