Hi Satoru, >> That is too bad, because I will be briefing the AERO BGP routing system at >> the meeting tomorrow. > > Yes, sorry to say.
OK. The talk generated quite a few questions, and was followed by a demo of emulated network nodes running BGP and adding/withdrawing routes in response to emulated Client/Server associations. >> I read your proposal, but have not received any indication if you have read >> my AERO proposal yet. AERO uses >> BGP in a way that was first specified by RFC6179 in 2011 and carried forward >> into draft-templin-ironbis and >> draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of >> which AERO Client Prefixes (ACPs) >> are associated with which AERO servers. But, only the Servers are exposed to >> localized ACP mobility events; >> the BGP is only updated when an ACP moves to a new Server. This means that >> there will be very little churn >> in the BGP routing system itself. So, the BGP is not directly exposed to >> localized mobility events. > > I know you are the guy who invent ISATAP That was a long time ago. :^} > so I understand you may utilize same mechanism. Not exactly the same mechanism, but yes the same NBMA tunnel virtual link model. Once the virtual link is established, ordinary link-local services like DHCPv6 and IPv6 Neighbor Discovery (ND) can be used to manage Client/Server associations and Client mobility events. There is no need for any other control message signaling protocols. > You and me > look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility > management is assumed to exist so > the mobility management exports BGP mobility information into routing > information. Do you assume 3gpp > or ietf mobility management protocol/system in your draft as well? My draft presents a method for managing Client mobility based on DHCPv6 and IPv6 ND messaging in the same way that these functions would work on ordinary links. But Client mobility does not get propagated up to the Server/Relay BGP routing system unless the Client changes over to a new Server (which should happen only very infrequently). That said, the AERO BGP routing system can be used independently of the underlying Client mobility signaling - it is only concerned with announcing and withdrawing routes via BGP updates. >> AERO Clients use DNS discovery to discover the address(es) of nearby >> Server(s) as the default >> means. Other solutions such as manual configuration, DHCP option, etc. are >> also possible. > > Yes, I know, there are many type of endpoint discovery. Do you clear any > patent which claim > the right of dns based endpoint discovery? There are no patents that I am aware of. The AERO DNS discovery exactly parallels the discovery method used for ISATAP as found in widely deployed implementations. >> It would be nice if you were to review the AERO architecture and explain to >> me the way in which >> this requirement is or is not addressed already there. > Well, will do. I suppose today you provides explanation to extract aero into > three work items. > Thats works a lot for me to help reviewing the aero. I still don't feel like I fully understand the three work items, but it was said in the call (maybe by Alper?) that the enhanced anchoring team would be a place to discuss. I think we would find that AERO could also be discussed within the context of the other two teams as well. I think from my talk today people came away with a better understanding of the overall AERO architecture even though the talk and demo focused specifically on the BGP routing system. There was interest in having a more thorough discussion on the list, and I will start a new thread on that soon. Thanks - Fred fred.l.temp...@boeing.com --- From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] Sent: Tuesday, October 07, 2014 2:34 AM To: Templin, Fred L Cc: sarik...@ieee.org; Dapeng Liu; dmm@ietf.org Subject: Re: [DMM] Going forward with the DMM work items Hi Fred, On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L <fred.l.temp...@boeing.com> wrote: Hi, > Maybe I can't attend next webex meeting tomorrow. That is too bad, because I will be briefing the AERO BGP routing system at the meeting tomorrow. Yes, sorry to say. I read your proposal, but have not received any indication if you have read my AERO proposal yet. AERO uses BGP in a way that was first specified by RFC6179 in 2011 and carried forward into draft-templin-ironbis and draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of which AERO Client Prefixes (ACPs) are associated with which AERO servers. But, only the Servers are exposed to localized ACP mobility events; the BGP is only updated when an ACP moves to a new Server. This means that there will be very little churn in the BGP routing system itself. So, the BGP is not directly exposed to localized mobility events. I know you are the guy who invent ISATAP so I understand you may utilize same mechanism. You and me look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility management is assumed to exist so the mobility management exports BGP mobility information into routing information. Do you assume 3gpp or ietf mobility management protocol/system in your draft as well? Anycast has been widely used in other router discovery solutions. Two cases are 6rd [RFC5969] and 6to4 [RFC3068]. But, anycast has known operational problems in real networks, and in fact has caused major headaches for 6to4 - even to the point that its deprecation is currently being called for: http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html AERO Clients use DNS discovery to discover the address(es) of nearby Server(s) as the default means. Other solutions such as manual configuration, DHCP option, etc. are also possible. Yes, I know, there are many type of endpoint discovery. Do you clear any patent which claim the right of dns based endpoint discovery? It would be nice if you were to review the AERO architecture and explain to me the way in which this requirement is or is not addressed already there. Well, will do. I suppose today you provides explanation to extract aero into three work items. Thats works a lot for me to help reviewing the aero. Cheers, --satoru _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
