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

Robert Raszuk <> Mon, 01 July 2019 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3A19120220; Mon, 1 Jul 2019 04:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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] 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 VAaJIE_VDOUv; Mon, 1 Jul 2019 04:45:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D702C12008D; Mon, 1 Jul 2019 04:45:34 -0700 (PDT)
Received: by with SMTP id bi6so7228274plb.12; Mon, 01 Jul 2019 04:45:34 -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=KnXBz5i3vBD5KrFB8G0t9IAmKUo3HKtidtIJDFKj7Pg=; b=oozaH4Ghm/3jG+jne09REGFTjpliUaaLs1jw2MsGMlReOinc42ev7PMxcB8I6hkEJW H16jPQF/Y9BlzyietMzQ76TLyoYCEKc+vgy9cagqoPFboL8gsRgg4w03tgaQy2ARaSPi RfPrxrZb7qcNtA/W+ppMWmDCrIgLieYeNHIk5SlOOMMcEzs8E/LcqmDsXqHY1e3d6Ny2 uEwO8P1OWcXdZL/hHwJpYmhP+706MaQCtDS6oN8n86siF7hoC5hHsaprZp/qtheXCBQy e1hsaOLw9uPpdzCEcMnLGqkkt4pAsuUTEh4h21mFbpzn757G2jWEvjZ/iLAh8a+I38Wq jTDw==
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=KnXBz5i3vBD5KrFB8G0t9IAmKUo3HKtidtIJDFKj7Pg=; b=NHLe616BnRtxZpXOYm8TKUylba0rt9p6BLFOXcRwveUkZ91j2iP/45DtCPf18Jjs2l z5RgsNr4yX6RfZEDFT9LPfVcTFJiuu1ZeOvq8+mHPkJ7iTN/pIufWBFd2RdPq4dICY25 w+yyribR7zRNjxWfAXI2kj1cja4eO5exKlxs7nzRFblWD7RGOnpYinRjtD7OmQ0gIR+Q RXtuTTIkT/d3eCcGbKn5+rFzuqB9q8xww6yScVT7BJxfGFXfGnOWHATOrsUkyDgiGKM+ 8C7vR91HhvWXTsl+VP3yv/XBDzWKBBoknar6eqcbXGcgSUr1wMJCgR7WTOZErugV3fu7 GU9w==
X-Gm-Message-State: APjAAAXu2ca0Sj8CKdXewsVYQPla/ztCdOFdJ2UfWfINHczp63mTiZg7 6ikiWQkF+UM9Cv8AV9wA7Bvt2+Un19uZVovLqPc=
X-Google-Smtp-Source: APXvYqwv6pro1tknOKoGDVVSIQ8hUDpyY4ORltOpkSWiq+AnjcyQHBBq7q3m05Ey2ee5+66MLnGur96wFd75LTN3KbY=
X-Received: by 2002:a17:902:2ec5:: with SMTP id r63mr28247705plb.21.1561981533992; Mon, 01 Jul 2019 04:45:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 1 Jul 2019 13:45:22 +0200
Message-ID: <>
Subject: Re: Tsvart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
To: Jen Linkova <>
Cc: =?UTF-8?Q?Michael_T=C3=BCxen?= <>,,, IETF Rinse Repeat <>, Routing WG <>
Content-Type: multipart/alternative; boundary="0000000000007aba9a058c9d2a3e"
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 11:45:38 -0000

Hi Jen,

What you say below about IPv4 and NAT is true ... but it is not complete.

Yes when I use multi homing and I do NAT on the CE upon link loss the
address of all of transport sessions will change.

But please imagine the case (my own setup) where I am multi homed, I use
1918 space in my LAN which I extend over my multihomed connections to a
satellite near by cloud VM with static IP from cloud's provider registered
space. On that VM I run NAT and go off to Internet.

That means that if any of my uplink goes down or up all of my sessions stay

Question #1:

Now how would I do this in your proposal ? How would I do that in general
with IPv6 ?

Question #2:

Imagine the qualiy of the links I am multihomed with do change during the
day or during the week. Today I can measure run time SLAs (delay, jitter,
rtt, MOS etc ... ) and based on that choose which ISP the packets should
take on the way out (to Internet or my described above VM) without touching
the applications, servers etc ...

Trust me the above Performance Based Routing pays off. But I am sure you
know. So with your proposal how is that possible any longer ? If 100s of
servers are to choose src IP address are you suggesting that all 100s of
them will be running SLA probes every few seconds to choose optimal uplink

What is the answer to this Q in your solution ?


On Mon, Jul 1, 2019 at 8:38 AM Jen Linkova <> wrote:

> 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!
> Thanks!
> --
> SY, Jen Linkova aka Furry
> _______________________________________________
> rtgwg mailing list