Subject: Re: [DMM] rechartering

From: Jouni Korhonen <[email-masked]>
Date: Tue, 27 May 2014 11:50:49 +0300

Now that the gap analysis I-D is almost on the stage of leaving the WG 
and the requirements I-D has almost completed IESG, it would be time to 
return to the rechartering topic.

First, the latest revision can be found at:
https://github.com/jounikor/dmm-re-charter

Second, have a look at it. There are few changes proposed by Alper eons 
ago and corrected milestones pointed by Behcet.

Third, let us get this finally done..

- Jouni

4/22/2014 3:55 PM, Jouni Korhonen kirjoitti:
> Folks,
>
> Sorry for letting this topic to rot in a dark for the couple of last
> weeks. I'll crank out a revision shortly..
>
> - Jouni & Dapeng

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 May 2014 17:54:45 +0000

Hi Jouni,

I have one small edit to propose:

      "However, mobility management in a limited area, such as within an
      autonomous system, is not strictly limited to mentioned IP mobility
      protocols but can be any existing or a new protocol solution enabling
      the movement of a mobile node. Specifically, when solutions are not
      based on IP mobility protocols, the DMM working group should cooperate
      with other IETF working groups working on other technologies that
      might allow the mobility of an end host. These working groups include
      but are not limited to I2rs, Lisp, Idr and Forces."

Suggest changing the final two sentences to the following:

      "Specifically, when solutions are not based on IP mobility protocols,
       the DMM working group should cooperate with other IETF working groups
       and/or consider non-working group items working on other technologies
       that might allow the mobility of an end host. These working groups
       include but are not limited to I2rs, Lisp, Idr and Forces, while
       non-working group items are considered based on their merit."

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
> Sent: Tuesday, May 27, 2014 1:51 AM
> To: [email-masked]
> Subject: Re: [DMM] rechartering
> 
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 28 May 2014 03:11:02 +0300

Fred,

I think your concern (assuming you have SEAL et al in mind..) should 
already be convered by:

   [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963].
   However, mobility management in a limited area, such as within an
   autonomous system, is not strictly limited to mentioned IP mobility
   protocols but can be any existing or a new protocol solution enabling
   the movement of a mobile node.

- Jouni

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 28 May 2014 12:35:45 +0000

Hi Jouni, all,

let me pick up some comments again, which we should clarify. 

About anchor selection:

Referring to the milestones, having the anchor re-selection document
separated from the advanced anchor selection only by 3 months does not
seem to be useful, even if you consider re-selection to be used only for advanced
DMM deployment and operation, whereas basic anchor selection is required for
any DMM deployment with decentralized data plane anchors. 

I understand this document treats solely selection and runtime re-selection,
not the associated establishment of routing/tunnel states according to the
selected anchor. So, I think both aspects, selection and re-selection, should
go into a single document. Unless the WG decides that re-selection is too advanced,
then it may go into a separate document when the base selection spec is almost ready,
as it will depend on it.

About forwarding path and signaling management:

In particular if the support of runtime/mid-session anchor change is considered for the first
set of DMM solution documents, the described work item about 'forwarding
path and signaling management' should be given a milestone, as this is
essential if anchors are changed mid-session and IP address continuation
is expected. So far there is no document about this work item in the
charter list.

Inter-working between mobility functions and network nodes, e.g. routers,
requires the use of some non-mobility protocol. DMM should at least describe
which states (identifiers, locator addresses/IDs, ..) to expose through these
protocols. That's what I understood behind mobility state exposure, whereas
the text in the work items list reads more like this is about announcements
from the network to an MN about the characteristics of an IP address to support
the MN in picking the right address for an application. I know it's more a terms issue,
but we need clarification what we expect from a work item.

Hope the above makes sense and we can easily clarify.

marco

