Re: Roman Danyliw's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)

Jen Linkova <furry13@gmail.com> Mon, 01 July 2019 14:32 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D9D1200FD; Mon, 1 Jul 2019 07:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgKLTavba4in; Mon, 1 Jul 2019 07:32:46 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51ED31200FB; Mon, 1 Jul 2019 07:32:46 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id j19so14825944qtr.12; Mon, 01 Jul 2019 07:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sllcCuhCrzQgsWbQDzArvK+Rq78PFrndT8g7Op5epBA=; b=PW3IVPqKT8u3LSlUhwUr21I8SowamngXZkBBts9YEVK5frkjeyWYy1Xab54PxoKj0h oNC7lmI9C3deII/2va+yU6k0jFWuGTHx0s72B9eUHlEbrn7zFDb3Wbb/niORGKuyrW0a WB4zoUjmqoGvyiUfwktCWDnNaA6CWGUB73kSvUGD50tjmNDwbFq1u0LqFDYDyYxJNGbT CUAamQBFvUjuBUmveoHWywkkNv0TnZulfPx5qMMW00mPbs6quKQV2eILi0H5kxKDPwwM CLZoE1WWVq27+l0f1ePmtPxdjjqLPxk7LFzvJGrY3StyUGyhwa/stDRbJkh9LEFBEy68 hRrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sllcCuhCrzQgsWbQDzArvK+Rq78PFrndT8g7Op5epBA=; b=ABRs3mtdLw/V8bCTJhADUM0FxVd+wLe0Pskq6vIGaH9Rn3I7RETdiDj1d4AdJVTcx4 5fx0qshj8OnyoGmbJ6YRBrsR+kLXzxJyEEL9Nzvp4Ul2NoXUnO45EFQ/mr8kfLvs1tZ/ +UF4quOgBmx7POu+nptFLyw0VkQp7yfWqrLXa5X6aL+MbK7P21A7hJJjqAPPF7Gh2MfU HiDYR6oBdXPvIyqN4+WYCBGIRtQSghekXoEude5ERgJWVyWjOr8zImTH+RlxLe58ONiQ AEvvnyjGfsd6ZEC6xkjexMR/SoUjqDMRxdvXhBD2YX4JrFq5VHLRodZKcND+JXoQkiwj s0XA==
X-Gm-Message-State: APjAAAVmbA7B2yam1c03nWwjCPSvJkqu8XSts85tEmZc0lNgT+NBsktN G9RiHsMhuZfGTHWlXQJV+YgrQxLvIFMeXySAuBo=
X-Google-Smtp-Source: APXvYqyOQyiEjhjlBnH4QEpjKFsONDzZYQSB7laEBJBeVot6oiVov32pqmGfZeTPHGjKX0hF3yXf8bh3c8TU8W/JBKo=
X-Received: by 2002:ac8:2e59:: with SMTP id s25mr20499331qta.94.1561991565215; Mon, 01 Jul 2019 07:32:45 -0700 (PDT)
MIME-Version: 1.0
References: <156155382586.20201.14088878618004862906.idtracker@ietfa.amsl.com>
In-Reply-To: <156155382586.20201.14088878618004862906.idtracker@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 2 Jul 2019 00:32:34 +1000
Message-ID: <CAFU7BARyZDUSi=6sqr+9hemR90BRJhxWyT8zN90hwHoWv81ELQ@mail.gmail.com>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, Ronald Bonica <rbonica@juniper.net>, rtgwg-chairs <rtgwg-chairs@ietf.org>, draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, Routing WG <rtgwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/2hz4AcAQRJNb9mOSOgugab429yI>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 01 Jul 2019 14:32:48 -0000

Hi Roman,

Thanks a lot for reviewing such a long draft ;)

On Wed, Jun 26, 2019 at 10:57 PM Roman Danyliw via Datatracker
<noreply@ietf.org>; wrote:
> A few questions and comments:
>
> (1) Section 1. Per “That is, some routers must be capable of some form of
> Source Address Dependent Routing (SADR), if only as described in [RFC3704]”,
> I’m not sure what minimal SADR technique is being described in RFC3704.  What
> section?

Added the link to the section 4.3 of [RFC3704].

> (2) Section 3.5.  Per “However, when evaluating scalable implementations of the
> solution, it would be reasonable to assume that the maximum number of ISPs that
> a site would connect to is five”, what is the basis of the up to _five_ ISPs?

Added some clarification:
"
(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)."

> (3) Section 5. Per “If all of the ISP uplinks are working, the choice of source
> address by the host may be driven by the desire to load share across ISP
> uplinks …”, how does an individual host have enough information to make that
> kind of decision?

Well, it's a bit out of scope of this draft to discuss all possible
mechanisms but I've added some clarification by adding the following
text:

"
(if some information
uplinks is not working, then the choice of source address by the host
about various path properties has been made availabe to the host
can determine if packets get dropped. somehow - see
[I-D.ietf-intarea-provisioning-domains] as an example)."

> (4) Section 5.  Per “An external host initiating communication with a host
> internal to a PA multihomed site will need to know multiple addresses  for that
> host in order to communicate with it using different ISPs to the multihomed
> site.”, what is mean by “in order to communicate with it using different ISPs”?
>  Why would being multi-homed this matter?  Wouldn’t one IP address be
> sufficient?

Added a sentence to clarify:
"(knowing just one address would undermine all benefits of redundant
connectivity provided by multihoming)."

>Section 9.  Per “It recommends that a given host verify the
> original packet header included into ICMPv6 error message was actually sent by
> the host itself”, is this guidance to the host or to network stack implementers?

I'm not sure if it does matter here (at this draft level of
granularity "host" is mostly equal to 'it's network stack".
Do you have any suggestions on how you'd like it to be phrased? For
I'm a bit lost here..

> (5) Section 9.  Given the current (helpful) text about the threat of a spoofed
> ICMPv6 message, it would be equally useful to discuss the threat to the other
> approach in Section 5 (i.e., DHCPv6) – a rogue DHCPv6 server.

The reason DHCPv6 is not discussed is that the draft concludes that
it's not a  suitable mechanism anyway. The draft concludes that RAs
should be used (with some help of ICMPv6) and the discusses the
security aspect of the recommended approach (ICMPv6 + Neighbor
Discovery/RAs)

> A few editorial nits:

All fixed, thanks for pointing them out!

-- 
SY, Jen Linkova aka Furry