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

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 01 July 2019 15:08 UTC

Return-Path: <ietf@kuehlewind.net>
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 9706A120128; Mon, 1 Jul 2019 08:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 b8u8VAXLJbUx; Mon, 1 Jul 2019 08:08:24 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 DEAC61200FA; Mon, 1 Jul 2019 08:08:23 -0700 (PDT)
Received: from 200116b82cd06f0044a98311ac51f103.dip.versatel-1u1.de ([2001:16b8:2cd0:6f00:44a9:8311:ac51:f103]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hhxul-0005iL-OR; Mon, 01 Jul 2019 17:08:19 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: =?utf-8?Q?Re=3A_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-rt?= =?utf-8?Q?gwg-enterprise-pa-multihoming-08=3A_=28with_DISCUSS_and_COMMENT?= =?utf-8?Q?=29?=
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CAFU7BAQqqENi5=BrAiEMDKS8p4tM4jk821RGrc9htaUDSMV6DQ@mail.gmail.com>
Date: Mon, 1 Jul 2019 17:08:19 +0200
Cc: Ronald Bonica <rbonica@juniper.net>, Routing WG <rtgwg@ietf.org>, rtgwg-chairs <rtgwg-chairs@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5D7BDBF-DA79-46D1-9B57-98CF5F2341D2@kuehlewind.net>
References: <156156191295.20067.4187670605460699632.idtracker@ietfa.amsl.com> <CAFU7BAQqqENi5=BrAiEMDKS8p4tM4jk821RGrc9htaUDSMV6DQ@mail.gmail.com>
To: Jen Linkova <furry13@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1561993703;8607c08c;
X-HE-SMSGID: 1hhxul-0005iL-OR
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/reydO7PEoTT4WAFoOa8TdD70eH0>
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 15:08:27 -0000

Hi Jen,

Please see below.

> On 1. Jul 2019, at 16:37, Jen Linkova <furry13@gmail.com>; wrote:
> 
> 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.

Yes, that was my understanding. I was rather wondering if there is an option to make it work. E.g. if the ISP doesn’t do source spoofing validation, re-routing the uplink could just work and for the downlink the “broken" ISP would need to forward to the other ISP and somehow know about this link… I guess it’s complicated and probably out of scope for this document.

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

Thanks for adding this. That’s definitely enough to resolve my discuss. Will do it right way!

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

Thanks!

Mirja


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