Joe, You specifically asked about how next-hop determination is done, and as is said in the document this is the role of the AERO address. So if the destination address is something like 2001:db8:1:2::1 then the next-hop address is simply fe80::2001db8:1:2 (i.e., a link-local address with the prefix of the destination in the interface identifier). So, next-hop determination is stateless and requires no message exchanges. Do you see a problem with that?
Thanks - Fred From: Int-area [mailto:[email protected]] On Behalf Of Templin, Fred L Sent: Monday, December 12, 2016 11:37 AM To: Joe Touch <[email protected]>; Lucy yong <[email protected]>; Brian E Carpenter <[email protected]>; [email protected] Subject: Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels 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:[email protected]] Sent: Monday, December 12, 2016 11:17 AM To: Templin, Fred L <[email protected]<mailto:[email protected]>>; Lucy yong <[email protected]<mailto:[email protected]>>; Brian E Carpenter <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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:[email protected]] Sent: Friday, December 09, 2016 8:53 PM To: Templin, Fred L <[email protected]><mailto:[email protected]>; Lucy yong <[email protected]><mailto:[email protected]>; Brian E Carpenter <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> 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
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
