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

Tom Herbert <tom@quantonium.net> Tue, 29 January 2019 16:33 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 B14D7130E59 for <pidloc@ietfa.amsl.com>; Tue, 29 Jan 2019 08:33:21 -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=ham 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 KrxrkigBEhjT for <pidloc@ietfa.amsl.com>; Tue, 29 Jan 2019 08:33:19 -0800 (PST)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 40B3E130E30 for <pidloc@ietf.org>; Tue, 29 Jan 2019 08:33:19 -0800 (PST)
Received: by mail-it1-x132.google.com with SMTP id m8so14248698itk.0 for <pidloc@ietf.org>; Tue, 29 Jan 2019 08:33:19 -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=Y4/s89U/i58QIJSLvn3HR7OLAEohcBEsAfdiAwWD6EY=; b=ZuZJ2a+MogG0rcFAWlk7OoMlc1UFdHdlHidAVLc12OY5YwzFakQ1fM/RsPg44oHHdw UFetxcBbtN7DgG6qlRzYPrD2Qfk671ArW2fuwZfJIGlYd6BpCVF3QcTXiDsnifEWgGKE kEnre85FbBl2xRaET8PNSTaSpgTw9zxccmVd4HvgOeT/nJ0JEpS3xTmwsntTG8vlU14V b3nrHigfwyvLlXprHrriicxtgD0STpKC9yN/dII2+pfQkd6fgjB+CyOyKdAOP9h94nuk rZx5cR45RZNhFjJT21bmzXVGOuC8yFBKtSqb9hXJWJ/G7vlr93nCVI0ti6pnq0kOv3yN SZcw==
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=Y4/s89U/i58QIJSLvn3HR7OLAEohcBEsAfdiAwWD6EY=; b=ClDcsQMq44KM0XraDHWO2ARhS2xXjMVmWs7hN89OHWM7Mcx1SVcQltiPxL6XFxJBV/ Gx7HH5/NYQ/zoYP6tVk1cSMO3wNQ91/IqMjzbBGXbxIwXDT1dNLKuDMzUhGpS5VGdvpU RlCGfs7QEW/k0F9y4Kqc+o6Qc25vsJ3xs0TMMP+Ddzl4qj5CBvzcq1nh8vrrBAhlEthr QE2UTyV9mqmvCpUG0W9xxrRtn8CqcnKYhJhCsIKE+xVDWGvRL29A5vKjLPNdJ5rtvzhl XKt4Jl6VTo5sH8wI99YB9ratnGiHtpeRqtj67+5upDUBGCytR9eS2xA4qtRxplAMfLsG MUaA==
X-Gm-Message-State: AJcUukcgQrTRWZ9qzCfaNT8tdKnIISuLOC3REwKkqRzj3VULuIHgvLIn cZp5fQc2NwUDE2LP9XF7maUN7xAHdoPV3vd/3V6sPA==
X-Google-Smtp-Source: ALg8bN5LvDerDFalDoJloK3vEGkajZx8DkxqUmiUDDJg21dABd/LMyqW9/IxbkGLTbulttR/2HZ6Qx7ODlKuxAYZB40=
X-Received: by 2002:a02:5944:: with SMTP id p65mr16220739jab.3.1548779598288; Tue, 29 Jan 2019 08:33:18 -0800 (PST)
MIME-Version: 1.0
References: <154871730925.2863.111474039018096073.idtracker@ietfa.amsl.com> <CAPDqMer2teQty5RU6GtMuW6sj_HgPHbVKUPcSvj=bWuRe2MCnw@mail.gmail.com> <7be91a164bda4144a12c6c693bae7106@boeing.com>
In-Reply-To: <7be91a164bda4144a12c6c693bae7106@boeing.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 29 Jan 2019 08:33:07 -0800
Message-ID: <CAPDqMeqqLx42x_1c3=grWSoryGRS-v8xKP_yiXDO_cpB-JDYew@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/L35MOYtwJC39lCKbEMmzslGz9JA>
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 16:33:22 -0000

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