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

Robert Raszuk <robert@raszuk.net> Wed, 21 August 2019 21:16 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 08753120089 for <irtf-discuss@ietfa.amsl.com>; Wed, 21 Aug 2019 14:16:15 -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=unavailable 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 x_BnulXi2n2o for <irtf-discuss@ietfa.amsl.com>; Wed, 21 Aug 2019 14:16:11 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 D9FC012001E for <irtf-discuss@irtf.org>; Wed, 21 Aug 2019 14:16:10 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id p13so3166861qkg.13 for <irtf-discuss@irtf.org>; Wed, 21 Aug 2019 14:16:10 -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=UvQ2x0Uwr56YrpY0RirKT0WUkfU8tliNsFL2YUIOf10=; b=DBR5co9ru7UmclF1fUOIPkGYGpbw+a+hrLp5+c9+qIM1ZryQ+D8nIBKRu3I4+BA9Mp pZsBfZExlnQrSFhLfPu3ji41j0Otu+r1MgIKC4/g/3i1Bj848cigtqOYXp7WtfFGHgnI W9Uv9QYbSoRzHr75kAPyDmHj5MLKq1dePhF+zSZTcw4p67I9OLNJaeR5MXt4QNByMehi 17WIjPXsxgMJePrUrnT1mzrCwE5RaPKaptr9RfC+6/8k7KSJTurcG7nKibpyzp2iKDsj NmOTIBGMGpmH7jeTEvJLIXY4+XrMiAS1WIjGEqte/doTxPbWjWAcOzFSZ+B9zKUdS0iF 1FKA==
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=UvQ2x0Uwr56YrpY0RirKT0WUkfU8tliNsFL2YUIOf10=; b=iwVcQJLQUh7mMgYmWbiynH6EQQ2eC5v6JxKSBvMXL6oUegt4XXeAmzodotmDHXv5uD s61HxSWAsOjQlo4+Pfj9d3zsMcEZ2YCTAO2iyr7CpiMes+ko90wxBjXCBjcfgCWFknZK 7xOIQlmeHmdQFg+X+bYdI5nokBPnAiSAaLaN5nJcvsBkBEuLrgIc0jOuBrYD4ObrDUS+ m/cKso3NdfQmdr+W6myBxyGgpQpzAwjpLEJdnLMl1Z22XJw8TZQgb7TpV4N4FuBOSGZX L0CkRz+6z2C2hHxMZZUknDUJsejpa516G6smh65NjcZoavHjROpvsBWZK74Fv8+LflXf ELUw==
X-Gm-Message-State: APjAAAUA8SePAZ6WLhqm45RM/FQtNVlXjnWh8O7mQqNFwzjKgxzX/7v1 A/e1DCxHs35zXmgJdv8sXjCWHjfNqqPBz4Neui7Ubg==
X-Google-Smtp-Source: APXvYqxG3fGTNjJ60ToWW5IPxXUJbRfridWVxPOFO135NdXfdez4tQTKJFuJAZIzhGdN2FjSXCVL2ikI3KGcmkq8uuA=
X-Received: by 2002:a37:4f41:: with SMTP id d62mr32030866qkb.302.1566422169859; Wed, 21 Aug 2019 14:16:09 -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> <CAOj+MMHsHQPisxiJCLb4bB_nLy_W1y3YkAtYCXFJT5r00uKbVQ@mail.gmail.com> <ffa5248f-4fb3-32d2-1ec4-aeb9621c0787@necom830.hpcl.titech.ac.jp>
In-Reply-To: <ffa5248f-4fb3-32d2-1ec4-aeb9621c0787@necom830.hpcl.titech.ac.jp>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 21 Aug 2019 23:15:59 +0200
Message-ID: <CAOj+MMHde82V-eZ78iPq8L52WCFOZWbF7-mSM19Q24FxXZz6Kw@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="00000000000000cd130590a715fa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/Mkk52xIFcN_3fDVQ3Cc_y2WX-V8>
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 21:16:15 -0000

> That you configure your BGP poorly

To configure exit path selection such that you take optimal exit to
destination X vs destination Y you need mechanism to either passively or
actively measure it. The entire point I am trying to make here is that
sweet spot for such measurements is the edge of the network and not on each
host, VM, container etc ....

>  proper IGP metric may be given by proper policy based on such knowledge

If you are proposing to redistribute BGP into IGP and apply proper metric
to each dst route then I think we already differ a little bit in a
perspective how to construct a network.

Of course even if I would carry selective destinations in IGP with properly
mapped metrics how would host learn about it when it has to pick the src
address from N available in end to end multi homing principle ? Is the
assumption again that hosts, VMs, LXCs participate now in the IGP ?

And even if it would be a passive IGP listener how do you encode in any IGP
today which src address should be selected such that packets will not be
dropped due to uRPF check by the upstream provider ?

Many thx,
RR.



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

> Robert Raszuk wrote:
>
> >> 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.
>
> I'm afraid you are not familiar with BGP policy, where you don't have
> to blindly rely on path attributes.
>
> > 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.
>
> That you configure your BGP poorly does not mean others can't have
> better policy to favor the alternative path.
>
> As is written in the draft:
>
>      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.
>
> proper IGP metric may be given by proper policy based on such knowledge
> (not carried by BGP) as "with +1 AS but shorter RTT of 150ms".
>
>                                                 Masataka Ohta
>