Re: [DMM] Going forward with the DMM work items

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

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
[e-mail]  

---

From: Satoru Matsushima [mailto:[e-mail]] 
Sent: Tuesday, October 07, 2014 2:34 AM
To: Templin, Fred L
Cc: [e-mail]; Dapeng Liu; [e-mail]
Subject: Re: [DMM] Going forward with the DMM work items

Hi Fred,

On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L <[e-mail]> 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