Hi Tom,
> -----Original Message-----
> From: Pidloc [mailto:pidloc-boun...@ietf.org] On Behalf Of Tom Herbert
> Sent: Tuesday, January 29, 2019 9:36 AM
> To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> Cc: Vikram Siwach <vsiw...@gmail.com>; pid...@ietf.org; dmm <dmm@ietf.org>
> 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
> <fred.l.temp...@boeing.com> 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 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.
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:t...@quantonium.net]
> > > Sent: Tuesday, January 29, 2019 8:33 AM
> > > To: Templin (US), Fred L <fred.l.temp...@boeing.com>
> > > Cc: dmm <dmm@ietf.org>; pid...@ietf.org; Vikram Siwach <vsiw...@gmail.com>
> > > 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
> > > <fred.l.temp...@boeing.com> 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:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
> > > > > Sent: Monday, January 28, 2019 3:36 PM
> > > > > To: dmm <dmm@ietf.org>; pid...@ietf.org
> > > > > Cc: Vikram Siwach <vsiw...@gmail.com>
> > > > > 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: <internet-dra...@ietf.org>
> > > > > Date: Mon, Jan 28, 2019 at 3:15 PM
> > > > > Subject: New Version Notification for draft-herbert-intarea-ams-00.txt
> > > > > To: Vikram Siwach <t...@quantonium.net>
> > > > >
> > > > >
> > > > >
> > > > > 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
> > > > > dmm@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/dmm
>
> --
> Pidloc mailing list
> pid...@ietf.org
> https://www.ietf.org/mailman/listinfo/pidloc
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
