Re: [DMM] vepc draft Rev. 04

Satoru Matsushima <satoru.matsushima@gmail.com> Thu, 25 June 2015 10:22 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 002A51B3515 for <dmm@ietfa.amsl.com>; Thu, 25 Jun 2015 03:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.401
X-Spam-Level:
X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=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 i-u9ay86jNiW for <dmm@ietfa.amsl.com>; Thu, 25 Jun 2015 03:22:49 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFF21B32DC for <dmm@ietf.org>; Thu, 25 Jun 2015 03:22:47 -0700 (PDT)
Received: by igin14 with SMTP id n14so52237778igi.1 for <dmm@ietf.org>; Thu, 25 Jun 2015 03:22:47 -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=9bfXqCMlYnaJu+qf1LYU8JW1NI15wrkFrRDmTWAnEcM=; b=tj5dxA5gt2a1iSIjyc5nL46MTvJ6gPSIsfaoPFmbKQfZ7Dgb9gCF5EXGV2ShNYIGGP bsTe2mjwK/dFfJYH4103nrqtbwcoXlAGO5zQldTcPLY5FptbzDoiI9r7dwg60jQyrPiy Yy2wfaJtCo+xkrkp4jzq4E7m98KWhH2jPMjhwo16H2l+k8udxVqnNleMsb0MEdeCJN2K AR7j8CNT9jF01h7RnuoA47d2RIvtFk1sW+TlQ4Ag8xPmsAb6VaVWf7mJicH3s0DO7Nkz D5UW3zNYoZRedst46aaeKB2+5282d167J4iO2T5YM5Y8zLmauUceT5BNURKrql7+hB+K 5jcQ==
MIME-Version: 1.0
X-Received: by 10.43.164.66 with SMTP id mr2mr41854356icc.85.1435227766974; Thu, 25 Jun 2015 03:22:46 -0700 (PDT)
Received: by 10.36.155.139 with HTTP; Thu, 25 Jun 2015 03:22:46 -0700 (PDT)
In-Reply-To: <CAC8QAccadmdD0s6q1qCzY54xw8mVhqpAAHWKmh_+S7ZsMMpi+A@mail.gmail.com>
References: <CAC8QAccTQwa9p7+q8S40UtmZ2QdNEeYqVAzC_6hM37Wy2KRGrQ@mail.gmail.com> <CAFwJXX6O+WKngm_vd0XwcZKAouYuQ-zPQMD87JGeNa7Yqo+NhQ@mail.gmail.com> <CAC8QAceUkRYMZr-L3LDnjRmhdB+m4PEOv9cvz1xtGezCnzJdHw@mail.gmail.com> <CAFwJXX5kEXMM4CWug4yHA_CfFFTyqxBysdn=qG1hfhHhVotiHg@mail.gmail.com> <CAC8QAccadmdD0s6q1qCzY54xw8mVhqpAAHWKmh_+S7ZsMMpi+A@mail.gmail.com>
Date: Thu, 25 Jun 2015 19:22:46 +0900
Message-ID: <CAFwJXX5St4nJxz_v2feA0C2OGeN1+2vcAjnf1_z6nYt3rp2Vhw@mail.gmail.com>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Content-Type: multipart/alternative; boundary="001a11c2f3b238f002051955011f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dmm/w0mC5dz0nwEQSd5XkHDMAOi_yO0>
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] vepc draft Rev. 04
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 25 Jun 2015 10:22:51 -0000

Hi Behcet,

Sorry for my late response.

As I looked over your dmm-for-wifi draft, I found two protocols to be used
to separate
control and data plane such as XMPP and OpenFlow.

It seems like you want to work on that protocols to be implemented in data
plane nodes.
OpenFlow is another forum controlled protocol so I don't touch it in the
IETF.
XMPP sounds nice. If you adopt XMPP with same model of
draft-ietf-l3vpn-end-system,
it almost same with using BGP like the vEPC draft.

But what I mentioned FPCP in vEPC is as a way to export mobility info to
BGP speaker
from control-plane nodes of mobility management.

And more, many parameters should be aligned for these nodes to utilizing
data-plane
network so that the config data model should also be defined in FPCP. I
think that's not
part of signaling protocol roles.

Thought?

Regards,
--satoru




On Wed, Jun 3, 2015 at 4:25 AM, Behcet Sarikaya <sarikaya2012@gmail.com>
wrote:

>  Hi Matsushima-san,
>
> On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima
> <satoru.matsushima@gmail.com> wrote:
> > Hi Behcet-san,
> >
> > On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya <sarikaya2012@gmail.com
> >
> > wrote:
> >>
> >> Hi Satoru,
> >>
> >> Thanks for your reply.
> >>
> >> Let me continue the discussion with your text in Section 3.2 where you
> >> mention
> >> vEPC may utilizes Forwarding Policy Configuration Protocol (FPCP)
> >> that defines FPCP Agent function and Client function.
> >>
> >> I don't understand how you could justify defining a new forwarding
> >> policy configuration protocol to do this Agent/Client functionality?
> >> Why not use similar Agent/Client models that are being defined rather
> >> than defining a new protocol?
> >> I think this point requires much stronger justification which I could
> >> not see in Section 3.2.
> >>
> >
> > The text just describes about a part of where FPCP may be applicable in
> > vEPC.
> >
> >
> >
> >>
> >> Are you that we have to to reinvent the wheel, rather than reusing
> >> something that is already available? How are we going to reinvent that
> >> wheel also remains to be seen, I think.
> >>
> >
> > Point taken. Which kind of wheel do you have in mind?
>
>  Please check this draft:
> https://tools.ietf.org/html/draft-sarikaya-dmm-for-wifi-02
>
> Regards,
>
> Behcet
> >
> > cheers,
> > --satoru
> >
>