Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

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

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Wednesday, November 30, 2016 12:04 PM
> To: Templin, Fred L <[e-mail]>; Lucy yong <[e-mail]>; Brian E Carpenter
> <[e-mail]>; [e-mail]
> Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels
> 
> 
> 
> On 11/30/2016 11:41 AM, Templin, Fred L wrote:
> > It is about more than just mobility - security, traffic engineering, routing
> > control, VPN, and other aspects. What really makes AERO intarea-like
> > is the fact that it is modeled as an NBMA link-layer for IP and can be
> > considered an "IP-over-foo" document.
> You're talking about the features, not the problem. Every tunnel that
> includes encryption supports security and can be used for a VPN. Routing
> isn't part of a tunnel (a tunnel ends in interfaces); routing happens in
> the overlay *to* that tunnel interface.

I didn't mention route optimization. With AERO, route optimization is what happens
when the tunnel ingress switches from an egress that is on a suboptimal path to a
different egress that is on a better path. Due to the link nature of the NBMA overlay,
that switching is accomplished through the use of IPv6 ND Redirect messages the
same as would occur on a physical link (and in the same spirit as published in RFC6706).
That is why I ended up agreeing with you that fully embracing fragmentation is the
only way to truly handle tunnel MTU, because without fragmentation an MTU that
worked over the suboptimal path might fail over the new path once route
optimization is employed.

> And traffic engineering is easy
> in a tunnel *if* it's supported in the base network over which the
> tunnel operates, and impossible otherwise.

Traffic engineering as in allowing the Client to select both the outbound underlying
interface for outbound traffic and the inbound underlying interface for inbound
traffic. So, a device that has both cellular and WiFi can send and receive packets
with different TOS markings over both interfaces simultaneously (e.g., TOS '1' goes
out over cellular, TOS '2' goes out over WiFI, etc.) and respectively for the
inbound direction.

> I'm not claiming this wouldn't be useful.  I'm saying that we need to
> know what problem it solves to know where to home it.

I have identified two very important use cases relating to aviation. So, the fortuitous
selection of the AERO acronym now seems quite appropriate. We are also using it for
mobile VPN management for corporate enterprise mobile device users (cellphones
and tablets), and we are planning to release source code soon.

Thanks - Fred
[e-mail]