Re: Mirja Kühlewind's Discuss on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with DISCUSS and COMMENT)

Jen Linkova <furry13@gmail.com> Mon, 01 July 2019 14:37 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 CA0AD1200CE; Mon, 1 Jul 2019 07:37:44 -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 nteDHT1skp9z; Mon, 1 Jul 2019 07:37:43 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 0CE841200BA; Mon, 1 Jul 2019 07:37:43 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id s15so14828704qtk.9; Mon, 01 Jul 2019 07:37:42 -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=0zLpeCyLBPOqNpR46jDKmmuwqHrR5g0Or1OQCedVCeA=; b=eC2ZFoXCs9tfGkXpDLrPq/kJeouAdPywjYwGofxGVH9quVwqZAe6NWiZ6MygDzBG+k n1U6zNRyHNZY8OuuClXooR6B4aWahv6lemEeXfaWNyxwBiUGs3rM2FLpvr1V2HhM62ml PgGGPsYiWIj/OBGcqJiXTg1spxN84lMGSid+g+Byvi2vgE1wNCi6b5pWs3tcU98h2SUQ i4U/4InQEbPlBpKEnULcMdFxZbQ25GpYMYo4Nzk6/cxXCKfunv6nXsEJPxzNPZJ5UViP eUmWu0I1BorJ84qwviVESAeBO1Arh7x26zYbkaCmZSD62ZoquGd19H/7bia7IB+l6+9e n6fA==
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=0zLpeCyLBPOqNpR46jDKmmuwqHrR5g0Or1OQCedVCeA=; b=fp/78QDghM2xL6pyjk6GJ1Siifc2eJqw/UQxPzDLRhlHhbjRfACd4beHg9uHDPHQBk h6AvTTnVpLT4WlG0CUcdgptzqGt3sCFuItKPuDXtjqLLfIqKVHwOd4S9ClMygR0u9uGK dCKavexX+gdX8cNl0autIkPfa43g25yhwTmx9UI4ldzwbQ/8hvHXweAJEdfftWER4EeY w+3REuV3I6hV5akkApjwW3mnIlKi1JMqJyvU1HS4Dm48KxhWBN5sQ6PRMr4rO7ZO5ABF SHl8fwxLWBKiatBWUbG8gK/TL5s8ncunq59M2bS50vqoqUD6i+Qy/SGdhcGJJ0jmaF0f /tEg==
X-Gm-Message-State: APjAAAUlamHckpduNAFomsaR42HTvvhcP7Ix+rHMtfjcsgTtw717bkjn k78HjrfffM/XzUHd4LpIC5l9XQpCp6RniaUTJAYPOV6UrpE=
X-Google-Smtp-Source: APXvYqxpbCDEES+lDTnOpYWsT8n6spZrh2qpLN3IyavdBhtilTuYLOpOYucGcP/PqZDfFx1RFldm5VG6VdeAAOn4DKc=
X-Received: by 2002:ac8:2b90:: with SMTP id m16mr20363976qtm.384.1561991861899; Mon, 01 Jul 2019 07:37:41 -0700 (PDT)
MIME-Version: 1.0
References: <156156191295.20067.4187670605460699632.idtracker@ietfa.amsl.com>
In-Reply-To: <156156191295.20067.4187670605460699632.idtracker@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 2 Jul 2019 00:37:30 +1000
Message-ID: <CAFU7BAQqqENi5=BrAiEMDKS8p4tM4jk821RGrc9htaUDSMV6DQ@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft=2Dietf=2Drtgwg=2De?= =?UTF-8?Q?nterprise=2Dpa=2Dmultihoming=2D08=3A_=28with_DISCUSS_and_COMMENT=29?=
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
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/TMRzZfO56efmn0HHq0hVD0AD2Qo>
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:37:45 -0000

Hi Mirja,

On Thu, Jun 27, 2019 at 1:12 AM Mirja Kühlewind via Datatracker
<noreply@ietf.org>; wrote:
> I have a question basically on section 5.3, however, maybe I'm misunderstanding
> something or there is an open aspect here: If I have selected one IP address
> and then open a TCP connection and during using this TCP connection the
> connection to the selected ISP fails, my expected behaviour from a multi-homed
> network would have been that my traffic is simply rerouted to the other ISP.

Well, it would be the case if the enterprise network has its own
address space or using PI. Such networks are outside of the scope of
the document - the problem
does not exist for them. What the draft is talking about is the
scenario when a network (big or small) has to use address space
provided by an ISP.
In that case rerouting does not happen.

> However, all solutions discussed in sec 5.3. assume that the endpoint will
> switch its IP address. In case of TCP, which is not migration-capable, as
> indicated by the TSV-ART reviewer (Thanks Michael!), this would mean that I
> have to open a new TCP connection and start over again. That doesn't see
> optimal. Should this be considered?

I've added a section to discuss the solution limitations:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.7

Please let me know if more clarification is required.

> I was also wondering about the question Alvaro raised in point B. I mean even
> if unscoped forwarding is used for internal traffic, this would probably still
> prevent spoofing, however, it doesn't seem correctly that unscoped forwarding
> table are not needed anymore.

Yes, good catch, it was an artifact, removed.

> Nit:
> Sec 6 s/This document defines a way for network/This document defines a way for
> networks/ or
>           s/This document defines a way for network/This document defines a way
>           for the network/

Fixed, thanks!


-- 
SY, Jen Linkova aka Furry