Subject: Re: [DMM] rechartering

From: Jouni Korhonen <[email-masked]>
Date: Mon, 02 Jun 2014 08:37:26 +0300

Are we getting into acceptable text now?  Any further wishes? If you 
want something to be addressed propose the text change/addition/removal.

- Jouni

5/30/2014 8:57 AM, Alper Yegin kirjoitti:
> 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:
>
>> Bechet,
>>
>> 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti:
>>> 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?
>>
>> 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.
>>
>>> 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??
>>
>> You are welcome to propose concrete text & change snippets to the current charter text.
>>
>> - Jouni
>>
>>>
>>> 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.
>>>>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> dmm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>> _______________________________________________
>> dmm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 2 Jun 2014 16:38:41 +0900

Jouni and Alper

On 2014/05/31, at 2:08, Jouni Korhonen <[email-masked]> wrote:

> Agree.

+1

The text looks good to me. I am eager to have solution discussion.

ryuji

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 2 Jun 2014 08:11:59 +0000

I don't have a problem with the anchor term if we treat it as a function in the network which knows
how to further forward packets to an MN's location. That can be any tunnel management protocol,
aka (P)MIPv6, and should be orthogonal to the DMM solutions. That function can be also a router/switching
component in the network topology and the MN's IP address can be topologically correct on this
component, or incorrect, e.g. in case of (user-plane) anchor relocation and demand for IP address continuity.
IMO, DMM is a lot about solutions to route packets through the transport network and deliver them
to the MN's current anchor. Remaining delivery is up to tunnel management, which diminishes if these anchors
are deployed on the very edge, e.g. radio base stations.

marco

>-----Original Message-----
>From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
>Sent: Freitag, 30. Mai 2014 07:58
>To: Jouni Korhonen
>Cc: [email-masked]
>Subject: Re: [DMM] rechartering
>
>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.
>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
>
>
>
>>> 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.
>>>
>>> In view of this, my question is how are we going to go ahead with
>>> this 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.
>>
>>>> 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.
>>>>
>>>>> 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: Marco Liebsch <[email-masked]>
Date: Mon, 2 Jun 2014 08:22:41 +0000

Jouni,

>From: Jouni Korhonen [mailto:[email-masked]]
>Sent: Mittwoch, 28. Mai 2014 19:55
>To: Marco Liebsch; [email-masked]
>Marco,
>5/28/2014 3:35 PM, Marco Liebsch kirjoitti:
>> 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
>
>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.

Ok, if we are clear about this, I am fine. To confirm your understanding: the milestone
about anchor selection is solely about the selection process, while the milestone about
anchor re-selection is about runtime selection of a new anchor plus traffic routing. Correct?

Then I still believe it would make sense to cover that in a single document. If we want to
separate documents, then we may address anchor selection and runtime re-selection (just the selection)
in a single document, as the same algorithms and protocol components should apply to find a
suitable anchor, whereas a separate document treats the traffic routing to the selected anchor.

No too strong opinion here and no push to change wording as long as the listed milestones
allow all required work to be done.

>
>Does anyone else share the same view?
>
>> 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.
>
>Right, any suggestions for the actual document name and time lines?

That one I understand is associated with the traffic routing in the above
documents, no?

marco

>
>> 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.
>
>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
>
>
>>
>> marco
>>
>>
>>
>>
>>> From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
>>> Sent: Dienstag, 27. Mai 2014 10:51
>>> To: [email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 2 Jun 2014 11:33:22 -0500

On Thu, May 29, 2014 at 6:01 PM, Jouni Korhonen <[email-masked]> wrote:
> Bechet,
>
> All what we discuss here has been discussed 2-4 months ago already.
> Repeating myself: propose concrete text & change snippets.
>
Jouni, you asked for it, you get it:

I see these three charter items and I don't understand why we have them?
             Enhanced gateway and mobility anchor selection

            Forwarding path and signaling management

            Gateway and mobility anchor re-selection

I suggest making a single charter item as dmm solution protocol so
that we don't have to look at many documents for whatever solution we
select.

I see this item and I don't understand what it is about:

                   Exposing mobility state to mobile nodes and network nodes

Is this about the MN dealing with many prefixes?

What if the solution does not require the MN to deal with many prefixes?

It seems like this  charter was written from the point of view of what
we had way back in 2012.
Now we are in 2014 and a lot has changed and these changes are not
reflected in the charter.

Regards,

Behcet

> - Jouni
>
>
> 5/30/2014 12:29 AM, Behcet Sarikaya kirjoitti:
>
>> 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:
>>>
>>> Bechet,
>>>
>>> But you are right that we should not get stuck on those.. and that has
>>> not
>>> been the intent either.
>>>
>>>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 03 Jun 2014 13:59:53 +0300

Bechet,

>              Gateway and mobility anchor re-selection

Ok..

> that we don't have to look at many documents for whatever solution we

And the text for the change you propose is..?

> Is this about the MN dealing with many prefixes?

It is mostly about that and being able to advertise and configure 
addresses for a specific use case (e.g. prefix1 offers network based 
mobility, prefix2 provides connectivity to "value added services" and 
perfix3 is just about internet access without stating anything more).

> What if the solution does not require the MN to deal with many prefixes?

Then it doesn't.. if the MN does not need some enhancement / protocol, 
it does not need to implement one just because there is a milestone for 
one or a protocol out there.

The challenge is to make sure that the protocol defined here actually 
does not break legacy MNs or those who choose not to make use of some 
protocol extension.

> reflected in the charter.

Fair point. So, let's try to modernize the charter.

- Jouni