Subject: [DMM] re-charter text updated

From: Jouni Korhonen <[email-masked]>
Date: Mon, 17 Mar 2014 14:41:38 +0800

Folks,

I have updated the charter draft text slightly:
https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt

Basically:

Added Sri's comment on PMIPv6 maintenance.
Added Alper's comment of location of mobility functions.
Added links to other IETF WGs on possible mobility enabling technologies.
Added a comment that virtualised network functions are in scope.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 17 Mar 2014 03:29:57 -0500

Hi Jouni,

Reading your milestones:
Submit I-D 'Solution Requirements' to the IESG for consideration as an
Informational RFC.
  Submit I-D 'Gap Analysis' to the IESG for consideration as an
Informational RFC.

I came to the conclusion that we are the loop doing the same or similar
things over and over again.

Why?

Regards,

Behcet

On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen <[email-masked]>wrote:

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 17 Mar 2014 17:16:18 +0800

On Mar 17, 2014, at 4:29 PM, Behcet Sarikaya <[email-masked]> wrote:

> Hi Jouni,
> 
> Reading your milestones:
> Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC.
>   Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.
> 
> I came to the conclusion that we are the loop doing the same or similar things over and over again.
> 
> Why?

Because our text editing has not even reached milestones part of the
charter text. That's why.

- Jouni

> 
> Regards,
> 
> Behcet
> 
> 
> 
> On Mon, Mar 17, 2014 at 1:41 AM, Jouni Korhonen <[email-masked]> wrote:
> Folks,
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Mar 2014 10:20:11 +0800

Folks,

Triggered by the question from Behcet, we should come up with the 
milestones. Few proposals:

o The deployment models and scenarios I-D is obvious.
o Anchor selection I-D is obvious. Could we also bundle
  the re-anchoring solution into this one or should it be
  a different I-D?
o Mobility state exposing I-D. This would communication 
  between the end host and the network. Maybe also covering 
  the missing parts within the end host.. Are we OK with one
  I-D or how people want to see this?
o ..

- Jouni

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 18 Mar 2014 03:49:15 +0000

>  the re-anchoring solution into this one or should it be

IMO, these are two different topics and can be kept as separate work items.

Anchor selection is tied to access network, request path, policy,
handovers and load on the target elements. The entity using the gateway
selection can be a end point, a network node or a policy system. The bulk
of the work is around laying out the considerations for gateway selection
and specifying the logic. The selection to most part is about the
assigning a gateway during initial session establishment.

Session Re-anchoring is about moving a session state between gateways,
after the session got established. It has impact on the forwarding plane
and is more about a routing problem. But, you may argue this is also
touching the aspect of gateway (re)-selection at a failure point. In this
sense there is some relation there, but it depends on how the re-anchoring
solution is specified.

IMO, its better to track them as separate work items.

>  I-D or how people want to see this?

Single ID is fine. 

Regards
Sri

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 18 Mar 2014 00:07:40 -0400

Hi,

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> (sgundave)
> Sent: Monday, March 17, 2014 11:49 PM
> To: Jouni Korhonen; [email-masked]
> Subject: Re: [DMM] re-charter text updated
> 
> 
> 
handovers
> and load on the target elements. The entity using the gateway
selection can
> be a end point, a network node or a policy system. The bulk of the
work is
> around laying out the considerations for gateway selection and
specifying
> the logic. The selection to most part is about the assigning a gateway
during
> initial session establishment.
> 
> after the session got established. It has impact on the forwarding
plane and
> is more about a routing problem. But, you may argue this is also
touching
> the aspect of gateway (re)-selection at a failure point. In this sense
there is
> some relation there, but it depends on how the re-anchoring solution
is
> specified.

[JCZ] +1

> >  I-D or how people want to see this?

[JCZ] Single ID is fine indeed. However, we still need to assess whether
this will be a DMM or a MIF ID.

Regards,

Juan Carlos

---

From: <[email-masked]>
Date: Tue, 18 Mar 2014 08:41:18 +0000

Hi,

Mobility issues are not specifically in MIF scope. So, as long as we are talking about exposing mobility state, the I-D should be in DMM. Another reason is that MIF is still discussing the generic MIF API, so, I'm not sure they can go on the mobility  area before a while.

Pierrick

