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

Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 07 October 2014 21:23 UTC

Return-Path: <sarikaya2012@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 13ABD1A886A for <dmm@ietfa.amsl.com>; Tue, 7 Oct 2014 14:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 NIXH_OHZht1H for <dmm@ietfa.amsl.com>; Tue, 7 Oct 2014 14:23:12 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D03C1A8868 for <dmm@ietf.org>; Tue, 7 Oct 2014 14:23:12 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id hz20so7279858lab.11 for <dmm@ietf.org>; Tue, 07 Oct 2014 14:23:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b1HkMb19/RTTkm4QmEyjsoPpZAWP+gaWiEmXSHFfZ7Q=; b=Z2jKMocohtrJt5WmLu1P2q/mdNOLMFa3UrcJ1H5zy6+Qwsm9yaAiB495lysHFtKS8C 6KaVuJV7+JRqXJKWstrdnll51OyuvIx12jNUIRf6pj+lHHrIa6OoYxm567lFlXspw96j TAYDj1bSKtuc2eGS68E4Ppwapqk617csZWENJCox+V5aJkRQGdBohiKlNONS2NDuWpXa szHdd5a7pZHH3RfM2B0EsyuHJwS+uNX5/FWmsmQqkY4uiiDz4mWRCgzvuTlfM8PtxEz+ 3RFg5oSFrIFL2TJddySXd24PiSzqh336r/E8KS3ja1V8KV46HL771YbrsGOIdO3iZ8xQ kHVw==
MIME-Version: 1.0
X-Received: by 10.152.163.66 with SMTP id yg2mr6857785lab.38.1412716990404; Tue, 07 Oct 2014 14:23:10 -0700 (PDT)
Received: by 10.114.77.37 with HTTP; Tue, 7 Oct 2014 14:23:10 -0700 (PDT)
In-Reply-To: <CAFwJXX799gN_Fnrjy5WEXSqG1oriDdn8aU=1Mz9N7r=wyVAqsw@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> <CAFwJXX799gN_Fnrjy5WEXSqG1oriDdn8aU=1Mz9N7r=wyVAqsw@mail.gmail.com>
Date: Tue, 07 Oct 2014 16:23:10 -0500
Message-ID: <CAC8QAcc0KULP3sG_3Ho5ht1oUM_6BY=Enz-2-hp+7XvjZk2n8w@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: Satoru Matsushima <satoru.matsushima@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6G_qPhh0vxahXxfUFjkTkzXf-2g
Cc: "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
Reply-To: sarikaya@ieee.org
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 21:23:14 -0000

Hi Satoru,

Thank you for your comments on my draft, we will consider them in
revising it next time.

Let me say that I lived in Japan more than 7 years and I can probably
state that I am a bit familiar with the culture.
So my translation of your views is that these things happen in IETF
and we should live with them.

Yes, I agree that it happens but in IETF there is also freedom of
expression. We can and we should point the discrepancies and there is
nothing wrong to say that this (whatever it is) is wrong, people will
respect you more if you do that.

 Regards,

Behcet

On Tue, Oct 7, 2014 at 2:31 AM, Satoru Matsushima
<satoru.matsushima@gmail.com> wrote:
> 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