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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 1 Dec 2021 15:34:50 +0000

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

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

---

From: [email-masked]
Date: Mon, 6 Dec 2021 11:33:52 +0800 (GMT+08:00)

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

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.