>-----Message d'origine-----
>De : dmm [mailto:[email-masked]] De la part de Zuniga, Juan Carlos
>Envoyé : mardi 18 mars 2014 05:08
>À : Sri Gundavelli (sgundave); Jouni Korhonen; [email-masked]
>Objet : Re: [DMM] re-charter text updated
>
>Hi,
>
>[JCZ] Single ID is fine indeed. However, we still need to assess whether this
>will be a DMM or a MIF ID.
>
>Regards,
>
>Juan Carlos
>
>>
>>
>> Regards
>> Sri
>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Mar 2014 11:07:03 +0200

>  the re-anchoring solution into this one or should it be

I'd say re-anchoring is a separate I-D.

Btw, I take "anchor selection" as the process/algorithm for selecting the type of anchor (e.g., one in access or core or corresponding network), and selecting a specific anchor node of that type (e.g., determining its IP address).

If so, that can be an I-D.

But then, how the data-path is setup and maintained between the MN and the anchor across handovers is another I-D. 
And in fact, that's where more than one solutions is likely…. So, limiting this as "one I-D" may not work.

>  I-D or how people want to see this?

There's the API aspect on the terminal (one I-D),
and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.)

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 18 Mar 2014 11:07:53 +0200

I agree, let's not mixup DMM API with MIF API….

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Mar 2014 21:48:20 -0500

My suggestion is that we should be to the point.
We should discuss specific solution drafts first. This could be the first
charter item.

Then we should go to the solution selection phase.
This could be another charter item.

Solution drafts can be classified easily as
Client mobility based,
network mobility based and
Routing based

We already have drafts on each of these. new revisions can be submitted in
due course.

WG can take some time (~6 months) to consider each.

Terminology and sub-solutions should be considered parts of each category.

Once we have all those, then we can go to the solution selection phase.
In this phase WG makes a decision and those selected become WG documents.

Regards,

Behcet

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 20 Mar 2014 11:01:27 +0800

I split the gateway selection & re-anchoring.

Goals and Milestones:
  aaa 2014 - Submit 'The deployment models and scenarios' as a working
             group document. To be Informational RFC.
  bbb 2014 - Submit 'Enhanced gateway and mobility anchor selection' as
             a working group document. To be Proposed Standard.
  ccc 2014 - Submit 'Gateway and mobility anchor re-selection' as a
             working group document. To be Proposed Standard.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 20 Mar 2014 12:03:45 +0800

Alper,

> and there is the MN-network interface ones (e.g., extending RA, DHCP, etc.)

So you want an API document? I have some reservations documenting
an APIs as-is. Could this be an extension to RFC5014? I'd see this
approach feasible since there are even (partial) implementations of
the RFC5014 in popular operating systems.

Then the subsequent thing. Each MN-NW interface would be one document,
if I understand the above comment correctly? Which one(s) to do first?
ND or/and DHCP?

- JOuni

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Mar 2014 08:58:36 +0200

Hi Jouni,

> the RFC5014 in popular operating systems.

Yes, we are talking about extensions to source address selection (RFC 5014).

> if I understand the above comment correctly? Which one(s) to do first?

Yes. Both.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 20 Mar 2014 16:30:25 +0800

> Yes, we are talking about extensions to source address selection (RFC 5014).

Ack.

>> if I understand the above comment correctly? Which one(s) to do first?

Ack. Since we are coming up with I-D numbers, any preference
on the protocols that we patch..?

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Thu, 20 Mar 2014 10:41:43 +0200

> on the protocols that we patch..?

between ND and DHCP? DHCP….

Alper

---

From: <[email-masked]>
Date: Thu, 20 Mar 2014 08:44:51 +0000

>De : dmm [mailto:[email-masked]] De la part de Alper Yegin
>Envoyé : jeudi 20 mars 2014 09:42
>À : Jouni Korhonen
>Cc : [email-masked]
>>>>>> o Mobility state exposing I-D. This would communication between
>>>>>> the end host and the network. Maybe also covering the missing
>>>>>> parts within the end host.. Are we OK with one I-D or how people
>>>>>> want to see this?
>>>>>> o ..
>>>>>>
>>>>>
>>>>> There's the API aspect on the terminal (one I-D), and there is the
>>>>> MN-network interface ones (e.g., extending RA, DHCP, etc.)
>>>>
>>>>
>>>> So you want an API document? I have some reservations documenting an
>>>> APIs as-is. Could this be an extension to RFC5014? I'd see this
>>>> Then the subsequent thing. Each MN-NW interface would be one
>>>> document, if I understand the above comment correctly? Which one(s) to
>do first?
>>>> ND or/and DHCP?
>>>>
>>>
>>> Yes. Both.
>>
>> Ack. Since we are coming up with I-D numbers, any preference on the
>> protocols that we patch..?
>>
>
>between ND and DHCP? DHCP..
>

