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

[Jen Linkova <[e-mail]>]

On Thu, Jun 27, 2019 at 5:10 PM Éric Vyncke via Datatracker
<[e-mail]> wrote:
> 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)

I've tried ;)

The diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-enterprise-pa-multihoming-09
The -09: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09

Please let me know if I have not addressed your comments.

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

AFAIR v6ops@ was asked to review and the draft was presented there. As
drafts are usually adopted by one group, it ended up in RTGWG - maybe
Ron could recall the details?

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

Rephrased.

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

Well, I'd argue that e2e was a design goal...but I might be wrong here..

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

Added a paragraph.
"Another issue with asymmetric traffic flow (when the egress traffic

   leaves the site via one ISP but the return traffic enters the site
   via another uplink) is related to stateful firewalls/middleboxes.
   Keeping state in that case might be problematic, even impossible."

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

I've updated the section to put some context there. In particular:

"(topologies with two redundant routers each having two uplinks to

   different ISPs plus a tunnel to a headoffice acting as fifth one are
   not unheard of)."


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

Fixed.

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

I'd prefer to keep it as a reference to what could be done.
Potentially. If someone thinks it's a good idea. Or at least as a
reference to smth which we tried to do - so readers would not reinvent
a wheel.

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

Because in this section the draft makes some conclusions on what is
the right solution...But if you think it's misleading I could update
the text.

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

More reliable than ICMPv6 in that case....

-- Section 5.7.1 --
>
> The DNS issue should also probably refer to RFC 7556 (PvD).

Done.

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

I've actually added a few more references to PvD to the text.

> -- Section 7.3 --
>
> There should be a reference to MPTCP or ICE.

MPTCP and  multipath capabilities in QUIC are mentioned.

>
> == NITS ==
>
> -- Abstract --
>
> I would suggest to add the word "IPv6" in the abstract as well for clarity.

It's the only modern version of IP we have...The default one...;)))
Anyway, added ;)

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

All fixed.

> -- Section 4 --
>
> Please expand ULA before first use (+ reference)

I've actually added it to the Terminology section.

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

Fixed.

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

Fixed.

>
> -- Section 5.5.2 --
>
> Please expand GUA before first use.

Added to the Terminology section.

-- 
SY, Jen Linkova aka Furry