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

From: Tom Herbert <[email-masked]>
Date: Mon, 28 Jan 2019 15:36:05 -0800

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-masked]>
Date: Mon, Jan 28, 2019 at 3:15 PM
Subject: New Version Notification for draft-herbert-intarea-ams-00.txt
To: Vikram Siwach <[email-masked]>

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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 Jan 2019 15:35:27 +0000

Hi Tom,

I read it, and I do not think it is different from the system described
in 'draft-ietf-rtgwg-atn-bgp'.

Fred

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Monday, January 28, 2019 3:36 PM
> To: dmm <[email-masked]>; [email-masked]
> Cc: Vikram Siwach <[email-masked]>
> Subject: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
> 
> Hello,
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Jan 2019 08:33:07 -0800

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 Jan 2019 16:45:52 +0000

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

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2019 8:33 AM
> To: Templin (US), Fred L <[email-masked]>
> Cc: dmm <[email-masked]>; [email-masked]; Vikram Siwach <[email-masked]>
> Subject: Re: [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Jan 2019 09:35:41 -0800

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 Jan 2019 18:25:34 +0000

Hi Tom,

> From: Pidloc [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Tuesday, January 29, 2019 9:36 AM
> Cc: Vikram Siwach <[email-masked]>; [email-masked]; dmm <[email-masked]>
> Subject: Re: [Pidloc] [DMM] Fwd: New Version Notification for draft-herbert-intarea-ams-00.txt
> 

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.

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

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.

Thanks for the questions, and let me know if you have any others.

Regard s- Fred

> --
> Pidloc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pidloc

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Jan 2019 11:24:36 -0800

> ('scalable-bgp', 'atn-bgp' and AERO) really say the same thing - scalable
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. From that POV maybe they are complementary.

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

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.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 Jan 2019 20:13:47 +0000

Hi Tom,

> Sent: Tuesday, January 29, 2019 11:25 AM
> 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.

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

> 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

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.

> the most direct route available (e.g. anchorless routing), hence the

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

---

From: Tom Herbert <[email-masked]>
Date: Tue, 29 Jan 2019 12:44:34 -0800

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

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

> 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

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 Jan 2019 21:47:57 +0000

Hi Tom,

> Sent: Tuesday, January 29, 2019 12:45 PM

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.

> 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

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.

> 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

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.

> 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