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

Mirja Kuehlewind <> Mon, 01 July 2019 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9706A120128; Mon, 1 Jul 2019 08:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b8u8VAXLJbUx; Mon, 1 Jul 2019 08:08:24 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id DEAC61200FA; Mon, 1 Jul 2019 08:08:23 -0700 (PDT)
Received: from ([2001:16b8:2cd0:6f00:44a9:8311:ac51:f103]); authenticated by 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 <>
In-Reply-To: <>
Date: Mon, 1 Jul 2019 17:08:19 +0200
Cc: Ronald Bonica <>, Routing WG <>, rtgwg-chairs <>, The IESG <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Jen Linkova <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1hhxul-0005iL-OR
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:08:27 -0000

Hi Jen,

Please see below.

> On 1. Jul 2019, at 16:37, Jen Linkova <>; wrote:
> Hi Mirja,
> On Thu, Jun 27, 2019 at 1:12 AM Mirja Kühlewind via Datatracker
> <>; 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:
> 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.



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