Subject: Re: [DMM] rechartering draft text updated

From: Alper Yegin <[email-masked]>
Date: Fri, 4 Apr 2014 15:47:36 +0300

Jouni,

One more thing:

      The DMM working group will also work on maintenance-oriented and
      incremental extensions to the Proxy Mobile IPv6 protocol, specified
      in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work primarily
      addresses any protocol gaps required to support existing deployments
      and other standards development organizations using the Proxy Mobile
      IPv6 protocol in their system architectures.

We shall not shut the door on the client-based mobility.
Hence, I propose the following revision:

      The DMM working group will also work on maintenance-oriented and
      incremental extensions to the Mobile IPv6 protocol, specified
      in RFC 5213, RFC 5844, and RFC 3775. 

I removed the last sentence because I wasn't sure if it really added any value.

Alper

On Mar 26, 2014, at 12:02 PM, Jouni Korhonen wrote:

> Folks,
> 
> Take a look at the latest revision. I have added the initial stab
> for the milestones. Comments and flames are welcome. If you want
> something to be changed, just propose text & diff. You might also
> want to say why the change is needed.
> 
> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt
> 
> - Jouni
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Jouni <[email-masked]>
Date: Fri, 4 Apr 2014 23:06:40 +0300

Alper,

Thanks for the proposed text. I am not entirely sure about the addition
of the client mobility. It was not discussed during the meeting when we
were advised to add the maintenance part.

What do the others think?

- Jouni

---

From: Peter McCann <[email-masked]>
Date: Fri, 4 Apr 2014 20:21:20 +0000

I think there may need to be some work on dynamic HA assignment
and security association configuration for client MIP.  This is
because DMM assumes that the MN will prefer the use of a locally
assigned, more topologically correct address, which means it will
need to set up dynamic relationships with HAs.  Ideally, the MN
would be able to use its network access credentials to set up the
SA with the HA.

Even if that HA is not used for the localized mobility (i.e., we
have netdmm or something) the HA would come in handy when the MN
has moved beyond the scope of the netdmm solution.  It could fall
back to client MIP in that case.  The netdmm solution could then
be used in place of gratuitous ND/ARP to get the packets to the HA
before they are tunneled to the MN on another network.  This would
widen the reach of the HA beyond a single link, and allow placement
of the HA near the boundary of the netdmm region instead of on the
link where the assigned address would fall topologically.

The HA would then become completely analogous to a base station/
access router, in that you use your network access credentials to
authenticate yourself to it, and where the remote tunnel connection 
is used instead of a wireless link.

-Pete

Jouni wrote:
> 
> Alper,
> 
> Thanks for the proposed text. I am not entirely sure about the
> addition of the client mobility. It was not discussed during the
> meeting when we were advised to add the maintenance part.
> 
>>       incremental extensions to the Proxy Mobile IPv6 protocol,
>>       specified in RFC 5213 and RFC 5844. The Proxy Mobile IPv6 work
>>       primarily addresses any protocol gaps required to support
>>       existing deployments and other standards development
>>       organizations using the Proxy Mobile IPv6 protocol in their
>>       system architectures.
>>       incremental extensions to the Mobile IPv6 protocol, specified in
>>       RFC 5213, RFC 5844, and RFC 3775.
>> 
>>> Take a look at the latest revision. I have added the initial stab for
>>> the milestones. Comments and flames are welcome. If you want something
>>> to be changed, just propose text & diff. You might also want to say
>>> why the change is needed.
>>> 
>>> https://github.com/jounikor/dmm-re- charter/blob/master/recharter_draf
>>> t.txt
>>> 
>>> - Jouni
>>>

---

From: Alper Yegin <[email-masked]>
Date: Sat, 5 Apr 2014 14:24:23 +0300

Hi Jouni,

For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'd do that -- naturally. I think this goes w/o saying. It's just part of the solution.
And I now think the charter text does not aim that aspect. 

I guess that PMIPv6 text is about maintenance of PMIPv6 outside the scope of DMM "problem space".
If PMIPv6 needs some extension that is not related to DMM, the place to do that in IETF would be the DMM WG.
If so, OK, that's an extra, which I have no objection.

I do not know specifically what we'd need to do on PMIPv6, or CMIPv6 (outside the scope of DMM space).
But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 06 Apr 2014 11:45:10 +0300

Alper,

> And I now think the charter text does not aim that aspect.

Right. Could be sloppy wording but if the DMM solution needs (P)MIPv6 
enhancements, those are in scope. They both have always been.

> If so, OK, that's an extra, which I have no objection.

This is correct, regarding the latest addition of maintenance text.

> But I cannot imagine why we'd let PMIPv6 go in but exclude MIPv6.

Ok. If you see it beneficial to add MIPv6 also into the maintenance 
part, then fine. Honestly, even if that gets mentioned there it is not 
to be considered and open invitation to work on client MIPv6 specific 
"outside DMM scope" topics just because it is in charter.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Apr 2014 14:13:20 -0500

Hi Jouni,

On Sun, Apr 6, 2014 at 3:45 AM, Jouni Korhonen <[email-masked]>wrote:

>> For the DMM solution, if we need extensions on the PMIPv6 or MIPv6, we'd
>> do that -- naturally. I think this goes w/o saying. It's just part of the
>> solution.
> Ok. If you see it beneficial to add MIPv6 also into the maintenance part,
> then fine. Honestly, even if that gets mentioned there it is not to be
> considered and open invitation to work on client MIPv6 specific "outside
> DMM scope" topics just because it is in charter.
>
>
The issue here is in a routing based approach such as vEPC or the flat
architecture MIP6 extension  may come into picture, as Pete explained.
So it is not MIP6 extensions that MIP6 based DMM protocol needs which is in
charter's scope already.

I hope this clarifies.

Regards,

Behcet

>>>> specified