Éric Vyncke's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 27 June 2019 07:10 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: rtgwg@ietf.org
Delivered-To: rtgwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D92612004C; Thu, 27 Jun 2019 00:10:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, Ron Bonica <rbonica@juniper.net>, rtgwg-chairs@ietf.org, rbonica@juniper.net, rtgwg@ietf.org
Subject: Éric Vyncke's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <156161940756.21711.148183930887680940.idtracker@ietfa.amsl.com>
Date: Thu, 27 Jun 2019 00:10:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/zuwPwC2T7LgDDIexl2hhkCORKmg>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2019 07:10:08 -0000
É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.
- Éric Vyncke's No Objection on draft-ietf-rtgwg-en… Éric Vyncke via Datatracker
- Re: Éric Vyncke's No Objection on draft-ietf-rtgw… Jen Linkova
- Re: Éric Vyncke's No Objection on draft-ietf-rtgw… Eric Vyncke (evyncke)