On Tue, Jan 29, 2019 at 12:13 PM Templin (US), Fred L <[email protected]> wrote: > > Hi Tom, > > > -----Original Message----- > > From: Tom Herbert [mailto:[email protected]] > > Sent: Tuesday, January 29, 2019 11:25 AM > > To: Templin (US), Fred L <[email protected]> > > Cc: Vikram Siwach <[email protected]>; [email protected]; dmm <[email protected]> > > Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for > > draft-herbert-intarea-ams-00.txt > > > > On Tue, Jan 29, 2019 at 10:25 AM Templin (US), Fred L > > <[email protected]> wrote: > > > > > > Hi Tom, > > > > > > > -----Original Message----- > > > > From: Pidloc [mailto:[email protected]] On Behalf Of Tom Herbert > > > > Sent: Tuesday, January 29, 2019 9:36 AM > > > > To: Templin (US), Fred L <[email protected]> > > > > Cc: Vikram Siwach <[email protected]>; [email protected]; dmm > > > > <[email protected]> > > > > Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for > > > > draft-herbert-intarea-ams-00.txt > > > > > > > > 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. > > > > > > Good input, but for that one we really were chartered to focus > > > specifically > > > on the aviation use case. Even so, the document says: > > > > > > "In this way, each set of c-ASBRs maintains > > > separate routing and forwarding tables so that scaling is distributed > > > across multiple c-ASBR sets instead of concentrated in a single > > > c-ASBR set. For example, a first c-ASBR set could aggregate an MSP > > > segment A::/32, a second set could aggregate B::/32, a third could > > > aggregate C::/32, etc. The union of all MSP segments would then > > > constitute the collective MSP(s) for the entire ATN/IPS." > > > > > > The A::/32, B::/32, C::/32 I think correspond to what your document calls > > > "shards", but there is no implied maximum number in the doc so there > > > could be thousands. But, in terms of the architecture, all three documents > > > ('scalable-bgp', 'atn-bgp' and AERO) really say the same thing - scalable > > > deaggregation. > > > > > I see. I think the atn may be nicely describing the sharding referred > > to in AMS. AMS employs caches to ensure direct path for critical > > communications. > > But, what do you do with arriving packets while there is a cache miss and > you need to go out and fill the cache? Drop them on the floor? Hold them > in a queue? With the BGP arrangement, packets are forwarded normally > even if initial packets end up taking a somewhat longer route. > > > From that POV maybe they are complementary. > > I think examining the elements that would be at work within the stub AS > makes sense, and I haven't gone to that level of examination in the *rtgwg* > docs. But, intra- stub AS candidate solutions already include MIPv6, LISP and > AERO - so, you may need to look for overlaps with those as well. > > > > > 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. > > > > > > The document is very careful to differentiate scaling considerations of > > > s-ASBRs independently of the scaling considerations of the stub AS. > > > The s-ASBR is the entity that connects the stub AS to the overlay, but > > > there may be many other entities inside the stub AS whose job it is > > > to coordinate with the mobile nodes. > > > > > > > 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. > > > > > > Other elements inside the stub AS can do the fine-grained mobility > > > signaling with the mobile nodes, while the s-ASBR can be deployed in > > > such a fashion that all it ever does is send unidirectional BGP updates > > > to c-ASBRs. > > > > > > > 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? > > > > > > The stub ASes accept mobile node customers up to a certain maximum. > > > So, if there are currently only 1K customers then there are currently only > > > 1K routes. But, let's assume that each stub AS can accept up to 1M mobile > > > node customers at a time. Then, if there are 1K stub ASes we achieve our > > > 1B MNP goal. > > > > > > It is also important to understand that the stub AS does not correspond > > > to a > > > single sub-MSP aggregated prefix (e.g., 2001:db8::/44). The stub AS will > > > accept > > > the MNPs of mobile nodes that are covered by any sub-MSP so routing in the > > > stub AS (as well as in the system as a whole) is completely de-aggregated. > > > > > Sure, but isn't there sub-optimal routing when a node moves to an area > > covered by a different stub AS. In that case wouldn't packets be > > routed to the home s-ABSR and then forwarded to the remote location. > > In this model, there is no such notion as a "home" s-ASBR; mobile nodes > are always "away from home", and there is no aggregation of any kind > within any stub AS. Total de-aggregation instead. > > > And even if each stub AS were to support up to 1M nodes, a large > > densely populated urban area might have an order of magnitude more > > devices which means that the city needs to be divided up into several > > areas corresponding to stub-ASs and MNPs. > > Yes, for very dense urban areas there could be many stub ASes - each one of > which is capable of serving any mobile node that shows up. So there is natural > load balancing and no aggregation of any kind.
Fred, I'm not sure why you say there's no aggregation, it seems like MNPs are aggregating nodes. Relying too much on this sort of load balancing might be precarious. It's conceivable that a mass migration could happen that quickly changes the dynamics of load balancing. Consider people going to a major sporting event or evacuation from a natural disaster. Network architecture needs to be able to handle edge cases like that seamlessly and robustly. > > > Entropy of motion implies > > that a steady state will be reached where a fairly large portion of > > users are outside the geographic area corresponging to their MNP so > > communications are subject to the triangular routing. > > Mobile nodes associate with a nearby stub AS from a regional perspective. > If the mobile moves far away from its current stub AS, it can leave that > one and associate with a new stub AS that is closer. But, it could instead > remain with the old stub AS at the penalty of routing stretch as you say. > Then that would raise the question of how does the mobile node know it's move to a different AS, and what is the process to associate with a new stub AS. I would assume the latter means the host would need to get all new addresses. Personally, I tend to think that the network should handle this transparently and not require disruption or intelligence on the mobile device. > > So I think the atn solution might be good to scale the number of > > nodes, but sub-optimal routing is going to be problematic for critical > > low latency applications. For those, I maintain we always want them to > > the most direct route available (e.g. anchorless routing), hence the > > value of a cache. > > Route optimization is used to avoid having to always go through an > anchor - AERO is Asymmetric Extended Route Optimization, and > LISP does a sort of route optimization in its xTR discovery process. > Direct mobile-to-mobile route optimization may also be possible > in some environments, but not all. > Correct. A major point of AMS is to bypass routing through anchors when it's of benefit to do so. Tom > Thanks - Fred > > > > Thanks for the questions, and let me know if you have any others. > > > > > > Regard s- Fred > > > > > > > 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 > > > > > > > > -- > > > > Pidloc mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/pidloc _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
