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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Mon, 29 Nov 2021 02:59:54 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-alto-path-vector-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Vijay Gurbani for the shepherd's write-up as it seems to
indicate a low number of WGLC reviews.

I hope that this helps to improve the document,

Regards,

-éric

While it seems clear that knowledge of the path to some endpoints can help the
applications to select the "most suitable" endpoints to connect to, I wonder
whether knowledge about a single ISP will be enough. Assuming that a single ISP
is the topic of this I-D as the singular form "ISP" is used rather than "ISPs".

Nothing bad of course, but I read this IETF draft more like an IRTF draft,
i.e., it reads more like research and conjectures.

As only "max-reservable-bandwidth" is actually specified to this document, I
wonder whether other characteristics/properties could also have been defined,
e.g., max-latency, max-packet-drop, ... ?

-- Section 3 --
May I assume that the first paragraph should be removed before publication? If
so, then please add a note to the RFC Editor.

-- Section 4.2.1 --
On figure 5, please use consistently "v" or "V" but not a mix. Unsure whether
"f1" label (?) should be in the picture as it brings nothing.

-- Section 4.2.2 --
I find amusing to see the old telephony concept of "central office(CO)" being
used in an IETF draft ;-)

== NITS ==

-- Section 1 --
Please expand IRD at first use.

-- Section 8.1 (and other places) --
Please use only lowercase in IPv6 addresses (and thank you for finally using
some IPv6 examples)

---

From: [email-masked]
Date: Wed, 1 Dec 2021 01:01:02 +0800 (GMT+08:00)

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.

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

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