>Sent: Dienstag, 27. Mai 2014 10:51
>To: [email-masked]
>Now that the gap analysis I-D is almost on the stage of leaving the WG and the
>requirements I-D has almost completed IESG, it would be time to return to the
>rechartering topic.
>
>Second, have a look at it. There are few changes proposed by Alper eons ago
>and corrected milestones pointed by Behcet.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 May 2014 14:10:02 +0000

Hi Jouni,

I am OK with what you have if you think my concern is already
covered. BTW, I am no longer pushing forward with SEAL and am
interested in consideration for AERO:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

SEAL was trying to do too much to be all things to all people;
AERO is simple, and is really nothing more than IPv6 neighbor
discovery applied to tunnels.

Thanks - Fred

> From: Jouni Korhonen [mailto:[email-masked]]
> Sent: Tuesday, May 27, 2014 5:11 PM
> To: Templin, Fred L; [email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 28 May 2014 20:54:51 +0300

Marco,

> not the associated establishment of routing/tunnel states according to the

Actually, I was in an opinion that re-selection would also cover the 
needed parts for possible re-routing of traffic.. whatever the 
mechanisms is.

Does anyone else share the same view?

> is expected. So far there is no document about this work item in the

Right, any suggestions for the actual document name and time lines?

> but we need clarification what we expect from a work item.

The latter is what I had in mind.. mainly the MN<->network communication.

> Hope the above makes sense and we can easily clarify.

Sure.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 May 2014 08:40:35 +0300

> The latter is what I had in mind.. mainly the MN<->network communication.

Plus, the interaction between the apps and the IP stack on the MN.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 29 May 2014 21:26:48 +0300

> Plus, the interaction between the apps and the IP stack on the MN.

Correct.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 May 2014 23:17:26 +0300

Hello Jouni, folks,

Here are few more comments:

      DMM can be used to realise such a distributed deployment
      model, by distributing forwarding functions at optimal location; for
      example, closer either to the mobile user or the corresponding node.

We had already talked about that: s/mobile user/mobile node. 

     o Enhanced gateway & mobility anchor selection and re-selection: define 
        protocol solutions for a gateway and mobility anchor selection that
        go beyond what has been, for example, described in RFC 6097. The
        solution should also define a mechanism for anchor re-selection that allow
        preserving ongoing mobility sessions in a single administrative domain.
       
      o Forwarding path and signalling management: the mobility agent that handles
        the mobility signalling interacts with the network elements in the DMM network
        for managing the forwarding state associated with a mobile node's IP traffic.
        These two functions may or may not be collocated. Furthermore, the forwarding
        state may also be distributed into multiple network elements instead of a
        single anchor like network element. Define required protocol extensions to
        allow described forwarding path and signalling management.

GW selection and data-path management signaling may be defined in the same "solution" document. In at least some cases these are provided as part of the same solution set. They may also be separable, maybe, but we shall not be hung up on producing separate documents for these… The solution discussions will guide us… (no specific change required on the above text, more on this below…)

The milestones are missing any document that defines the "data-path management signaling" (what's mentioned above). And like I said before, that's "the"  product of this WG IMO. It'd of course be supplemented by GW selection and mobility state exposure bits to complete the picture.

Let's add another milestone:

Nov 2014 - Submit 'Forwarding path and signaling management' as a working group document. To be Proposed Standard.
Mar 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. To be Proposed Standard.

Cheers,

Alper

On May 27, 2014, at 11:50 AM, Jouni Korhonen wrote:

> 
> Now that the gap analysis I-D is almost on the stage of leaving the WG and the requirements I-D has almost completed IESG, it would be time to return to the rechartering topic.
> 
> Second, have a look at it. There are few changes proposed by Alper eons ago and corrected milestones pointed by Behcet.
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 29 May 2014 23:36:07 +0300

Alper,

> We had already talked about that: s/mobile user/mobile node.

Ack.

> GW selection and data-path management signaling may be defined in the
> same "solution" document. In at least some cases these are provided as
> part of the same solution set. They may also be separable, maybe, but we
> shall not be hung up on producing separate documents for these… The
> solution discussions will guide us… (no specific change required on the
> above text, more on this below…)
>
>
> The milestones are missing any document that defines the "data-path
> management signaling" (what's mentioned above). And like I said before,
> that's "the"  product of this WG IMO. It'd of course be supplemented by
> GW selection and mobility state exposure bits to complete the picture.
>
> Nov 2014 - Submit 'Forwarding path and signaling management' as a
> working group document. To be Proposed Standard.

Ack. Somewhat ambitious timeline though ;)

- Jouni

>> and the requirements I-D has almost completed IESG, it would be time
>> to return to the rechartering topic.
>>
>> Second, have a look at it. There are few changes proposed by Alper
>> eons ago and corrected milestones pointed by Behcet.
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 May 2014 15:52:37 -0500

Hi Jouni,

I was looking at the charter text and noticed one important issue. The
charter seems to be stuck with the good old anchor think. Almost all
text is about anchoring, anchor selection, anchor reselection, and so
on.

However in the past several months, we have seen in Alper's events,
presentations which seem to have no anchor.

I don't see any active draft that talks about the anchors.

In view of this, my question is how are we going to go ahead with this
charter and meet the deadlines?

Or else, are we better off with a charter text which is much less
dependent on the anchors, something  which could make it possible to
progress one of those proposals??

Regards,

Behcet

On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen <[email-masked]> wrote:
>
> Now that the gap analysis I-D is almost on the stage of leaving the WG and
> the requirements I-D has almost completed IESG, it would be time to return
> to the rechartering topic.
>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 30 May 2014 00:03:27 +0300

Bechet,

> charter and meet the deadlines?

I (myself) see still value dragging along some anchoring stuff just to 
allow smoother migration from current deployed models toward less 
centralized architectures.

But you are right that we should not get stuck on those.. and that has 
not been the intent either.

> progress one of those proposals??

You are welcome to propose concrete text & change snippets to the 
current charter text.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 May 2014 16:29:15 -0500

About two months ago I had made this proposal

First cycle, select one from each category of solutions, client,
network based and routing based
Second cycle, select one from the selected ones as the dmm solution.

which still stands, I think.

On Thu, May 29, 2014 at 4:03 PM, Jouni Korhonen <[email-masked]> wrote:
> I (myself) see still value dragging along some anchoring stuff just to allow
> smoother migration from current deployed models toward less centralized
> architectures.
>
> But you are right that we should not get stuck on those.. and that has not
> been the intent either.
>
>
> You are welcome to propose concrete text & change snippets to the current
> charter text.
>
> - Jouni
>
>
>>
>> Regards,
>>
>> Behcet
>>
>>
>>> and
>>> ago

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 30 May 2014 02:01:36 +0300

Bechet,

All what we discuss here has been discussed 2-4 months ago already. 
Repeating myself: propose concrete text & change snippets.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Fri, 30 May 2014 08:57:53 +0300

IMO, solutions that do not rely on "anchors" are welcome.
Even though the charter uses that term, we are not hung up on solutions that have "anchors"
Besides, remember I made an attempt to refine the term with an additional one "deflector"… So, we do need to have some discussions around that eventually.
But I don't think we need to have that right now in the context of the charter text.
As long as people understand that anchor-less solutions are welcome for discussion, and we may eventually refine the term, we can move forward with the current text -- I'd say.

Alper

On May 30, 2014, at 12:03 AM, Jouni Korhonen wrote:

> I (myself) see still value dragging along some anchoring stuff just to allow smoother migration from current deployed models toward less centralized architectures.
> 
> But you are right that we should not get stuck on those.. and that has not been the intent either.
> 
> You are welcome to propose concrete text & change snippets to the current charter text.
> 
> - Jouni
> 
>> 
>> Regards,
>> 
>> Behcet
>> 
>>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 30 May 2014 20:08:13 +0300

Agree.