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

Jen Linkova <> Mon, 01 July 2019 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1E1412031E; Mon, 1 Jul 2019 08:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mri24rRgLyly; Mon, 1 Jul 2019 08:09:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80A9E120344; Mon, 1 Jul 2019 08:09:02 -0700 (PDT)
Received: by with SMTP id d15so11251226qkl.4; Mon, 01 Jul 2019 08:09:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mTRIUDDMpJHzl7yu8Ju0M37viRWUkIN0BLjDptKN2YA=; b=ECUgmzNL9XsVA7q5KojB4Ow0vZaZUuJqHDocDjugbDseXm2dp0QqEKpI1MDM/KcFX3 KxDNYglu0McjYW+wiKoe8KKz2dyjPAoEYbJ1ENpEKWrZtiOcs5pJdsaj7jUfNRKKBwbH TmqsAW7fiYI4mFjnRsMiu8F7473Zuc+OgZmWAdLPZa4BzLLV7y5k+PPhAVbabsHMW33w nh9fosD+FqZkPKl0GRpsFG94vTqsq0KvttahtgPJGcQHBl1mHK1miJ0Fa/cogvEM8Di9 uVxxGJJ3p9P8kUOjbwEtvF3ldua+eN3J+ujg33sTwwUCehbPwzpfhLFS26Jd/PsOjno4 /dlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mTRIUDDMpJHzl7yu8Ju0M37viRWUkIN0BLjDptKN2YA=; b=dakoUVL5D4uk33Cb3qlChG3OJm3PIgYBa8GXBGVwsop5Ir4ff1cqutDP+OGR/iGYUo YW4i+U95G57bKW4WyfstCpBFJd6gU6hfLfre88r1ij80I5dqZu4dhJmdnQMC7vQUWPnn w50GeIZ2THDJY0OLoEmSYasCqhJkXNcWVSLOXz+FD86/4EegukpFVGh1Rw71mOEsZlZP pUOGFea4Zozb02nLEByMyTJpIMJbmKA7jCadkIiLULIqwrZE4sXXGlRDy5uXACjccEx0 Fz5EZvGq7hUcNeG7en+4dDdv51/wYwL2bhpDTeA1tCKr9aofN/nG168aUrxJia6vbkI2 tv5Q==
X-Gm-Message-State: APjAAAXe8U9zmhduryKS1bF1KYoA5TsBbFoU1EoxMhpVkn+g2KU+7+ve StQy6sGi1WFRC92+1jll+/Sh4iJH4wGqVkhl8IE=
X-Google-Smtp-Source: APXvYqzAolfSmmGs7kAh5n2sdQEkjIiqZKI+hN5bPNzX1zNgdE9VIk+Md6Px3KJwROqEJ4m7XULrc7q0tDPge0C8Tek=
X-Received: by 2002:a05:620a:15cd:: with SMTP id o13mr20544323qkm.417.1561993741383; Mon, 01 Jul 2019 08:09:01 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Tue, 2 Jul 2019 01:08:50 +1000
Message-ID: <>
Subject: =?UTF-8?Q?Re=3A_=C3=89ric_Vyncke=27s_No_Objection_on_draft=2Dietf=2Drtgwg=2D?= =?UTF-8?Q?enterprise=2Dpa=2Dmultihoming=2D08=3A_=28with_COMMENT=29?=
To: =?UTF-8?B?w4lyaWMgVnluY2tl?= <>
Cc: The IESG <>, Ronald Bonica <>, rtgwg-chairs <>,, Routing WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jul 2019 15:09:16 -0000

On Thu, Jun 27, 2019 at 5:10 PM Éric Vyncke via Datatracker
<>; 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:
The -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.


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


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


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


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

Added to the Terminology section.

SY, Jen Linkova aka Furry