Re: [Pidloc] [DMM] 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 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.

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

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

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