Re: RTGWG WGLC draft-ietf-rtgwg-enterprise-pa-multihoming

Jen Linkova <furry13@gmail.com> Mon, 30 April 2018 02:52 UTC

Return-Path: <furry13@gmail.com>
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 592F212D86F; Sun, 29 Apr 2018 19:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bKmz497XfPEP; Sun, 29 Apr 2018 19:52:21 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 3018F12D77C; Sun, 29 Apr 2018 19:52:21 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id j193-v6so10239917lfg.6; Sun, 29 Apr 2018 19:52:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IixKSanvGo4RNvPK8bp+88kxyoC2sNC5sJxGf8wKwbo=; b=ibrPmaCN9Anljlppi9tBGJ4Rql5sMRTZa+/zgGknAvxC77/VbeOjlP1IDF9UCsAzdG 0IL5ll69iXBLeNuCZUc4Y/zE8zp0Nl7H27ksy11+O6xtW0CEmBvkPk3yd2e75WaOhs1B 0gl2FxXLcYX+f8cH3JoQgt4cRIHDVG8bkzyScN/5tPexttW71ulzkhQ9A3XPf2G2DPvo UMzKwum2BSEydRPCRZ7zHvQIHNCXmqx+xBX0EcwsZLkKB3EJ5MUSEdo1a3k743sOlNeu sXfxbsXBa88Oq9pPQvtcvKwK3X1EJPb7teKYvkh1AXTC3k3Bv4aVzb2VI8YBzDdwJuKC 0TRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IixKSanvGo4RNvPK8bp+88kxyoC2sNC5sJxGf8wKwbo=; b=Xjtiru7TeKkDHni9CYkdAsnDczFOfMC15EGYezQh9HymJqFrhMm+buhFbUoQKIsZko hvdyZzjbSL+pcf+iWpSsKMv2fqhcOBoUNzZlg6xvvEu7CLW3iQ/5cABUYLZ1GmqIuw50 hT2LeHLlB5e+ciCtq4Sxe3p0F0/9Rdy7dGC1TzDe90P2vIoP1WVs1zU5MexcrmhaqxpX pM/XVkxhwjwwZaer3fSmn9NZVh59nv4JrsgKtJ6x7HlnFtH5+IBrEWklokLoidP2mUPY y+xN9SFhpM0vaMH/U+3qhOolKoBDJh76ogNRCETAOs2rgNxQjXUTh0vje3d7epRORk3/ e4RQ==
X-Gm-Message-State: ALQs6tCsk42NH93leBSOFiZHDnmOuhowc3AutcId32AwLKVNmSv3Tgf4 PPiQCBJx2fOMKjnSYabkznUjERe/DHUjm5xbYsY=
X-Google-Smtp-Source: AB8JxZqNcAnx7ft20lajquLcyKoEL3pc7tzjq2vL3qUFZLvTyFz7e6PodIkRgI7KcJDzdbwNHGqC2Uh2OfUGFuTjn/w=
X-Received: by 2002:a2e:9d54:: with SMTP id y20-v6mr6594441ljj.107.1525056739307; Sun, 29 Apr 2018 19:52:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:5c04:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 19:51:58 -0700 (PDT)
In-Reply-To: <03236c92-1166-13fa-b39d-d7c7c41e6920@uclouvain.be>
References: <44C0D21A-9788-4AEE-B814-D3670D3B3110@gmail.com> <f3a6a3d5-9aaf-54dd-edfc-dd58d223afde@uclouvain.be> <CA+b+ERnZmCLSC=0gfwLFixAnyNasuKqsFF4VR-ttqySJcSo0Zw@mail.gmail.com> <CAFU7BAQbvdWbotyCVwiRjmRr-2uC-Mo=wq_XDvUtriqAoih-+A@mail.gmail.com> <03236c92-1166-13fa-b39d-d7c7c41e6920@uclouvain.be>
From: Jen Linkova <furry13@gmail.com>
Date: Mon, 30 Apr 2018 12:51:58 +1000
Message-ID: <CAFU7BASnB1wSLfMTy2O3gHZapYui-s_=SBedLaKPCCR2GS_Z0A@mail.gmail.com>
Subject: Re: RTGWG WGLC draft-ietf-rtgwg-enterprise-pa-multihoming
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: Robert Raszuk <robert@raszuk.net>, rtgwg-chairs <rtgwg-chairs@ietf.org>, RTGWG <rtgwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/vdWZkW4pSJGy4nt01m6YX93iYbc>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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, 30 Apr 2018 02:52:23 -0000

On Sun, Apr 29, 2018 at 7:36 PM, Olivier Bonaventure
<Olivier.Bonaventure@uclouvain.be> wrote:
>> Let me clarify why Section4 discusses SLAAC/DHCP/ICMP instead of
>> multipath transport.
>> I totally agree that if all hosts were using path-aware transports
>> only, it would have solved the problem discussed in the Section 4 of
>> the draft.
>> However it means that enterprises can not have IPv6 multihoming until
>> almost all their traffic is over those path-aware transport protocols
>> and I have some concerns re: when it's going to happen.
>>
>> Point taken, the document should mention multipath transport and
>> explain why we are looking for lower-level solution.
>>
>
> I think that it is worth to document what can be done today with single path
> transport and what will become possible with multipath transport. Multipath
> transport makes the multihoming problem much simpler from a network
> viewpoint. With Multipath TCP and soon Multipath QUIC, we cannot ignore the
> benefits that multipath will bring.
>
> I'm ready to contribute text about multipath or propose a separate document
> if you believe that it would be better to document today's (single path)
> approach in one document and a longer term (multipath) in a separate
> document.

Thanks a lot Olivier!
I'm thinking of updating the document with a section which would clarify that:
- multipath transport makes multihoming easier and solves a number of
multihoming netwroks have problem;
- in particular, multihomed enterprise network would still need a
solution described in the Section 3 but if all hosts in such a network
are using
multipath transport, we might not even need a network to signal
topology changes with RAs;
- however as there are significant number of hosts which do not use
mulipath transport and they are not completely disappearing in any
foreseeable future, the solution
needs to take those hosts into account and therefore this document
discusses how to make multihoming work for the least common
denominator. Multupath transport (if/when hosts in the network start
using it) would complement  the solution described in the Section4.

Would it address your concern?

-- 
SY, Jen Linkova aka Furry