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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 29 January 2019 16:46 UTC

Return-Path: <Fred.L.Templin@boeing.com>
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 20ACE130E59; Tue, 29 Jan 2019 08:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aIiwqkr1nW7c; Tue, 29 Jan 2019 08:46:01 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AE9130E09; Tue, 29 Jan 2019 08:46:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x0TGjwwe027902; Tue, 29 Jan 2019 11:45:59 -0500
Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x0TGjrXV027572 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 29 Jan 2019 11:45:53 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1591.10; Tue, 29 Jan 2019 08:45:52 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.1591.012; Tue, 29 Jan 2019 08:45:52 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Tom Herbert <tom@quantonium.net>
CC: dmm <dmm@ietf.org>, "pidloc@ietf.org" <pidloc@ietf.org>, Vikram Siwach <vsiwach@gmail.com>
Thread-Topic: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
Thread-Index: AQHUt2KfWlx/WWYcSkyzsVamPdto6KXGYSAAgACW14D//3tEQA==
Date: Tue, 29 Jan 2019 16:45:52 +0000
Message-ID: <2e0c578499cb4761ac113a264f3992a0@boeing.com>
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>
In-Reply-To: <CAPDqMeqqLx42x_1c3=grWSoryGRS-v8xKP_yiXDO_cpB-JDYew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 90A4752C0436430AB38A6B1054C2F7CB0B1C89B7905FDC792FD133E491F21CA52000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/oeiFg75H-AyaBFRvQC5-PBk2Ve8>
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:46:04 -0000

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.

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