Re: [Pidloc] [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt

Tom Herbert <tom@quantonium.net> Tue, 29 January 2019 17:35 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: pidloc@ietfa.amsl.com
Delivered-To: pidloc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC15130E66 for <pidloc@ietfa.amsl.com>; Tue, 29 Jan 2019 09:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 a5U9jD1tqtCY for <pidloc@ietfa.amsl.com>; Tue, 29 Jan 2019 09:35:53 -0800 (PST)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 F0CFC130E9C for <pidloc@ietf.org>; Tue, 29 Jan 2019 09:35:52 -0800 (PST)
Received: by mail-io1-xd34.google.com with SMTP id t24so17034905ioi.0 for <pidloc@ietf.org>; Tue, 29 Jan 2019 09:35:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S1P9lOidc+8/sLvEdc8tHDlpe8XEpU1Ud3SGRbMGvkA=; b=SZ7SwG78lAtB3c/gRE9KUd/424rB+VkgIvcPSwkvBuLNL2Aq1NOvPn8HY51qYg7IHg U0WVzFq/c5xPVY0jtbUfWLpqFvZ1E7ts0iP1m1kWKqymq76FxXGW0JiYZMWRLko9YKgW N8rBxsiTtAHKk84Tl3pp7KHncpoCcQaiINBFWKC2sDOZCnRdAcZWErolpirZhFDkzSsx UqSOaN3PNUXkPzcrZnOnV1IP2XbEsEe2HVK3qMkiYYxv0t4pJ9xCSM3WMnc8cU6fscBu HUYfe2zT/8yteIBQEa6qU30Ci8yVMqEPPk/0j0NzCNqnv1maJni3Y03p7X1uYfG2NQvR 1SBQ==
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=S1P9lOidc+8/sLvEdc8tHDlpe8XEpU1Ud3SGRbMGvkA=; b=SmH1FOwdynIHh4+hrS2LDE0cS/GLDSIFWED01VklI9WggXSNWVwMDWv83Tf1mQcOvo DmlXMFgS+QJ+B1jRBAh56yk3M9gkgMbpGiLyNfQfOWppNY8gRer1MmC9O0yKjB3c/GdO A2d3Xi/bKoda1ennu77vXKhVOdQa3l5FU24eHQYudaX8cHXsZpThPpGqBjAzCUuktvfX wFhIhwXwdR1ytnyeBqNDoDYX7EAs9y9MrJrFAtUgUOIa/9fCM2XtbFO8xVKtIqqFh/RK B0OGalK9DsBJfQ4/9KmaEJn1khDcN4gbY78EIlL8Zwb+ioKivOuqA2sH8jA6zfwF/1il kUVQ==
X-Gm-Message-State: AHQUAubHG4K4kne0oPce6cQGPUm7mVUaZfDj/BSO1zsZD3F30sMmgSTV mYf7g0tOObrGFBVlkL2v40yjWrZk9vbgOG1G+6v7jg==
X-Google-Smtp-Source: AHgI3IbDAfoRuDHe4o8mvfmLYeahuF+0bInaktohbyYyupvUSvOsljalHy41bu00LxbjWCgc2rIRor4GILCDPWSPLrA=
X-Received: by 2002:a6b:1411:: with SMTP id 17mr15980110iou.252.1548783352044; Tue, 29 Jan 2019 09:35:52 -0800 (PST)
MIME-Version: 1.0
References: <154871730925.2863.111474039018096073.idtracker@ietfa.amsl.com> <CAPDqMer2teQty5RU6GtMuW6sj_HgPHbVKUPcSvj=bWuRe2MCnw@mail.gmail.com> <7be91a164bda4144a12c6c693bae7106@boeing.com> <CAPDqMeqqLx42x_1c3=grWSoryGRS-v8xKP_yiXDO_cpB-JDYew@mail.gmail.com> <2e0c578499cb4761ac113a264f3992a0@boeing.com>
In-Reply-To: <2e0c578499cb4761ac113a264f3992a0@boeing.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 29 Jan 2019 09:35:41 -0800
Message-ID: <CAPDqMeqg3iRPZjw=sEGuXXeQiw9HVXUROep42Dhs16hgFkN5MA@mail.gmail.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
Cc: dmm <dmm@ietf.org>, "pidloc@ietf.org" <pidloc@ietf.org>, Vikram Siwach <vsiwach@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/fLLWl1WB6DhCvRMjhJ2n0lUTB3c>
Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
X-BeenThere: pidloc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <pidloc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pidloc>, <mailto:pidloc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pidloc/>
List-Post: <mailto:pidloc@ietf.org>
List-Help: <mailto:pidloc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pidloc>, <mailto:pidloc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2019 17:35:56 -0000

On Tue, Jan 29, 2019 at 8:46 AM Templin (US), Fred L
<Fred.L.Templin@boeing.com>; wrote:
>
> Hi Tom,
>
> Please read 'draft-templin-rtgwg-scalable-bgp' (only 7 pages). It emphasizes
> the scalability considerations from 'draft-templin-intarea-6706bis' that we
> omitted from 'draft-ietf-rtgwg-atn-bgp', and also shows that the use cases
> are not limited to civil aviation. The purpose is to present a condensed
> version of the AERO routing system that has been around for many years.
>
> In 'draft-templin-rtgwg-scalable-bgp', we show that a BGP overlay can be
> organized to support 1B or more de-aggregated MNP prefixes. So, please
> have a look at that with the mindset that we are not addressing just the
> civil aviation use case but are broadly considering other use cases.
>
Okay, thanks for the explanation. It might be helpful if you could
recast draft-ietf-rtgwg-atn-bgp to be more of a general solution.

I looked at draft-templin-rtgwg-scalable-bgp. There's a lot discussion
about scalability of c-ASBR but not so much about s-ABSR. I'm
primarily interested in the latter because that is where the solution
will be providing the oprimizations we want for low latency. While
with c-ASBRs we could expect them to have scaling properties similar
core routers, I would expect that s-ASBR devices will exhibit a lot
more variety and have a wider range of scalability. For instance, it's
conceivable that we might want the functionality incorporated into a
low powered device in the base station of a microcell, or incorporated
into MEC servers as I mentioned previously. I assume a BGP solution
would require all s-ASBRs to hold all the routes for the sub-MNPs as
well as being able to consume the rate of mobile events within the
sub-MNP. So to me, the obvious question is if such a device were only
communicating with, say, a 1000 nodes at any givent time, then does it
really make sense to give them all the information about the 1M or so
nodes in the sub-MNP, or can we just give them the information that is
currently useful to them?

Do you have any thoughts along these lines?

Tom

> Thanks - Fred
>
> > -----Original Message-----
> > From: Tom Herbert [mailto:tom@quantonium.net]
> > Sent: Tuesday, January 29, 2019 8:33 AM
> > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>;
> > Cc: dmm <dmm@ietf.org>;; pidloc@ietf.org; Vikram Siwach <vsiwach@gmail.com>;
> > Subject: Re: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
> >
> > On Tue, Jan 29, 2019 at 7:35 AM Templin (US), Fred L
> > <Fred.L.Templin@boeing.com>; wrote:
> > >
> > > Hi Tom,
> > >
> > > I read it, and I do not think it is different from the system described
> > > in 'draft-ietf-rtgwg-atn-bgp'.
> > >
> > Hi Fred,
> >
> > Thanks for the comment. I have read draft-ietf-rtgwg-atn-bgp also. I
> > think that the hub and spoke architecture will end up being similar,
> > but I'm not sure that this is exactly the same thing. One difference
> > is that draft-ietf-rtgwg-atn-bgp is targeted to particular
> > application, whereas draft-herbert-intarea-ams endeavours to be
> > general purposes. There are differences especially in scalability. For
> > instance, rtgwg-atn-bgp mentions network with millions of routes, and
> > in draft-herbert-intarea-ams the target is to support networks with
> > billions of active addresses for IoT networks. And if we do get to
> > unique address per flow, then the total number of addresses to be
> > managed is much more (hence why hidden aggregation becomes
> > interesting).
> >
> > Another consideration is MEC servers providing services to UEs at they
> > edge. If they participate in the routing/mapping system (as an ASBR-s
> > in draft-ietf-rtgwg-atn-bgp and AMS-F in AMS) then the end device can
> > perform overlay routing itself. That is very efficient for lowest
> > latency. There may be many MEC servers and each one might only be
> > communicating with a small subset of all possible nodes. This seems to
> > motivate a working set cache to that limits the number of mappings as
> > well as the amount of control plane communications.
> >
> > Tom
> >
> > > Fred
> > >
> > > > -----Original Message-----
> > > > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Tom Herbert
> > > > Sent: Monday, January 28, 2019 3:36 PM
> > > > To: dmm <dmm@ietf.org>;; pidloc@ietf.org
> > > > Cc: Vikram Siwach <vsiwach@gmail.com>;
> > > > Subject: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
> > > >
> > > > Hello,
> > > >
> > > > We've posted a first draft of Address Mapping System (AMS). We
> > > > anticipate that this can be applied to mobile networks to provide
> > > > optimized overlay routing. In particular, this design provides for
> > > > anchorless routing (in the form of anchor bypass) and otherwise
> > > > facilitates meeting several requirements for optimizing the mobile
> > > > user plane as described in section 1.0 of
> > > > draft-bogineni-dmm-optimized-mobile-user-plane-01.  AMS is agnostic to
> > > > the underlaying overlay protocol and should be compatible with most of
> > > > those being discussed. Another goal of AMS is to not require replacing
> > > > exsiting control planes, but can work in concert with them. For
> > > > example, the draft discusses how AMS might work with 5G.
> > > >
> > > > Tom
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: <internet-drafts@ietf.org>;
> > > > Date: Mon, Jan 28, 2019 at 3:15 PM
> > > > Subject: New Version Notification for draft-herbert-intarea-ams-00.txt
> > > > To: Vikram Siwach <tom@quantonium.net>;
> > > >
> > > >
> > > >
> > > > A new version of I-D, draft-herbert-intarea-ams-00.txt
> > > > has been successfully submitted by Tom Herbert and posted to the
> > > > IETF repository.
> > > >
> > > > Name:           draft-herbert-intarea-ams
> > > > Revision:       00
> > > > Title:          Address Mapping System
> > > > Document date:  2019-01-28
> > > > Group:          Individual Submission
> > > > Pages:          47
> > > > URL:
> > > > https://www.ietf.org/internet-drafts/draft-herbert-intarea-ams-00.txt
> > > > Status:         https://datatracker.ietf.org/doc/draft-herbert-intarea-ams/
> > > > Htmlized:       https://tools.ietf.org/html/draft-herbert-intarea-ams-00
> > > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ams
> > > >
> > > >
> > > > Abstract:
> > > >    This document describes the Address Mapping System that is a generic,
> > > >    extensible, and scalable system for mapping network addresses to
> > > >    other network addresses. The Address Mapping System is intended to be
> > > >    used in conjunction with overlay techniques which facilitate
> > > >    transmission of packets across overlay networks. Information returned
> > > >    by the Address Mapping System can include the particular network
> > > >    overlay method and instructions related to the method.  The Address
> > > >    Mapping System has a number of potential use cases networking
> > > >    including identifier-locator protocols, network virtualization, and
> > > >    promotion of privacy.
> > > >
> > > >
> > > >
> > > >
> > > > Please note that it may take a couple of minutes from the time of submission
> > > > until the htmlized version and diff are available at tools.ietf.org.
> > > >
> > > > The IETF Secretariat
> > > >
> > > > _______________________________________________
> > > > dmm mailing list
> > > > dmm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/dmm