Subject: Éric Vyncke's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 27 Jun 2019 00:10:07 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-rtgwg-enterprise-pa-multihoming-08: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/

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

Thank you all for the work put into this document; this is an important network
deployment use case. I second Alvaro's COMMENTs and I sincerely believe that a
revised ID could fix a lot of small details in the text in order to improve the
quality of the text (see my COMMENTs and NITs)

Also, this is mostly a tutorial / guide. I also wonder why it is in RTGWG
rather than V6OPS as part of the document is not about SADR but source address
selection. But, this is really a detail.

== COMMENTS ==

-- Abstract --

" a complete solution" while the document is not about a single solution but
rather multiple of them.

-- Section 1 --

Unsure whether "one of the goals of IPv6 is to eliminate the need for and the
use of NAT or NAPT" is true. Even, if I would hate to use NAT with IPv6, but,
this was probably not a design goal for IPv6.

-- Section 1 --

Is there a reason why the issue of stateful device (firewall, ...) requiring to
inspect all ingress/egress traffic is not mentioned in the list of issues?

-- Section 3.5 --

While I agree that the scalability of the SADR solution puts some limit on the
number of ISP, why does this document select the value 5? More generally, this
section could probably be removed.

-- Section 4 --

The "way to forward packets" does not read easily. Esp point 2), is it
"selected forwarding table" or "selected forwarding table entries" (from point
1). Or should point 1 select a specific source-scoped forwarding table rather
than forwarding table entries.

-- Section 5.2.2 --

AFAIK, pfister-6man-sadr-ra is 'dead' since 2015. Is it still worth mentioning
here ?

-- Section 5.2.4 --

Why this section have "SHOULD" in uppercase while in the other section it is in
lower case ?

-- Section 5.6 --

Using RA for influencing source-address selection is probably not "the most
reliable" as RA being multicast can be lost.

-- Section 5.7.1 --

The DNS issue should also probably refer to RFC 7556 (PvD).

-- Section 6 --

Mostly at the end of the document, there is a mention of PvD and of
draft-ietf-intarea-provisioning-domains, possibly a little late in the flow.

-- Section 7.3 --

There should be a reference to MPTCP or ICE.

== NITS ==

-- Abstract --

I would suggest to add the word "IPv6" in the abstract as well for clarity.

-- Section 1 --

Sorry but I cannot parse "...without stopping to provide ..."

-- Section 3 ---

The section title should be changed into "use cases" rather than "requirements"
as it already describes part of the solution.

-- Section 3.6 --

s/the aim of this draft/the aim of this document/ also in a couple of places.

-- Section 4 --

Please expand ULA before first use (+ reference)

-- Section 5 --
s/host internal to the multi-homed site/host inside the multi-homed site/

-- Section 5.1 --

Please put all rules explanation in a separate paragraphs (esp rules 1 & 2).

-- Section 5.5.2 --

Please expand GUA before first use.