Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

Robert Raszuk <robert@raszuk.net> Wed, 21 August 2019 20:12 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9921201A3 for <irtf-discuss@ietfa.amsl.com>; Wed, 21 Aug 2019 13:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 4lTb4KSQ0tM2 for <irtf-discuss@ietfa.amsl.com>; Wed, 21 Aug 2019 13:12:26 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 1B5DD1201DE for <irtf-discuss@irtf.org>; Wed, 21 Aug 2019 13:12:26 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id i4so4629904qtj.8 for <irtf-discuss@irtf.org>; Wed, 21 Aug 2019 13:12:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=df7Kyiq9TAM7jJQ8T3leDgg2phnwfC+i77y84ZfZPHA=; b=KAWa2/S1qtZHPivyey3Tqsd6eA+LSR2MtVXReWRCKQ/M5+2SDQscqtuStfOCgQqbbJ jHBGiRsGZkvnGibArBljLKT7Pns8QhdNVWAkdhl54lBXCo1HL1wwh7gYcwvYCbyG9Aic 5Pc17nXYz9+RBrvjaxBd8ZmvWvZ4fiX7oVJDSqNbiPAa96Bt1GGV38f3tnEJ2767phCI XqHuVaGTWXNJ3+wC8y8YzntZaGcnnNcCzN0joOF0fav2p1Bk/zTQ9ZMS9Yi4XpPTuQ3K PEV80/+eM/+QpNlCu9fy4/dbiPENJ9EGK3XGLvGkUwYwbOW9OLAH8bMIx8NXTtHMCF/m sJDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=df7Kyiq9TAM7jJQ8T3leDgg2phnwfC+i77y84ZfZPHA=; b=VTYLvUvKA7c/e/xw9RG78oHzl+A2dqIgKojcDN29mIeLMFOmYCxO4B02ONjkS531pk F14ZI1WsnBSoQWfij+H1SJTeMyfRpbiG3Cb4OiYy5RlcBqWXOoEYSB0cpdXcuZUn5Gkm cbWukOFuynpL6JUf8MM2Vx3YQAvaRDvKzro4JqLlkmGt66vh3R2n4DTGgCeuYR1V36IO TmcvMojkkLlxpIROKYVWiUTobjdtES5PtFe577Ywufn478sJpmQnGf2K59rfWgzkceff Pi8hX7KWRKJRxMTS+wcDfmJ8YJsA/TBqyJRTJKIMAqLBAufA9B4oTr1/ZJ+cZ1gHYDdN 67VA==
X-Gm-Message-State: APjAAAUtZCUS0dQKjI456UNA2b5gTw1QEDs2SzpbBOUAIQQZqLmf7PXv 3SBjjcXv1MecPnfcNbmGn7YkpbVbZhsLLItvYcbBAg==
X-Google-Smtp-Source: APXvYqwB+42RBtrwI9vh2LdCTsbl2TEw0C573LCzd4YG2xlUlUURhPm6FmndF2AOT6A93I8T/SWSZx/pzS1A9RSZLK0=
X-Received: by 2002:ac8:7696:: with SMTP id g22mr32612449qtr.208.1566418344910; Wed, 21 Aug 2019 13:12:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAPTMOt+cGhBqHmT3yZVChv-PCMqxT-WPDcDdM3RuTc1TMfFeVg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE148C2FE4@DGGEML532-MBX.china.huawei.com> <10708d7b-a4bc-f9d8-a644-7c5617f5ebf3@gont.com.ar> <CAPTMOtLyiUpi4L+7TpLePvm=JtpEnw-Yv1NCKvO63_HK2jFnCA@mail.gmail.com> <447e5dae-2ae9-b9fe-baa2-111c028d3b68@necom830.hpcl.titech.ac.jp> <CAOj+MMH=wb+v137TvQkZ+KxaBobA8qYmvoHkFzEgi9-PP-Lqxg@mail.gmail.com> <df102b3b-d337-8852-c5dc-f7aa4f479d77@necom830.hpcl.titech.ac.jp>
In-Reply-To: <df102b3b-d337-8852-c5dc-f7aa4f479d77@necom830.hpcl.titech.ac.jp>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 21 Aug 2019 22:12:14 +0200
Message-ID: <CAOj+MMHsHQPisxiJCLb4bB_nLy_W1y3YkAtYCXFJT5r00uKbVQ@mail.gmail.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "irtf-discuss@irtf.org" <irtf-discuss@irtf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000004b2950590a6319e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/Xb-gSfXdI4krA6X5sEXdcItvIfE>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 20:12:29 -0000

> IGP metric is used as route preference,

And that's the issue. Neither IGP metric nor BGP path attributes today
reflect reality of true network paths. They all assure you that you can
reach the destination ... without any assurance that you will get lowest
jitter, lowest rtt, lowest loss etc ...

When I look at my BGP table in NY I get path to Europe via Seattle just
because such path has 1 AS less in the AS-PATH and neglect the fact that
there is alternative path just next to it with +1 AS but shorter RTT of 150
ms.

The point is that the sweet spot to make an educated choice is the edge of
your network when your upstream ASes are attached to.

Sure having addresses of various upstreams PAs space on the hosts +
applying src+dst based routing in your domain makes it possible to attempt
to choose which way to go at the hosts itself. But one needs to ask
himself:

*A* is this right architecture to run identical active & passive probing
from 1000s of my servers to destinations customers may be coming from if
all the traffic needs to traverse few ASBRs anyway ?

*B* now assume you still think *A* is the way to go are we going to apply
multiple interfaces to each VM and each docker container too such that
those autonomous computing entities will again start to select their own
view of the optimal exit path ?

Many thx,
R.

PS.

As an additional reference take a look at Google's Espresso or Facebook's
Edge Fabric or Cisco's PFR. Those are the solutions I think make most sense
when it comes to assuring customers get best experience for services from a
given network. And I don't think any of those work in concert with end to
end multi homing principle.


On Wed, Aug 21, 2019 at 9:56 PM Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> Robert Raszuk wrote:
>
> > *"Instead, APIs and applications must be modified to detect and react
> > against the loss of connection."*
> >
> > Well it is clear that you are making an implicit assumption that quality
> of
> > the available paths is equal and all you need to care about is end to end
> > connectivity/reachability.
>
> No, as is written in draft-ohta-e2e-multihoming-03.txt:
>
>     Once a full routing table is available on all the end systems, it is
>     easy for the end systems try all the destination addresses, from the
>     most and to the least favorable ones, based on the routing metric.
>
>     Note that end to end multihoming works with the separation between
>     inter domain BGP and intra domain routing protocols, if BGP routers,
>     based on domain policy, assign external routes preference values
>     (metric) of intra domain routing protocols.
>
>     One may still be allowed, though discouraged, to have local
>     configuration with dumb end systems and an intelligent proxy. But,
>     such configuration should be implemented with a protocol for purely
>     local use without damaging the global protocol.
>
> IGP metric is used as route preference, though, some workaround
> of proxy (last paragraph) or having partial routing table on
> near ISPs (not mentioned in the draft) may be necessary, until
> global routing table becomes small enough to be able to be
> held by ordinary hosts.
>
> Note that at the time the draft was written, IPv6 global routing
> table was small, which means, at that time, IPv6 worth deploying
> despite all the flaws in it.
>
>                                         Masataka Ohta
>