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

Robert Raszuk <> Wed, 26 June 2019 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEF731201E4; Wed, 26 Jun 2019 09:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z8tW9rz5knD5; Wed, 26 Jun 2019 09:25:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0ACFF12004F; Wed, 26 Jun 2019 09:25:17 -0700 (PDT)
Received: by with SMTP id d126so1634885pfd.2; Wed, 26 Jun 2019 09:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z75y3V1MZNUyZAO0ZgusNPm/GbIhVEq+b9MSTpZGj0A=; b=s2yVXF9nQx91DEr4tQA//HTSGtJ3iC94IQsJTsb9LKAjXGzpdSnbZlqsU9BZieO7JI Au0foNPdH4Z0Hr/9v8PHQQVN74mR5BNuBCry1DcgD8WDywKsOX3wX//Xeq+Uz4xol3WZ FRJ5HbHSXlGaFBAiNGckTQsAFaGOewXWPuPasNlyu/xD4bAe17ENMBd+8cfFibYMhKBc J7mR0hJTS/jfOvaCATrwyeBYPq+Y5yOGcpy9IJnvMPM3bVdvf9s0U/IJv0xOTvUFjRfw WsV5Q57oO0M4U7fE5npublBQOwxDakOPj+pRbCfmZx/j0B0vUmXzhIayS8AQNz2dSiM3 hkUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z75y3V1MZNUyZAO0ZgusNPm/GbIhVEq+b9MSTpZGj0A=; b=YJTbBySX9ZAIw5fLdbUUqopy+tUgRtdVje10ELiTe1VU624ExC4NH0LMcll7zDXxXk WiQno29v4JJzwk8EqXSEtlGwNYqzsdwAKxZbzsgXHkaOLI7F8Hg8wu3JeB8a1dzbHS8D pEskrJZjkpEakuZWM0CMwuyn6SKTM44NM6SEx+HOA8UUjfpJFjnlVsFrTTH0LHUPOKG1 grpjte1ykCUakRofXjvB2f8G0o57bTfSzpe6qTuHGJCfGAgvu4JEBNoW7WND3Tsnxjbt wnYuEq3HZVzyZj4t8MSfiZvi6/28B55ClC1ArhYbW8AErOtO0CmY/4yU0ZuV8i6ea+jS 0bqg==
X-Gm-Message-State: APjAAAXyLFGGLWIqAdlEKMAtS9BHhlheGKLJST7H6cZDwsg0tc0as5cD xUmCXoadDsynt6PRRO7t8ZuQB5IpFGHK1Q+2buY=
X-Google-Smtp-Source: APXvYqw4vxwbVe8nCpuVJX/XBNGMvUfLPwbPjKH8JU2r7A7uL5Xkgik6qMCXVgBHSjSueCRUqgRobUoNQL0kGcUuYBI=
X-Received: by 2002:a17:90a:1a0d:: with SMTP id 13mr5452763pjk.99.1561566315927; Wed, 26 Jun 2019 09:25:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Wed, 26 Jun 2019 18:25:02 +0200
Message-ID: <>
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?= <>
Cc: The IESG <>, Ronald Bonica <>, rtgwg-chairs <>,, RTGWG <>
Content-Type: multipart/alternative; boundary="0000000000008ddc81058c3c7d46"
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: Wed, 26 Jun 2019 16:25:20 -0000

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


On Wed, Jun 26, 2019 at 5:12 PM Mirja Kühlewind via Datatracker <>; 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
> 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.
> 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