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

Satoru Matsushima <satoru.matsushima@gmail.com> Tue, 07 October 2014 09:34 UTC

Return-Path: <satoru.matsushima@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4595D1ACCD8 for <dmm@ietfa.amsl.com>; Tue, 7 Oct 2014 02:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.485
X-Spam-Level:
X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhQWfKuMKUVP for <dmm@ietfa.amsl.com>; Tue, 7 Oct 2014 02:33:58 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848C01ACCDC for <dmm@ietf.org>; Tue, 7 Oct 2014 02:33:58 -0700 (PDT)
Received: by mail-yh0-f41.google.com with SMTP id i57so2835210yha.0 for <dmm@ietf.org>; Tue, 07 Oct 2014 02:33:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7tPRTVRBw6FekVtgS4VzEC318NFWoJ+QeaXfdtGM2OY=; b=UCzlcYLUdqb8ok+lDryGePidW2pTFyf0WcL+dOzFdOmn4SHRUrTrUcoTml99Dg5Aj0 fDYzw6YSC7R11RRCd2NUAqrTXVMRE026qenrQBFiANKVn/e+NmlgDvGvg/76VL9b18GT KO1C/EaYnrNYSK70jDNcPPpjF4eUS0j7lAKYDe6hTJjnyHT5A4Bei8sVVE3TBW5PAUsW 8uijpkIykWdAtBbAOe0opQkXGi0tXaG/fgbrotokLTNW32oTcPase+v43jSOCveUrU/a r0eiMeuGBSHKaxTmLmee7uasawuy8Nf2kow9K0KSoEd/bo3FiNlQLpavwgC4mvUsIVDZ uH+A==
MIME-Version: 1.0
X-Received: by 10.236.128.33 with SMTP id e21mr600333yhi.187.1412674437835; Tue, 07 Oct 2014 02:33:57 -0700 (PDT)
Received: by 10.170.54.198 with HTTP; Tue, 7 Oct 2014 02:33:57 -0700 (PDT)
In-Reply-To: <2134F8430051B64F815C691A62D9831832D381B3@XCH-BLV-504.nw.nos.boeing.com>
References: <5424FEFA.2050008@gmail.com> <CAC8QAcdjULeUT53aF_wCrFZSi2tXhs+u3fToyR9z3t3zVn+Tcg@mail.gmail.com> <CAFwJXX6Hd3gFnLncGV_7rxk3oSosvSeoVKLRRLr3eTxOZ0vfKw@mail.gmail.com> <2134F8430051B64F815C691A62D9831832D381B3@XCH-BLV-504.nw.nos.boeing.com>
Date: Tue, 07 Oct 2014 18:33:57 +0900
Message-ID: <CAFwJXX7fvYJg6LBmB8fWXgNid9OEL5rHt4_2vsU-exWGH=tQ4Q@mail.gmail.com>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: multipart/alternative; boundary="20cf3011dacd0cef0c0504d1e6de"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/0BDdZL3KaNv5FKK-Xfo3oK0kYC0
Cc: Dapeng Liu <liudapeng@chinamobile.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Going forward with the DMM work items
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Oct 2014 09:34:00 -0000

Hi Fred,

On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L <Fred.L.Templin@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