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:09 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 633921202FE; Mon, 1 Jul 2019 08:09:57 -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 f5XRi_JomZub; Mon, 1 Jul 2019 08:09:55 -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 197D7120341; Mon, 1 Jul 2019 08:09:55 -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 1hhxwG-00080m-J7; Mon, 01 Jul 2019 17:09:52 +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: <CA+b+ERkmOKfj7gK4iJ4TzMUXC3nSvfiEJpqg-KUhttUTWB9B2g@mail.gmail.com>
Date: Mon, 1 Jul 2019 17:09:52 +0200
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, RTGWG <rtgwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <95758B78-A3E6-484C-828A-9E0F0CDB5D59@kuehlewind.net>
References: <156156191295.20067.4187670605460699632.idtracker@ietfa.amsl.com> <CA+b+ERkmOKfj7gK4iJ4TzMUXC3nSvfiEJpqg-KUhttUTWB9B2g@mail.gmail.com>
To: Robert Raszuk <rraszuk@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1561993795;329d4bd7;
X-HE-SMSGID: 1hhxwG-00080m-J7
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/YxZUSOV0f9-V2_g1z-4YWTnqP8k>
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:10:09 -0000

Hi Robert,

Thanks for you quick reply. Please see also my reply to Jen’s mail.

Mirja



> On 26. Jun 2019, at 18:25, Robert Raszuk <rraszuk@gmail.com>; wrote:
> 
> Hi Mirja,
> 
> > my expected behaviour from a multi-homed
> > network would have been that my traffic is 
> > simply rerouted to the other ISP.
> 
> That expectations can be addressed today with PI address blocks or by use of third party virtual PA address anchor nodes (think as example LISP RTRs). This proposal is about use of PA blocks. I asked this question long time ago and got answer that PI IPv6 blocks are not easily accessible. One would hope v6 would at least solve that issue. 
> 
> With PA addresses unfortunately your TCP will fail resulting in need to re-establish the session I am afraid. One more reason to think about QUIC ... 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> On Wed, Jun 26, 2019 at 5:12 PM Mirja Kühlewind via Datatracker <noreply@ietf.org>; wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-rtgwg-enterprise-pa-multihoming-08: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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.
> 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?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.
> 
> 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/
> 
> 
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg