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