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

Mirja Kühlewind via Datatracker <noreply@ietf.org> Wed, 26 June 2019 15:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtgwg@ietf.org
Delivered-To: rtgwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBED41202AD; Wed, 26 Jun 2019 08:11:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, Ron Bonica <rbonica@juniper.net>, rtgwg-chairs@ietf.org, rbonica@juniper.net, rtgwg@ietf.org
Subject: =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-rtgwg-ent?= =?utf-8?q?erprise-pa-multihoming-08=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Message-ID: <156156191295.20067.4187670605460699632.idtracker@ietfa.amsl.com>
Date: Wed, 26 Jun 2019 08:11:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/yFrLOY4XSdE8ediglt19_Ae3yRE>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 26 Jun 2019 15:11:53 -0000

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:


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?


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.

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/