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

Satoru Matsushima <satoru.matsushima@gmail.com> Tue, 07 October 2014 07:31 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 121AB1A9139 for <dmm@ietfa.amsl.com>; Tue, 7 Oct 2014 00:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] autolearn=ham
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 4V9hqohYWCPZ for <dmm@ietfa.amsl.com>; Tue, 7 Oct 2014 00:31:12 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93891A6FCB for <dmm@ietf.org>; Tue, 7 Oct 2014 00:31:12 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id t59so2754698yho.1 for <dmm@ietf.org>; Tue, 07 Oct 2014 00:31:12 -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=KS7jyNq3gHQMAIlcXhpU5qVGHzMnwRrMtuPLWDwm5fM=; b=LltNmiEumVEqZmuA/kUTZorBYUy/X8i6nBls0C/UtjEeeXq+3Jr/tgBOUjH1XOcwIL uCqyH3jbojVdE4xherUY1IX+l2ZnVJ9fGHfxPhI50kB3dLNp0Brv0xefd2b+k2uQ7dyV 9awWjScwT7riVGJaMqxk8vbXANqzxTZ/wiaY7beYd5alwgISH5dYDBrURK1kjRIussFg HoMPlwaELQ0VazC3rvSHv7gRO3Vup2zMc/OuJPZ3wXZSh6jSXhwXuCxCfZubBOq4PzGx 6goae5t/+1Z4UIQGfppKUsihutj0bEyrNBP7CA/25BQXIiTuHDAfSB43b2iUjAIidwAF WZCw==
MIME-Version: 1.0
X-Received: by 10.236.51.201 with SMTP id b49mr2980333yhc.33.1412667072093; Tue, 07 Oct 2014 00:31:12 -0700 (PDT)
Received: by 10.170.54.198 with HTTP; Tue, 7 Oct 2014 00:31:11 -0700 (PDT)
In-Reply-To: <CAC8QAcd4i3d3dPWyqY3oMBBjtvjAVdDG5BScgPmTMqyeKS+4xA@mail.gmail.com>
References: <5424FEFA.2050008@gmail.com> <CAC8QAcdjULeUT53aF_wCrFZSi2tXhs+u3fToyR9z3t3zVn+Tcg@mail.gmail.com> <CAFwJXX6Hd3gFnLncGV_7rxk3oSosvSeoVKLRRLr3eTxOZ0vfKw@mail.gmail.com> <CAC8QAcd4i3d3dPWyqY3oMBBjtvjAVdDG5BScgPmTMqyeKS+4xA@mail.gmail.com>
Date: Tue, 07 Oct 2014 16:31:11 +0900
Message-ID: <CAFwJXX799gN_Fnrjy5WEXSqG1oriDdn8aU=1Mz9N7r=wyVAqsw@mail.gmail.com>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
To: sarikaya@ieee.org
Content-Type: multipart/alternative; boundary="089e013a1caa04a6110504d02f5b"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/80ZwrZXemf-E-jxQlUzcQyWRcZA
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 07:31:15 -0000

Hi Behcet,


On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya <sarikaya2012@gmail.com>
wrote:

>
> I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi
> we proposed new approaches like SDN.
>
>
Please don't get me wrong. My position hasn't been changed. BGP is used to
forwarding path management signaling.

In your draft, XMPP is the protocol that has same role of BGP. Good idea,
it is a pub-sub system as same as BGP. You may need to define data model
for dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs
either xmpp, netconf, or forces.

I suppose that you might want to adopt end-system VPN (
https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data
modeling. (actually it is BGP. :-) And, as you may know that there is a
draft which mentions about use case of BGP in i2rs. (
http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases)


> Having said that I don't think that the charter text on forwarding
> path and signaling is talking about the same thing.
>
>
Interesting. What do you expect for the charter text?
Why not you ask Marco, Anthony and Alper to explain their thought?



>
> In DMM fir WiFi we also adopted the anycast discovery, what is wrong with
> that?
>

How do you find the anycast address itself?



>
> Yes I agree, maybe other techniques like AAA can be worked out. Why
> not do it as extensions?
>
>
I suppose that it would be a part of enhanced anchoring work, isn't it?



> Really? My thinking was that vEPC does not need any involvement from
> MN because the prefix assigned to MN does not change.
>
> As I mentioned in my more recent mail, I think this item is based on
> 2102 solution proposals in which MN had to deal with many prefixes.
>
> Can you clarify which network nodes need exposure to MN mobility
> state? The ones on the path already know MN prefix, right?
>
>
Quite not. I meant disclosing mobility information to network node that
likes such as BGP speaker.



> So you are saying that these three items gave you some good ideas to
> think about on how you can improve your solution, vEPC.
>
>
In my view, the charter items work well to achieve vEPC architecture model,
yes.
More precisely, as the result of discussions which I had so far with many
dmm people, I have noticed some parts which the draft needs more work to
achieve the architecture model.


> You are indicating that there is a major solution proposal, i.e. vEPC
> by you, but that can be improved here and there.
>
> You are missing the point that such a view point is not yet agreed by the
> group.
>

I know. So I am trying to express my thought, and then we can recognize
differences each other, and we can discuss. It's normal process in the ietf
I think.


>
> Without such an agreement on the base, isn't it quite concerning what
> the WT's or DT's will do?
>
> My understanding is that the formation of WT's or DT's is another way
> of saying that we don't like all those solutions out there, we will
> design our own solutions to the above 3.
>

I guess wg management, who are responsible to establish dmm standard,
expect standardizing dmm solution would be very hard work because they find
many variants for it. In that situation, it would be reasonable that they
appoint some persons to lead the work. I really appreciate those persons
who volunteer to take that role to out consolidated solution.

Cheers,
--satoru