I'd say ND first :-)...  but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same.

>>>>>>> https://github.com/jounikor/dmm-re-
>charter/blob/master/recharter_
>>>>>>> draft.txt
>>>>>>>
>>>>>>> Basically:
>>>>>>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 20 Mar 2014 17:55:37 +0900

Jouni

It’s good to see some room for non-MIP based solution in DMM;-)

One clarification, the charter said following

      "Specifically, when solutions are not
      based on IP mobility protocols, the DMM workingvgroup shall 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, and Forces."

If we need to extend existing non-MIP protocols, it is reasonable to 
do extension in the working group owning the protocol. I agree on the charter.

However, DMM should work on documenting “how to use it”.  The document should 
be informational or experimental.  Is this scope of DMM? 

btw, you may add IDR in the listed of working group.

thanks
ryuji

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 20 Mar 2014 17:00:03 +0800

> I'd say ND first :-)...  but, anyway, do we really need two different documents? Although, container differs, I guess extensions will be the same.

Second the ND thing ;)

Why two docs.. DHCP is usually easy going as you can practically shove a flock of pigeons into it and people are just fine. ND is always a different story ;) 

- JOuni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Mar 2014 04:22:32 -0500

+1

Regards,

Behcet

---

From: <[email-masked]>
Date: Thu, 20 Mar 2014 09:25:46 +0000

>De : Jouni Korhonen [mailto:[email-masked]]
>Envoyé : jeudi 20 mars 2014 10:00
>À : SEITE Pierrick IMT/OLN
>Cc : Alper Yegin; [email-masked]
>>> Envoyé : jeudi 20 mars 2014 09:42 À : Jouni Korhonen Cc :
>>> [email-masked] Objet : Re: [DMM] re-charter text updated
>>>
>>>
>an
>> I'd say ND first :-)...  but, anyway, do we really need two different
>documents? Although, container differs, I guess extensions will be the same.
>
>Second the ND thing ;)
>
>Why two docs.. DHCP is usually easy going as you can practically shove a flock
>of pigeons into it and people are just fine. ND is always a different story ;)

Ok, I got it...

>___________________________________________________________
>___________________________________________________________
>___
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: Peter McCann <[email-masked]>
Date: Thu, 20 Mar 2014 12:54:13 +0000

I think our extensions should be to the prefix information option and not DHCP.

The properties of an address may change after a handover and we should not couple
the DHCP state machine (which is about lease renewal) to the handover state machine.

-Pete

[email-masked] wrote:
>> De : Jouni Korhonen [mailto:[email-masked]] Envoyé : jeudi 20
>> mars 2014 10:00 À : SEITE Pierrick IMT/OLN Cc : Alper Yegin;
>>>>>>>>> want to see this? o ..
>>>>>>>> There's the API aspect on the terminal (one I-D), and there is
>>>>>>>> the MN-network interface ones (e.g., extending RA, DHCP, etc.)
>>>>>>> 
>>>>>>> 
>>>>>>> approach feasible since there are even (partial)
>>>>>>> implementations of the RFC5014 in popular operating systems.
>>>>>>> 
>>>>>> 
>>>>>> Yes, we are talking about extensions to source address selection
>>>>>> (RFC
>>>> 5014).
>>>>> 
>>>>> Ack.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> document, if I understand the above comment correctly? Which
>>>>>>> one(s)
>> to
>>>> do first?
>>>>>>> ND or/and DHCP?
>>>>>>> 
>>>>>> 
>>>>>> Yes. Both.
>>>>> 
>> Why two docs.. DHCP is usually easy going as you can practically
>> shove a flock of pigeons into it and people are just fine. ND is
>> always a different story ;)
> 
> Ok, I got it...
> 
>> 
>> - JOuni
>> 
>> 
>> 
>> 
>>> 
>>>> Alper
>>>> 
>>>> 
>>>>> - Jouni
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Alper
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> - JOuni
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Alper
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> - Jouni
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> charter/blob/master/recharter_ draft.txt
>>>>>>>>>> 
>>>>>>>>>> Basically:
>>>>>>>>>> 
>>>>>>>>>> Added Sri's comment on PMIPv6 maintenance. Added Alper's
>>>>>>>>>> comment of location of mobility functions. Added links to other
>>>>>>>>>> IETF WGs on possible mobility enabling technologies. Added a
>>>>>>>>>> comment that virtualised network functions are in scope.
>>>>>>>>>> 
>>>>>>>>>> - Jouni
>>>>>>>>> 
>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>>> exploites ou copies sans autorisation. Si vous avez recu ce message
>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>>> que les pieces jointes. Les messages electroniques etant susceptibles
>>> d'alteration, Orange decline toute responsabilite si ce message a ete
>>> altere, deforme ou falsifie. Merci.
>>> 
>>> This message and its attachments may contain confidential or
>>> privileged information that may be protected by law; they should not
>>> be distributed, used or copied without authorisation. If you have
>>> received this email in error, please notify the sender and delete this
>>> message and its attachments. As emails may be altered, Orange is not
>>> liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>> 
> 
> 
> ______________________________________________________________________ _
> __________________________________________________
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> exploites ou copies sans autorisation. Si vous avez recu ce message
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> que les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not
> be distributed, used or copied without authorisation.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 20 Mar 2014 22:58:32 +0000

