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

["Templin (US), Fred L" <[e-mail]>]

Hi Tom,

> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Tuesday, January 29, 2019 12:45 PM
> To: Templin (US), Fred L <[e-mail]>
> Cc: Vikram Siwach <[e-mail]>; [e-mail]; dmm <[e-mail]>
> Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
> 
> On Tue, Jan 29, 2019 at 12:13 PM Templin (US), Fred L
> <[e-mail]> wrote:
> >
> > Hi Tom,
> >
> > > -----Original Message-----
> > > From: Tom Herbert [mailto:[e-mail]]
> > > Sent: Tuesday, January 29, 2019 11:25 AM
> > > To: Templin (US), Fred L <[e-mail]>
> > > Cc: Vikram Siwach <[e-mail]>; [e-mail]; dmm <[e-mail]>
> > > 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
> > > <[e-mail]> wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > > -----Original Message-----
> > > > > From: Pidloc [mailto:[e-mail]] On Behalf Of Tom Herbert
> > > > > Sent: Tuesday, January 29, 2019 9:36 AM
> > > > > To: Templin (US), Fred L <[e-mail]>
> > > > > Cc: Vikram Siwach <[e-mail]>; [e-mail]; dmm <[e-mail]>
> > > > > 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
> > > > > <[e-mail]> 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.

MNPs are the most fine-grained prefixes permitted in the system - for example,
a ::/64. And, all the stub ASes see are MNPs so there is no aggregation in any
stub AS, and no notion of a home network.

> Relying too much on this sort of load balancing might be precarious.

It is just a service like any other Internet service. Major web presences like
google, amazon, etc. ensure that there is load balancing so that no single
server gets bogged down. The load balancing strategy for this would be
no different.

> It's conceivable that a mass migration could happen that quickly
> changes the dynamics of load balancing.

That wouldn't happen. Movement between stub ASes is "macro-mobility"
and there is no good reason to move at that level unless you are moving
very far away from your current location - say, from Los Angeles to
Chicago. Micro-mobility events (like moving from one Wifi hotspot to a
second hotspot) are handled within the stub AS; that way, micro-mobility
events will never be propagated up to the c-ASBRs and there is no
mass migration.

> 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.

The only concern would be catastrophic loss of critical infrastructure,
and you raise a good point about earthquakes and such. But, the
concern is no different than for any other infrastructure meltdown
in terms of the way Internet services would be affected. With this
system, at least there would be backup stub ASes in case a mobile
node suddenly finds itself without service. It can just try other
servers until it finds one that is working.

> > > 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.

It tells its new stub AS hello and tells its old stub AS goodbye.

> I would assume the latter means the host would need to
> get all new addresses.

No; not at all - the mobile node's MNP travels with it wherever it goes and
never changes. It does not matter to which stub AS the mobile node is
associated, and the mobile can in fact associate with multiple for fault
tolerance. But, remember that even though the MNP (i.e., the "identifier")
never changes, the underlying network addresses (i.e., the "locators") can
be changing dynamically. Coordinating those changes within the stub AS
is the business of a mobility protocol like MIPv6, LISP and AERO.

> Personally, I tend to think that the network
> should handle this transparently and not require disruption or
> intelligence on the mobile device.

I have been thinking that the mobile node would make its own choices
of stub ASes to join so it could look out for its own welfare, but an
alternative is that it could enlist the help of some sort of network
service broker. Again, it is just an Internet service and load balancing
and topological closeness would be the same as for any service.

> > > 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.

I think MIPv6 may be too tied to the notion of a "home network" to be
able to benefit from route optimization between network elements
that does not extend all the way to the mobiles. I don't think some of
the other alternatives that do not have the notion of a home network
share this limitation.

Thanks - Fred

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