Subject: Re: [alto] Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 6 Dec 2021 08:29:23 +0000

The new text looks good to me, thank you

-éric

From: "[email-masked]" <[email-masked]>
Date: Monday, 6 December 2021 at 04:34
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Re: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)

Hi Éric,

Thanks for the comments and please see the replies inline.

Best,
Kai

> -----Original Messages-----
> From: "Eric Vyncke (evyncke)" <[email-masked]>
> Sent Time: 2021-12-01 23:34:50 (Wednesday)
> To: "[email-masked]" <[email-masked]>
> Cc: "The IESG" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)
>
> Hello Kai,
>
> Thank you for your prompt reply and your actions on the document.
>
> Please find some further comment below, look for EV>
>
> Regards
>
> -éric
>
>
> On 30/11/2021, 18:01, "[email-masked]" <[email-masked]> wrote:
>
>     Hi Éric,
>
>     Thanks for the review and please see the responses inline.
>
>     Best,
>     Kai
>
>
>     &gt; -----Original Messages-----
>     &gt; From: "Éric Vyncke via Datatracker" <[email-masked]>
>     &gt; Sent Time: 2021-11-29 18:59:54 (Monday)
>     &gt; To: "The IESG" <[email-masked]>
>     &gt; Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
>     &gt; Subject: Éric Vyncke's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)
>     &gt;
>     &gt; Éric Vyncke has entered the following ballot position for
>     &gt; draft-ietf-alto-path-vector-19: No Objection
>     &gt;
>     &gt; When responding, please keep the subject line intact and reply to all
>     &gt; email addresses included in the To and CC lines. (Feel free to cut this
>     &gt; introductory paragraph, however.)
>     &gt;
>     &gt;
>     &gt; Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>     &gt; for more information about how to handle DISCUSS and COMMENT positions.
>     &gt;
>     &gt;
>     &gt; The document, along with other ballot positions, can be found here:
>     &gt; https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
>     &gt;
>     &gt;
>     &gt;
>     &gt; ----------------------------------------------------------------------
>     &gt; COMMENT:
>     &gt; ----------------------------------------------------------------------
>     &gt;
>     &gt; Thank you for the work put into this document.
>     &gt;
>     &gt; Please find below some non-blocking COMMENT points (but replies would be
>     &gt; appreciated even if only for my own education), and some nits.
>     &gt;
>     &gt; Special thanks to Vijay Gurbani for the shepherd's write-up as it seems to
>     &gt; indicate a low number of WGLC reviews.
>     &gt;
>     &gt; I hope that this helps to improve the document,
>     &gt;
>     &gt; Regards,
>     &gt;
>     &gt; -éric
>     &gt;
>     &gt; While it seems clear that knowledge of the path to some endpoints can help the
>     &gt; applications to select the "most suitable" endpoints to connect to, I wonder
>     &gt; whether knowledge about a single ISP will be enough. Assuming that a single ISP
>     &gt; is the topic of this I-D as the singular form "ISP" is used rather than "ISPs".
>
>     Yes, this document is targeting the single ISP case. For arbitrary queries, a single
>     ISP may not have the knowledge of the full Internet paths. However, there are cases
>     where the two endpoints are inside the same "ISP", for example, ISP-hosted CDN/edge,
>     tenant interconnection in a single public cloud platform, SDN, etc. Some scenarios are
>     discussed in previous ALTO sessions, including the ISP-hosted CDN service in Telefonica,
>     and edge-assisted data transfer of Tencent (content provider) and China Telecom (ISP).
>     Also, there are approaches that generate the path vectors from end-to-end measurement
>     data that do not even require knowledge from an ISP. Thus, we believe this extension can
>     still be useful.
>
> EV> this is indeed quite logical and sensible. I would suggest mentioning this in the introduction with a sentence
> EV>  like "This document is mainly applicable when there is a single ISP between the ALTO client, ALTO server, and the content server".

I see the point. However, the wording might be slightly different as the restriction

is mainly on the source and destination PIDs/endpoints, which may or may not be

directly related to the locations of the ALTO client and server. The proposed text is

as below:

NEW:

    As a single ISP may not have the knowledge of the full Internet paths between
    arbitrary endpoints, this document is mainly applicable 1) when there is a
    single ISP between the requested source and destination PIDs or endpoints, for
    example, ISP-hosted CDN/edge, tenant interconnection in a single public cloud
    platform, etc.; or 2) when the Path Vectors are generated from end-to-end
    measurement data.

>
>     &gt;
>     &gt; Nothing bad of course, but I read this IETF draft more like an IRTF draft,
>     &gt; i.e., it reads more like research and conjectures.
>     &gt;
>
>     Fair enough. Any suggestion how we can cook more IETF gradient into the document?
>
> EV> Not really except deep rewriting
>
>     &gt; As only "max-reservable-bandwidth" is actually specified to this document, I
>     &gt; wonder whether other characteristics/properties could also have been defined,
>     &gt; e.g., max-latency, max-packet-drop, ... ?
>     &gt;
>
>     Good question. We choose these two initial properties as they are taken from
>     use cases that we already see or are pushing forward the deployment of. Note
>     the max-reservable-bandwidth is important to identify bottlenecks inside a
>     network that can be crucial to determine the end-to-end reservation. But for
>     latency and loss rate, the end-to-end result (i.e., using the base ALTO
>     protocol) is usually sufficient to select endpoints.
>
>     &gt; -- Section 3 --
>     &gt; May I assume that the first paragraph should be removed before publication? If
>     &gt; so, then please add a note to the RFC Editor.
>
>     You are right. The paragraph is intended to be a note to the RFC editor and should
>     be removed before publication. We will make this clear by changing "Note" to "Note
>     to the RFC Editor".
>
>     &gt;
>     &gt; -- Section 4.2.1 --
>     &gt; On figure 5, please use consistently "v" or "V" but not a mix. Unsure whether
>     &gt; "f1" label (?) should be in the picture as it brings nothing.
>
>     Good catch! We will use lowercase "v" for consistency and remove "f1" in the next
>     revision.
>
>     &gt;
>     &gt; -- Section 4.2.2 --
>     &gt; I find amusing to see the old telephony concept of "central office(CO)" being
>     &gt; used in an IETF draft ;-)
>
>     Indeed. But we do see the term being constantly used in literature related to edge
>     computing (perhaps due to historical reasons that the servers are co-located with
>     the central offices?). Actually it is taken from the [SEREDGE] document and we feel
>     it's better to use the term as it is to avoid misunderstanding.
>
>     &gt;
>     &gt; == NITS ==
>     &gt;
>     &gt; -- Section 1 --
>     &gt; Please expand IRD at first use.
>
>     Will do.
>
>     &gt;
>     &gt; -- Section 8.1 (and other places) --
>     &gt; Please use only lowercase in IPv6 addresses (and thank you for finally using
>     &gt; some IPv6 examples)
>     &gt;
>     &gt;
>
>     Will do.
>     </[email-masked]></[email-masked]>
>