Re: Tsvart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

Jen Linkova <> Mon, 01 July 2019 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B631612000E; Sun, 30 Jun 2019 23:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gJvC4AFK2I0w; Sun, 30 Jun 2019 23:37:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 865CA120018; Sun, 30 Jun 2019 23:37:20 -0700 (PDT)
Received: by with SMTP id s15so13448255qtk.9; Sun, 30 Jun 2019 23:37:20 -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:content-transfer-encoding; bh=rjRL6JLS4vzv8F69k3peZjr1t3Tb5Czg4YXMvNI6erk=; b=gNhYM1AkrkJLHBeJc7KZjnLUayg/dG4XTFlwDk4ol+YAjppM3H725J9XFPQs4B875I lPs4EugwI6S4RCFtPR3V1QsL88qbVy4NzwETUwTyEgyCv5gArCtotn/6AcYePJe/GcXB lXSZ/aNCIPBzcyJdsknde3I4u0smkC2n6UaJTAmx4ogFgOMfQ7MYFu9Z5SQV/BWllGVB M2DZJQuAF/+TAVBvOyrO+yt7zbJVRV1h3vlwrxJF5VuKGYLvgdoQ9/XKdzi15GecbvCm gaSCa3i0jnOPTZTIPj6t3vzsfPVKhYbX4w5gEKozA1RFzTf6eZyUGnD9QUsI8vxvD8cP 5E0A==
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:content-transfer-encoding; bh=rjRL6JLS4vzv8F69k3peZjr1t3Tb5Czg4YXMvNI6erk=; b=Y7RARSxPi5L+wL+YBbjrRMSxGJzFPjPbgF2ddNNEc+NMspfM3JsDX3dQjvkB1kqllE jhwZRPczxzD+gBJDJKnVMFpvpb9SdyYFoTm9T/rg8b4w4FjtGk31t7CkaYOLM5HHs7tD 6Vns17DOeSFLK5Wim75uEa6v73TINQxXKXiKLCwesqUWyalf/zaMeNVwycDPbNfGL2Jk fcBDnmCEWVAIu2v8xqOoQG/fE6JoKgxe4w5+rsz34KdmS0aw87fJtMs+71edjKazFmL5 9LuPxOIREvvd6rIpPz3ZhmpQc6ricSRbZoEuT6Z3WMiT7cNdvEbuLLzIcYRrSFFqdIeL 1XnA==
X-Gm-Message-State: APjAAAW58bCjOBqdR2WirUhof5veEOz0hjV3Mx4SXFyhaACH0iJhJb4z wby8HHyDGio5An/OXm0Ps1R0m9GzY5hLRIvQIVC5Gzzf
X-Google-Smtp-Source: APXvYqzSJd9yTFSQ0g1DtrJSz8dGMAxZ2lmqjOTPeHSbEPPc3a1JLO3U3fCglEo5L4UkAm/fGiWbPU38C/gp9qXXDxU=
X-Received: by 2002:ac8:ce:: with SMTP id d14mr19042723qtg.149.1561963039347; Sun, 30 Jun 2019 23:37:19 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Jen Linkova <>
Date: Mon, 1 Jul 2019 16:37:06 +1000
Message-ID: <>
Subject: Re: Tsvart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
To: =?UTF-8?Q?Michael_T=C3=BCxen?= <>
Cc:,, IETF Rinse Repeat <>, Routing WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 06:37:22 -0000

Hi Michael,

First of all, thanks for your review and comments - my apologies for
not responding earlier...

On Thu, Jun 6, 2019 at 11:24 PM Michael Tüxen via Datatracker
<> wrote:
> The document looks good from my perspective, but could make two things clearer:
> * If the connectivity to one ISP break down all transport connections without specific
>   multihoming support will break. This includes all TCP connections.

Ah, good point. If we add the following subsection to the "Section 6.
Deployment Considerations"

"6.1. Connections Preservation

The proposed solution is not designed to preserve connection state in
case of an uplink failure. When all uplinks to an ISP go down all
transport connections established to/from that ISP address space will
be interrupted (unless the transport protocol has specific multihoming
support). That behaviour is similar to the scenario of IPv4
multihoming with NAT when an uplink failure causes all connections to
be NATed to completely different public IPv4 addresses.

It should be noted that in case of IPv4 NAT-based multihoming uplink
recovery could cause connection interruptions as well (unless packet
forwarding is integrated with existing NAT sessions tracking so the
egress interface for the existing sessions is not changed). However
the proposed solution has a benefit of preserving the existing
sessions during/after the failed uplink restoration. Unlike the uplink
failure event which causes all addresses from the affected prefix to
be deprecated the recovery would just add new preferred addresses to a
host without making any addresses unavailable. Therefore connections
estavlished to/from those addresses do not have to be interrupted.
would it address your comment?

> * The description of transport based alternatives in section 7.3 is pretty generic.
>   However, this might be acceptable since the main argument that it is right now
>   not an alternative due to limited deployment, is valid.

I see what you mean but I'm not sure how to improve it...If you have
any suggestions it would be highly appreciated!

SY, Jen Linkova aka Furry