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:[email protected]] > Sent: Tuesday, January 29, 2019 8:33 AM > To: Templin (US), Fred L <[email protected]> > Cc: dmm <[email protected]>; [email protected]; Vikram Siwach <[email protected]> > 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 > <[email protected]> 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:[email protected]] On Behalf Of Tom Herbert > > > Sent: Monday, January 28, 2019 3:36 PM > > > To: dmm <[email protected]>; [email protected] > > > Cc: Vikram Siwach <[email protected]> > > > 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: <[email protected]> > > > Date: Mon, Jan 28, 2019 at 3:15 PM > > > Subject: New Version Notification for draft-herbert-intarea-ams-00.txt > > > To: Vikram Siwach <[email protected]> > > > > > > > > > > > > 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