>the DHCP state machine (which is about lease renewal) to the handover

Hi Pete,

This is a good comment. If we are making any assumption that even after a
handover, the DHCP transactions are still hitting the same DHCP server
node, this may be a valid concern. But, if DHCP transactions are locally
terminated after handover (Ex: RFC5844/MAG), then the updated properties
can be provided as part of the new DHCP transaction. Some parameters such
as MTU settings do change after an handover and so we can probably agree
that address properties can change as well.

Regards
Sri

---

From: Peter McCann <[email-masked]>
Date: Fri, 21 Mar 2014 00:37:01 +0000

Hi, Sri,

Sri Gundavelli (sgundave) wrote:
>> The properties of an address may change after a handover and we should
>> not couple the DHCP state machine (which is about lease renewal) to the
>> handover state machine.
> 
> Hi Pete,
> 
> This is a good comment. If we are making any assumption that even
> after a handover, the DHCP transactions are still hitting the same
> DHCP server node, this may be a valid concern. But, if DHCP
> transactions are locally terminated after handover (Ex: RFC5844/MAG),
> then the updated properties can be provided as part of the new DHCP
> transaction. Some parameters such as MTU settings do change after an
> handover and so we can probably agree that address properties can change as well.
> 
> 
> Regards
> Sri

I really don't think we should force DHCP to re-run on every handover.  I thought
one of the motivations for network-based mobility was to minimize the signaling
to the MN during handover.

-Pete

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 21 Mar 2014 06:21:35 +0000

Hi Pete,

> I really don't think we should force DHCP to re-run on every handover.
>I thought one of the motivations for network-based mobility was to
>minimize the signaling to the MN during handover.

In the current mobility models we have two DHCP deployment models.  a.)
DHCP server in the access. b.) DHCP Relay in the access

For #a, it is the dominant model. The DHCP server is collocated on the
access gateway; the interworking between the DHCP server and the mobility
function in the access gateway allows the network to offer the same IP
address to the mobile node. After each handoff and based on DNA
considerations, the MN may go into DHCP INIT-REBOOT followed by
Request/reply. I don't know if I should call this as complete Re-Run after
each handoff, but at least the current data suggests the handoff latency
related to this same-link validation is insignificant. Now, from coloring
perspective, the DHCP server in the access network can potentially change
the properties of the address. MN is on a new world, new access network,
new link and hence some changes to the properties.

For #b, we continue to route the DHCP lease renewal messages back to the
network where the MN obtained its address. Typically its tunneled to the
anchor. Here I see your point of not impacting the DHCP state machine by
changing properties based on MN's movement. But, if the DHCP server is
aware of changes to properties, can it not send the updated properties ?

We have to look at properties as meta-data that goes with an IP
address/prefix. This meta-data should not have any relation to the DHCP
state machine. But, some properties of that address do change, based on
MN's movement, mobility state changes ..etc. If the DHCP server is aware
of these property change, IMO, it should reflect the updated properties.

I'm more interested in #a and not deal with this issue at all. But, if we
insert a property element in PIO, we should do that consistently and have
that in DHCP as well.

Regards
Sri

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 21 Mar 2014 15:54:54 +0800

Ryuji,

> be informational or experimental.  Is this scope of DMM? 

In a case some DMMish feature depends on a work done by other WG
and it is used then in a DMM specific way, that should be documented
in DMM document. This is specifically the case if the feature or
extension done in other WG can be used also for other than DMM
purposes.

> btw, you may add IDR in the listed of working group.

Ok.

- Jouni