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

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

Hi Joe,

The problem is, you continue to imply that there are problems. Unless you are willing
to read the document, cut it out.

About use cases, I think I said this before but here are three:


-          Corporate Mobile VPN users (cellphones, tablets, laptops, etc.)

-          Civil aviation networking

-          Unmanned Air Systems

That is only to name three. If you need more, let me know.

Thanks - Fred

From: Joe Touch [mailto:[e-mail]]
Sent: Monday, December 12, 2016 11:17 AM
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


Fred,

The question is not (yet) whether there are problems. The question is whether a new solution is required where existing mechanisms suffice.

Your doc has only one paragraph that describes anything close to a use case, but doesn't explain why AERO is *needed* to solve that case.

I.e., I've repeatedly looked and still don't find the answers there.

Joe

On 12/12/2016 8:00 AM, Templin, Fred L wrote:
Hi Joe,

Whatever. You seem to keep implying that there are problems, but I can assure
you there are none. Why not have a look at the document, because I think you
will find the answers to your questions there.

Thanks - Fred

From: Joe Touch [mailto:[e-mail]]
Sent: Friday, December 09, 2016 8:53 PM
To: Templin, Fred L <[e-mail]><mailto:[e-mail]>; Lucy yong <[e-mail]><mailto:[e-mail]>; Brian E Carpenter <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels


Fred,

On 12/9/2016 4:25 PM, Templin, Fred L wrote:
Hi Joe,

I read your document and, for the applications I am concerned with, I still
think what I am doing is the better approach. One thing that you may not
have gathered is that the AERO interface does not maintain a replicated copy
of the entire IP forwarding table;
I wasn't assuming it did - therein lies the problem.



it only keeps neighbor cache entries for its
currently active sets of neighbors. For AERO Clients, this would include the
default router(s) and any peers that it has recently received Redirects from.
For AERO Servers, the neighbor cache would include entries for the current
list of associated Clients. So, the AERO interface is not a full-blown IP router;
it is a neighbor discovery engine for its active set of neighbors.

But it would need to have the full-blown IP forwarding capabilities to determine which next IP address is intended for a given packet handed to it by the master IP forwarding table.



 So, unlike a dynamic routing protocol the AERO interface uses IPv6 Neighbor
Unreachability Detection (NUD) instead of routing protocol keepalives to
maintain reachability. There is also no routing protocol control messaging
going out over the underlying data links - it is simply data packets plus
occasional NUD messages.
That only describes how the table is populated. There's the further issue of how the table is indexed, which is a full-blown forwarding lookup (with policy information as well).



 I noticed that your document was from 1997, which is the same year I
started with SRI International. I think that was right around the time
you and I first met.

Not sure - it was presented in early 1997 at the GBN workshop at Infocom, but also at a few DARPA PI meetings before.

FWIW, I didn't think we met until the IETF, which was in Dec in DC that same year.

Joe