Re: [DMM] vepc draft Rev. 04

[Behcet Sarikaya <[e-mail]>]

Hi Satoru,

Thank you for your comments.
My replies inline.

Regards,

Behcet

On Thu, Jun 25, 2015 at 5:22 AM, Satoru Matsushima
<[e-mail]> wrote:
> 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.
>

Wait a minute, there is more.
It seems like you have not read Sections 4.2 and 4.3.
Yes, XMPP and OpenFlow are for Section 4.1 for switch control on
mobile backhaul.
This is related to a university project we were involved which used
public domain OpenFlow tools like OpenDayLight.

In route establishment, I am using Netconf or RPC protocol which you
missed big and that was one of the main additions in Rev. 02.
Please check it again.

> 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.
>

As I said in my mail before, I wonder why we need all those things?
Why do we need another client/server system maybe other than what i2rs
is defining?
I think this is a big question FPCP lovers should answer? My point is
that at least you should not need it in vEPC, I am saying that as
someone who supports vEPC :-)

> Thought?

Another main addition is Rev. 02 was Section 5 on multicast support
which you missed or not commented?

>
> Regards,
> --satoru
>
>
>
>
> On Wed, Jun 3, 2015 at 4:25 AM, Behcet Sarikaya <[e-mail]>
> wrote:
>>
>>  Hi Matsushima-san,
>>
>> On Fri, May 29, 2015 at 8:24 AM, Satoru Matsushima
>> <[e-mail]> wrote:
>> > Hi Behcet-san,
>> >
>> > On Wed, May 27, 2015 at 5:34 AM, Behcet Sarikaya
>> > <[e-mail]>
>> > 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
>> >
>
>