On Tue, Jan 29, 2019 at 8:46 AM Templin (US), Fred L <[email protected]> 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:[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
