Subject: [DMM] draft charter text updates in github..

From: Jouni Korhonen <[email-masked]>
Date: Fri, 06 Jun 2014 14:47:19 +0300

Folks,

Minor changes..

https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt

IMHO..the charter as it is today, would allow pretty much any solution 
from legacy anchoring to herd of pigeons carrying IP.. ;-)

I have put in editorial changes of my own and clear text proposals 
received from others.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Fri, 6 Jun 2014 17:37:55 +0300

Hello Jouni, DMM folks,

We better clarify what "anchor re-selection" stands for.
If it is about selecting different anchors for different IP flows, that's one thing.
If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG.

I won't be in the call today. So, consider this for a discussion. Follow up on the mailing list afterwards would be good.

Cheers,

Alper

On Jun 6, 2014, at 2:47 PM, Jouni Korhonen wrote:

> IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-)
> 
> I have put in editorial changes of my own and clear text proposals received from others.
> 
> - Jouni
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Dapeng Liu <[email-masked]>
Date: Fri, 6 Jun 2014 22:48:38 +0800

在 2014年6月6日 星期五，22:37，Alper Yegin 写道：

> If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out.  
>  
>  

> A basic understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG.
>  
OK.

-Dapeng Liu  
> > [email-masked] (mailto:[email-masked])
> [email-masked] (mailto:[email-masked])

---

From: John Kaippallimalil <[email-masked]>
Date: Fri, 6 Jun 2014 14:56:46 +0000

Hi Alper, All:

Towards the end of the charter, there is a paragraph that states:

     "Although the maintenance of stable home address(es) and/or prefix(es)

      and upper level sessions is a desirable goal when mobile hosts/routers

      change their point of attachment to the Internet, it is not a strict

      requirement. Mobile hosts/routers should not assume that IP

      addressing including home address(es) and/or home network prefix(es)

      remain the same throughout the entire upper level session lifetime,

      or that support for mobility functions is provided on the network side

      in all conditions, unless these properties are specifically indicated

      to the mobile node and its applications from the network."

I suppose this clarifies that the "anchor re-selection" can apply to a single session also?

BR,

John

> -----Original Message-----

> From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin

> Sent: Friday, June 06, 2014 9:38 AM

> To: Jouni Korhonen

> Cc: [email-masked]

> Subject: Re: [DMM] draft charter text updates in github..

> If it is about selecting different anchors for different IP flows, that's one

> thing.

> If it is about changing the IP anchor in the middle of an IP flow, that's

> another thing. And that other thing needs to be scoped out. A basic

> understanding of a use case would be appreciated (just an explanation for

> discussion, I'm not asking for another I-D!), and identification of various

> aspects of that scenario which translate to work items for DMM WG.

> I won't be in the call today. So, consider this for a discussion. Follow up on

> the mailing list afterwards would be good.

> > IMHO..the charter as it is today, would allow pretty much any solution from

> legacy anchoring to herd of pigeons carrying IP.. ;-)

> > I have put in editorial changes of my own and clear text proposals received

> from others.

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Jouni <[email-masked]>
Date: Fri, 6 Jun 2014 18:06:05 +0300

Good point Alper. Lets hash that anchor reselection details out shortly.

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

> Alper Yegin <[email-masked]> kirjoitti 6.6.2014 kello 17.37:
> 
> Hello Jouni, DMM folks,
>

---

From: Jouni <[email-masked]>
Date: Fri, 6 Jun 2014 18:07:14 +0300

John, 

Correct. 

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

> John Kaippallimalil <[email-masked]> kirjoitti 6.6.2014 kello 17.56:
> 
> Hi Alper, All:
>  
> I suppose this clarifies that the “anchor re-selection” can apply to a single session also?
> 
> BR,
> John
>  
>

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 15:09:41 +0000

Hi John, Hi Alper,

Yes, that was the intention of having that text about “anchor re-selection” in the paragraph!
Of course, the  “anchor re-selection”  should apply to an ongoing session!

Best regards,

Georgios

PS. I am afraid that I cannot attend the telco!

________________________________
Van: dmm [[email-masked]] namens John Kaippallimalil [[email-masked]]
Verzonden: vrijdag 6 juni 2014 16:56
Aan: Alper Yegin; Jouni Korhonen
CC: [email-masked]
Onderwerp: Re: [DMM] draft charter text updates in github..

Hi Alper, All:

BR,

John

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 6 Jun 2014 15:12:59 +0000

As posted earlier in an email, I propose to keep the anchor (re)selection decoupled from
mid-session or between-session aspects. I think we should have one solution for
anchor selection, that can be used also to select a new one during runtime if needed.

How to treat bindings in case of mid-session re-selection, is a different thing.
It's about importing mobility states into the new selected anchor. Associated
Traffic steering I see in a separate document, which is currently named 'forwarding
path and signaling management'.

marco

>From: dmm [mailto:[email-masked]] On Behalf Of Jouni
>Sent: Freitag, 6. Juni 2014 17:06
>To: Alper Yegin
>Cc: [email-masked]
>> If it is about changing the IP anchor in the middle of an IP flow, that's another
>thing. And that other thing needs to be scoped out. A basic understanding of a
>use case would be appreciated (just an explanation for discussion, I'm not asking
>for another I-D!), and identification of various aspects of that scenario which
>translate to work items for DMM WG.
>>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 6 Jun 2014 18:52:50 +0300

Hi John,

My reading of that sentence is different.

To me it says "We cannot assume that the solutions we are developing would be available on all networks across the Internet".

While I'd agree with that statement, I don't know what it really means for our solution design.
Some of our solutions may not be present in a network, hence the MN cannot use them. OK…. and??

In my reading, it does not say the following: "Network cannot always provide IP session continuity, hence we need to define solutions that can deal with this". (e.g., using MPTCP, or restarting flows, or some other magic, etc.).
I don't think the intent of that sentence is this. And therefore, I don't think that sentence is related to "anchor re-selection".

Alper

---

From: John Kaippallimalil <[email-masked]>
Date: Fri, 6 Jun 2014 16:21:09 +0000

Hi Alper,
I did not intrepret it that way. The paragraph seemed broad enough to include both (or all) cases.
I found the charter to be broad enough - the current text would support a solution regardless of the specific scenario/design.

But, if it the text is being interpreted in a specific way, I don't have any serious reservations against clarification.

Best Regards,
John

From: Alper Yegin [mailto:[email-masked]]
Sent: Friday, June 06, 2014 10:53 AM
To: John Kaippallimalil
Cc: Jouni Korhonen; [email-masked]
Subject: Re: [DMM] draft charter text updates in github..

Hi John,

While I'd agree with that statement, I don't know what it really means for our solution design.
Some of our solutions may not be present in a network, hence the MN cannot use them. OK.... and??

Alper

Hi Alper, All:

BR,
John

> Cc: [email-masked]<mailto:[email-masked]>

---

From: Alper Yegin <[email-masked]>
Date: Sat, 7 Jun 2014 09:28:50 +0300

Hi John,

In that case we need a clarification and refinement on that text.

Alper

On Jun 6, 2014, at 7:21 PM, John Kaippallimalil wrote:

> I found the charter to be broad enough – the current text would support a solution regardless of the specific scenario/design.
>  
> But, if it the text is being interpreted in a specific way, I don’t have any serious reservations against clarification.    
> 
> Best Regards,
> John
>

---

From: Jouni <[email-masked]>
Date: Sat, 7 Jun 2014 10:37:38 +0300

Ack. John & Alper, any specific wording you want to clarify? 

- Jouni

---

From: Weixinpeng <[email-masked]>
Date: Mon, 9 Jun 2014 02:45:33 +0000

Hi Jouni, all,
"
      .....The protocol solutions
      should be based on existing IP mobility protocols, either host- or
      network-based, such as Mobile IPv6 [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 such
      as routing protocols....."
As my understanding for this text, DMM work group aims to realize mobility management by using/extending the existing host- or network-based protocols
for all the scenarios except for the limited area (relatively small network as my understanding).  Right?
Thanks.
BR
Xinpeng

>From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
>Sent: Friday, June 06, 2014 7:47 PM
>To: [email-masked]
>Subject: [DMM] draft charter text updates in github..
>
>Folks,
>
>Minor changes..
>

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Jun 2014 08:31:19 +0300

Can someone clarify the intent of that text?

Alper

---

From: Jouni <[email-masked]>
Date: Mon, 9 Jun 2014 09:17:51 +0300

> for all the scenarios except for the limited area (relatively small network as my understanding).  Right?

The guidance above is to attempt to build on top of existing IP mobility
protocols. However, if current IP mobility protocols are unfit for the 
desired use case or solution, then within a closed system i.e. not internet
wide, basically anything goes such as routing based solutions or whatever
folks come up with. Here the example was AS wide (which can be quite large
actually). The key point the above tries to address is that whatever you do
in your own administered network is your own business as long as it does not
propagate to Internet.

- Jouni

---

From: Jouni <[email-masked]>
Date: Mon, 9 Jun 2014 09:30:04 +0300

> If it is about selecting different anchors for different IP flows, that's one thing.

This we can do today.. all CMIP, PMIP, GTP allows that assuming
the new flow entails an allocation of a new home address / prefix.
Let's call this case1

> If it is about changing the IP anchor in the middle of an IP flow, that's another thing. And that other thing needs to be scoped out. A basic

This is what we had in mind when writing the "anchor re-selection".
let's call this case2. So, which "other thing" you want to scope out? 
Case 1 or 2?

> understanding of a use case would be appreciated (just an explanation for discussion, I'm not asking for another I-D!), and identification of various aspects of that scenario which translate to work items for DMM WG.

The "PMIP" use case I had in mind is a mechanism to move all or a
subset of mobility sessions from LMA1 to LMA2 for ongoing sessions.
Geo-redundancy or just a better "topological location" could be where
such is needed. Obviously this does not need to be PMIP specific but
when looking from exiting protocols point of view, it kind of was 
obvious choice for an example.

The re-selection involves for example making MAG (or equivalent node)
aware of the move, possibly moving the mobility state/context between
anchors and making sure traffic routing gets correct downstream to
the correct anchor (preferably no tunneling between anchors).

- Jouni

---

From: Jouni <[email-masked]>
Date: Mon, 9 Jun 2014 09:35:54 +0300

> To me it says "We cannot assume that the solutions we are developing would be available on all networks across the Internet".

The highlighted text intend to say:
 unless the mobile node is made explicitly aware (by the network)
 of the fact that the prefix/address it got will guarantee IP session
 continuity, the mobile node cannot assume it to remain unchanged
 infinitely when doing handovers and such.. the prefix/address may
 remain unchanged e.g. within a limited are e.g. as long as the
 mobile node remains within one administrated network domain.

- JOuni

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Jun 2014 15:49:21 +0300

> in your own administered network is your own business as long as it does not

Basically, this says "in limited scale, a non-MIP solution may be used".
The question, for sake of clarification, is:

- Is DMM WG supposed to work on such solutions as well?
- Or, are we just acknowledging the fact that there may be such solutions outside the scope of DMM WG, and our solutions may have to co-exist with them.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 09 Jun 2014 15:56:08 +0300

DMM is supposed to work on those solutions. In a similar manner what is 
done with AAA protocols, DHCP etc.. folks outside the "protocol owning" 
WG do work and at some point of time get reviews etc from there.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Jun 2014 16:21:36 +0300

Jouni,

OK, let's go with the PMIP example….

Let's say there's an ongoing flow, Flow1, via MAG1 and LMA1.

You are talking about switching LMA2 with LMA1, while maintaining MAG1 and not breaking Flow1 (i.e., retaining the same IP address), right?

Assuming LMA1 and LMA2 are not on the same IP subnet, then there'd need to be some routing trick between the LMAs and the Internet, so that IP traffic is steered towards LMA2 instead of LMA1. I presume this trick is outside the scope of DMM. Correct?

And, there needs to be context transfer between LMA1 and LMA2. Is that in scope of DMM?

And there needs to be a tunnel update between MAG1 and LMAs.  That's in scope?

….

If we take a step back and look at this… This probably deserves to be called "LMA-switch", or more generically "IP anchor switch". Not really a mere "anchor re-selection". 

I wonder if this is proposed (perceived) as a "DMM solution", or something that would co-exist with DMM solutions…

Alper

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Jun 2014 16:24:45 +0300

So, Jouni,

Is this saying "Some solutions' applicability may be limited to administrative domains (i.e., not Internet-wide)", and the point is "DMM WG can accept such solutions"?

Whatever the point we are trying to make, we better spell it out.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 09 Jun 2014 16:51:56 +0300

Alper,

Hmm, I already read it in a way myself I said below but that seems to be 
only me. I'll try to reformulate the text..

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 09 Jun 2014 17:19:14 +0300

Alper,

> You are talking about switching LMA2 with LMA1, while maintaining MAG1 and not breaking Flow1 (i.e., retaining the same IP address), right?

Yes. (except that retaining the IP address depends on the use case)

> Assuming LMA1 and LMA2 are not on the same IP subnet, then there'd need to be some routing trick between the LMAs and the Internet, so that IP traffic is steered towards LMA2 instead of LMA1. I pre…

Routing trick is probably needed, yes. If the current toolbox outside 
DMM is not adequeate, DMM could well define, for example, an extension 
to some popular IGP.

> And, there needs to be context transfer between LMA1 and LMA2. Is that in scope of DMM?

Context transfer is probably needed, yes. Whether that is in scope of 
DMM depends.. the context is typically rather system / vendor specific, 
I would lean towards context being outside DMM. If someone insists, 
defininig a set of "mandatory" information elements could do. However, 
the value of such document is debateable.

> And there needs to be a tunnel update between MAG1 and LMAs.  That's in scope?

I would assume, in the example PMIP case, the current stuff there is, is 
not enough. So for IETF defined protocols such as PMIP there would 
potentially be enhancements required (or clarifying the use of existing 
mechanisms in a new use case).

> If we take a step back and look at this… This probably deserves to be called "LMA-switch", or more generically "IP anchor switch". Not really a mere "anchor re-selection".

Fine.

> I wonder if this is proposed (perceived) as a "DMM solution", or something that would co-exist with DMM solutions…

Good question. I rather see it myself as a transition solution to 
something more DMMish, so "co-existing" would suite better. Others may 
have different opinions.

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Mon, 9 Jun 2014 17:41:50 +0300

Hi Jouni,

I can see it now…. 
A solution where IGP and PMIP are used hand-in-hand within a domain…. 
IGP is used between the border gateway and the LMA, PMIP is used between the LMA and MAG.
This solution allows LMA switch. 

I'd say, this is a valid solution that deserves consideration.
But I'd also say that this goes into the same bin as several other solutions.
In other words, it's already captured in the scope w/o any special designation (such as "anchor re-selection").

I recommend we recognize that this is a possible candidate solution, and not refer to "anchor re-selection" in the charter.
If someone wants to keep that term in the charter, then we need to change it to something more representative of the intent, and then discuss why this type of a solution deserves a dedicated deliverable in the charter.

Alper

On Jun 9, 2014, at 5:19 PM, Jouni Korhonen wrote:

> Routing trick is probably needed, yes. If the current toolbox outside DMM is not adequeate, DMM could well define, for example, an extension to some popular IGP.
> 
>> 
> Context transfer is probably needed, yes. Whether that is in scope of DMM depends.. the context is typically rather system / vendor specific, I would lean towards context being outside DMM. If someone insists, defininig a set of "mandatory" information elements could do. However, the value of such document is debateable.
> 
>> 
> I would assume, in the example PMIP case, the current stuff there is, is not enough. So for IETF defined protocols such as PMIP there would potentially be enhancements required (or clarifying the use of existing mechanisms in a new use case).
> 
>> 
>> ….
>> 
>> 
> Good question. I rather see it myself as a transition solution to something more DMMish, so "co-existing" would suite better. Others may have different opinions.
> 
> - Jouni
> 
> 
>> 
>> Alper
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 12:56:38 +0000

I suggest the following for the protocol maintenance part: 

 -------- OLD TEXT ------------
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 6275.

   -------- NEW TEXT -------------

The DMM working group will also work on maintenance-oriented and
      incremental extensions to the IPv6 Mobility protocols, specified
      in RFC 5213, RFC 5844, RFC 3963, RFC 5555 and RFC 6275.

>-----Message d'origine-----
>De : dmm [mailto:[email-masked]] De la part de Jouni Korhonen
>Envoyé : lundi 9 juin 2014 15:52
>À : Alper Yegin
>Cc : [email-masked]
>Objet : Re: [DMM] draft charter text updates in github..
>
>
>Alper,
>
>Hmm, I already read it in a way myself I said below but that seems to be only
>me. I'll try to reformulate the text..
>
>- Jouni
>
>> Is this saying "Some solutions' applicability may be limited to administrative
>domains (i.e., not Internet-wide)", and the point is "DMM WG can accept such
>solutions"?
>>
>>>> To me it says "We cannot assume that the solutions we are developing
>would be available on all networks across the Internet".
>>>
>>> unless the mobile node is made explicitly aware (by the network) of
>>> the fact that the prefix/address it got will guarantee IP session
>>> remain unchanged e.g. within a limited are e.g. as long as the mobile
>>> node remains within one administrated network domain.
>>>
>>> - JOuni
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Some of our solutions may not be present in a network, hence the MN
>cannot use them. OK.. and??
>>>>
>>>> In my reading, it does not say the following: "Network cannot always
>provide IP session continuity, hence we need to define solutions that can deal
>with this". (e.g., using MPTCP, or restarting flows, or some other magic, etc.).
>>>> I don't think the intent of that sentence is this. And therefore, I don't
>think that sentence is related to "anchor re-selection".
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> If it is about changing the IP anchor in the middle of an IP flow,
>>>>>> that's another thing. And that other thing needs to be scoped out.
>>>>>> A basic understanding of a use case would be appreciated (just an
>>>>>> explanation for discussion, I'm not asking for another I-D!), and
>>>>>> identification of various aspects of that scenario which translate to
>work items for DMM WG.
>>>>>>
>>>>>> I won't be in the call today. So, consider this for a discussion.
>>>>>> Follow up on the mailing list afterwards would be good.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>
>>>>>>> https://github.com/jounikor/dmm-re-
>charter/blob/master/recharter_
>>>>>>> draft.txt
>>>>>>>

_________________________________________________________________________________________________________________________

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: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Jun 2014 23:24:58 +0300

Right, RFC5555 should be there.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 11 Jun 2014 13:45:52 +0300

Alper,

> If someone wants to keep that term in the charter, then we need to change it to something more representative of the intent, and then discuss why this type of a solution deserves a dedicated delive…

Right. I am not persistent with the "re-selection" naming or it being 
explicitly mentioned in the charter body text. I am fine acknowledging 
that any work around mobility anchors in "legacy" sense falls under the 
maintenance part of the charter:

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

Given the above use case we should have a milestone for this though.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 11 Jun 2014 14:36:58 +0300

A heavily updated charter text in the github. I am not sure it addresses 
all wording concerns folks had. But.. flame on ;)

Reading the telco notes I realize I do not have nor have seen the slides 
shown during the call, so probably the "re-anchoring" sanitization in 
the charter text went too far compared what was discussed in the call. 
Please check.

If you have concerns on the milestones and specifically their timeline, 
express your opinion with a new month+year combination.

The cooperation with other WGs is heavily reworded. Basically it says 
now that DMM can mock other protocols but those then need review & 
ratification from the protocol "owning" WG, just like commonly done with 
DHCP & RADIUS.

Routing based solutions are now explicitly stated to be restricted to 
IGP routing domain and must not propagate routing updates outside the 
IGP routing domain.

Regarding the "enhanced mobility anchoring" milestone that could also be 
put under maintenance:

   Work items related to the PMIPv6 maintenance include:

    o Enhanced mobility anchoring: define protocol solutions for a
      gateway and mobility anchor assignment and mid-session mobility
      anchor switching that go beyond what has been, for example,
      described in RFC 6097, 6463, and 5142. The solution should also
      define a mechanism for preserving ongoing mobility sessions in a
      single administrative or IGP routing domain, which would involve
      directing traffic towards the new anchor.

Opinions?

- Jouni

---

From: Alper Yegin <[email-masked]>
Date: Wed, 11 Jun 2014 15:10:00 +0300

Hi Jouni,

Thank you for the revision.

Here are my comments:

      When extending non- IP mobility protocols, solutions should be
      reviewed and ratified by the WGs having the "ownership" of those
      protocols.

I think you mean "protocols that are not based on Mobile IP" instead of "non-IP mobility protocols".

      Although Internet-wide maintenance of the stable home address(es) or prefix(es)
      is a desirable goal when mobile hosts/routers change their point of
      attachment to the network, it is not a strict requirement on the DMM solutions. Mobile
      hosts/routers should not assume that the home address(es) and/or
      home network prefix(es) remain the same throughout the entire
      application level session lifetime, unless such property is indicated
      to the mobile node/router and its applications from the network.

Inserted the red text above.

      If the network or the mobile host/router do not
      support the distributed mobility management enabling protocol that
      should not prevent the mobile host/router gaining basic (i.e., nomadic) access to the
      network.

Red text again…

      o Enhanced mobility anchoring: define protocol solutions for a gateway and
        mobility anchor assignment and mid-session mobility anchor switching
        that go beyond what has been, for example, described in RFC 6097, 6463,
        and 5142. The solution should also define a mechanism for preserving
        ongoing mobility sessions in a single administrative or IGP routing
        domain, which would involve directing traffic towards the new anchor.
        
      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.

These above two seem inseparable. 
I recommend we list them as one item.
(The separation was between "anchor selection" and "data-path management signaling" before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items. In this latest text, the separation got blurred. The title of the first item, along with references to "switching", "preserving sessions", "directing traffic" all point to the context of the second one…)
We can note that separate anchor discovery & selection drafts may be produced (opening the door for split documents, while not forcing people to split any solution into two parts because the charter said so..)

Alper

On Jun 11, 2014, at 2:36 PM, Jouni Korhonen wrote:

> 
> A heavily updated charter text in the github. I am not sure it addresses all wording concerns folks had. But.. flame on ;)
> 
> Reading the telco notes I realize I do not have nor have seen the slides shown during the call, so probably the "re-anchoring" sanitization in the charter text went too far compared what was discussed in the call. Please check.
> 
> If you have concerns on the milestones and specifically their timeline, express your opinion with a new month+year combination.
> 
> The cooperation with other WGs is heavily reworded. Basically it says now that DMM can mock other protocols but those then need review & ratification from the protocol "owning" WG, just like commonly done with DHCP & RADIUS.
> 
> Routing based solutions are now explicitly stated to be restricted to IGP routing domain and must not propagate routing updates outside the IGP routing domain.
> 
> Regarding the "enhanced mobility anchoring" milestone that could also be put under maintenance:
>

---

From: Jouni <[email-masked]>
Date: Wed, 11 Jun 2014 18:50:03 +0300

Alper,

> I think you mean "protocols that are not based on Mobile IP" instead of "non-IP mobility protocols".

Ok.

> Inserted the red text above.

Ok.

>       should not prevent the mobile host/router gaining basic (i.e., nomadic) access to the

Ok again.

> I recommend we list them as one item.

Hrmph.. not sure I agree.

> (The separation was between "anchor selection" and "data-path management signaling" before. At that time, it was a clearer separation. But even at that time I was suggesting combining the two items…

I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could remove the last sentence of the anchoring milestone..

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jun 2014 16:13:36 +0000

Hi Jouni,

>      The DMM solutions primarily target at IPv6 deployments and should not
>      be tailored specifically to support IPv4, in particular in situations
>      where private IPv4 addresses and/or NATs are used. At least IPv6 is
>      assumed to be present in both the mobile host/router and the access
>      networks.

I would like that solutions that work when IPv6 is not present in the
access networks are also in-scope for the charter. Consider deployment
of IPv6 in mobile hosts/routers within an autonomous system that may
be many years away from providing IPv6 to the access networks. If the
solution works equally well when the access network is IPv4-only vs
IPv6-enabled, then shouldn't it also be in-scope for the charter?

Thanks - Fred
[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Wed, 11 Jun 2014 22:54:08 +0300

Hi Jouni,

> I see your point/concern. Since I (personally) see the enhanced mobility anchoring more towards maintenance work, I am tempted to have these two different milestones from the beginning. We could re…

So, what's called "enhanced mobility anchoring" refers to 'maintenance work', and
"Forwarding path and signaling management" refers to 'new DMM solution'?

I didn't get that from the text…
In my understanding, what we have been calling "maintenance" is simply PMIP/CMIP improvements/fixes in broad context -- not related to a DMM solution.

On the other hand, that first bullet above does read like a DMM solution to me.

I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet…

Alper

---

From: Jouni <[email-masked]>
Date: Thu, 12 Jun 2014 00:14:35 +0300

Alper,

> So, what's called "enhanced mobility anchoring" refers to 'maintenance work', and

It could, since we specifically point three PMIP RFCs on a related topic: daa daa on anchor selection, solution for redirect during session establishment and solution for anchor switch that does not address what happens to ongoing sessions. When you do better than those, you are approaching a solution that allows one to better distribute anchors. Still very PMIPish, though.

> "Forwarding path and signaling management" refers to 'new DMM solution'?

Yes.. we specifically do not refer how and based on what to achieve that.

> I didn't get that from the text…

So is the "Forwarding path and signaling management" intent unclear in DMM scope?

> I'm confused… what is maintenance, what is the objective of first bullet, what is the objective of second bullet…

First bullet intent should be clear, continue PMIP where it left on this anchor part. Second bullet gives you much more freedom. That is how I divided it in my organic compute unit.

- Jouni

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 11 Jun 2014 14:24:38 -0700

Hello folks,

I reviewed the charter, and found numerous little stylistic
improvements.  Most of my revisions were along the lines of
rewording the same thought to eliminate ambiguity or make
grammatical corrections.  I've attached a diff file to show all
of the suggested revisions.  I hope this is a reasonable format
my suggestions.  Even though such things are minor, getting
them right is very helpful for accurately expressing the ideas.

Here are some most substantial comments, which are also
embedded in my revised file:
/* What about RFC 5568 (FMIP)? */

"Routing based proposals must not propagate routing
          updates outside the IGP routing domain."
/* Does this disallow Binding Update? */

/* What does "eventually" mean?? */

Also, the suggested dates for chartered work items seem
quite unrealistic to me.

I noticed that part of the charter fit nicely in my 80-column
(vi) text window, and part of the charter does not fit nicely.
I could also fix that if desired.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 12 Jun 2014 09:09:51 +0300

Jouni,

Based on earlier discussions, and what you wrote below, there are 3 distinct things:

1. *MIP maintenance.

Any bug fix or improvement not driven by DMM, but for the sake of maintaining the *MIP baseline protocols, are handled here.

2. MIP-based DMM solutions.

3. Non-MIP-based DMM solutions.

I presume these 3 items map to the those two bullets in the charter. Right?
I cannot clearly tell the mapping though.

Alper

---

From: Jouni <[email-masked]>
Date: Thu, 12 Jun 2014 10:25:07 +0300

Alper,

The latter bullet (forwarding path etc) is imho clearly in your 3. choice below. It can also be 2. since it is not yet stated what is the baseline protocol. The protocol solution will then determine that. The former bullet (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be also partly in 3. if non-PMIP stuff is needed for the overall solution. Anyway, the baseline protocol is known - PMIP, and the solution aims to "distribution" within PMIP's boundaries. 

What is unclear here?

Jouni

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

> Alper Yegin <[email-masked]> kirjoitti 12.6.2014 kello 9.09:
> 
> Jouni,
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 12 Jun 2014 10:55:12 +0300

Jouni,

I think I can understand and follow now, after your explanation.
I cannot say the same when reading the charter text.
I'll let others speak up. If I'm the only one having difficulty parsing that part of the charter, then so be it.

Btw, I'm not aware of any decision that the baseline protocol will be PMIP. CMIP is equally on the table.

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 12 Jun 2014 11:39:13 +0300

Alper,

> I cannot say the same when reading the charter text.

Right. Then we just need to tweak the text, since if you have issues to 
parse it the IESG will have double that.

> Btw, I'm not aware of any decision that the baseline protocol will be PMIP. CMIP is equally on the table.

Sure. For the anchoring stuff that was kind of assumed to be PMIP though.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 Jun 2014 14:42:36 -0500

I don't understand why anchoring, re-anchoring are still in the charter.
There is no need for these terms.
We need to use general approaches in the charter such as routing,
network-based, client-based.

We also need to acknowledge the fact that almost all carriers will
have cloud networks by the time dmm picks up, if any. So the charter
should be open to the terms like virtualization, cloud, type of
futuristic terminology rather than the sticky anchor terminology.

Regards,

Behcet

On Thu, Jun 12, 2014 at 3:39 AM, Jouni Korhonen <[email-masked]> wrote:
>>> The latter bullet (forwarding path etc) is imho clearly in your 3. choice
>>> below. It can also be 2. since it is not yet stated what is the baseline
>>> protocol. The protocol solution will then determine that. The former bullet
>>> (enhanced anchoring etc) is imho clearly your 2. more than 1. It could be
>>> also partly in 3. if non-PMIP stuff is needed for the overall solution.
>>> Anyway, the baseline protocol is known - PMIP, and the solution aims to
>>> "distribution" within PMIP's boundaries.
>>>
>>> What is unclear here?
>>>
>>> Jouni
>>>
>>>
>>> --
>>> Jouni Korhonen
>>> Broadcom
>>>
>>> (Sent from my mobile..)
>>>
>>>> Any bug fix or improvement not driven by DMM, but for the sake of
>>>> maintaining the *MIP baseline protocols, are handled here.
>>>>
>>>>>>>> gateway and
>>>>>>>> (The separation was between "anchor selection" and "data-path
>>>>>>>> management signaling" before. At that time, it was a clearer separation. But
>>>>>>>> even at that time I was suggesting combining the two items. In this latest
>>>>>>>> text, the separation got blurred. The title of the first item, along with
>>>>>>>> references to "switching", "preserving sessions", "directing traffic" all
>>>>>>>> point to the context of the second one…)
>>>>>>>
>>>>>>>
>>>>>>> I see your point/concern. Since I (personally) see the enhanced
>>>>>>> mobility anchoring more towards maintenance work, I am tempted to have these
>>>>>>> two different milestones from the beginning. We could remove the last
>>>>>>> sentence of the anchoring milestone..
>>>>>>
>>>>>>
>>>>> It could, since we specifically point three PMIP RFCs on a related
>>>>> topic: daa daa on anchor selection, solution for redirect during session
>>>>> establishment and solution for anchor switch that does not address what
>>>>> happens to ongoing sessions. When you do better than those, you are
>>>>> approaching a solution that allows one to better distribute anchors. Still
>>>>> very PMIPish, though.
>>>>>
>>>>>> In my understanding, what we have been calling "maintenance" is simply
>>>>>> PMIP/CMIP improvements/fixes in broad context -- not related to a DMM
>>>>>> solution.
>>>>>>
>>>>>> I'm confused… what is maintenance, what is the objective of first
>>>>>> bullet, what is the objective of second bullet…
>>>>>
>>>>>
>>>>> First bullet intent should be clear, continue PMIP where it left on
>>>>> this anchor part. Second bullet gives you much more freedom. That is how I
>>>>> divided it in my organic compute unit.
>>>>>
>>>>> - Jouni
>>>>>
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> - Jouni
>>>>>>>
>>>>>>>
>>>>>>>> We can note that separate anchor discovery & selection drafts may be
>>>>>>>> produced (opening the door for split documents, while not forcing people to
>>>>>>>> split any solution into two parts because the charter said so..)
>>>>>>>>
>>>>>>>>
>>>>>>>> Alper
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> A heavily updated charter text in the github. I am not sure it
>>>>>>>>> addresses all wording concerns folks had. But.. flame on ;)
>>>>>>>>>
>>>>>>>>> Reading the telco notes I realize I do not have nor have seen the
>>>>>>>>> slides shown during the call, so probably the "re-anchoring" sanitization in
>>>>>>>>> If you have concerns on the milestones and specifically their
>>>>>>>>> timeline, express your opinion with a new month+year combination.
>>>>>>>>>
>>>>>>>>> The cooperation with other WGs is heavily reworded. Basically it
>>>>>>>>> says now that DMM can mock other protocols but those then need review &
>>>>>>>>> Routing based solutions are now explicitly stated to be restricted
>>>>>>>>> to IGP routing domain and must not propagate routing updates outside the IGP
>>>>>>>>> routing domain.
>>>>>>>>>
>>>>>>>>>> that's another thing. And that other thing needs to be scoped out. A basic
>>>>>>>>>>> IMHO..the charter as it is today, would allow pretty much any
>>>>>>>>>>> solution from legacy anchoring to herd of pigeons carrying IP.. ;-)
>>>>>>>>>>>

---

From: Alper Yegin <[email-masked]>
Date: Fri, 13 Jun 2014 08:58:31 +0300

> Sure. For the anchoring stuff that was kind of assumed to be PMIP though.

Possibly in some individual's minds. 

(Btw, it's likely that this WG would come up with multiple solutions. Yes, it's not desirable, but one-size-fits-all may not be achievable. Well, discussions will show…)

Alper

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 13 Jun 2014 13:41:20 +0300

Charlie,

Thanks Charlie for all the editorials. I have incoporated most. 
Additional comments inline.

> /* What about RFC 5568 (FMIP)? */

There is the "..such as.." so I think there is no really need to lost 
all possible MIP6 variations.

> /* Does this disallow Binding Update? */

Should not.. if you refer to MIP style tunnel management binding updates.

> /* What does "eventually" mean?? */

erm.. removed..

> Also, the suggested dates for chartered work items seem

;-) +3 months?

> I could also fix that if desired.

Fixed.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 13 Jun 2014 14:41:39 +0300

Folks,

New update (v9) available. I added most of the editorials from Charlie 
(thanks) and the red texts from Alper.

The lot debated anchoring term (and milestone) is still there. The 
milestone does not mention anymore about preserving the mobility 
sessions and stuff. That would be up to the solution to define.

- Jouni

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 13 Jun 2014 16:37:54 -0700

Hello Jouni,

Thanks for incorporating some of my suggested revisions.

Follow-up below...

> all possible MIP6 variations.

FMIP is particularly important when developing solutions
that are aimed at localizing handover signaling, and I think
it deserves particular mention, at the cost of adding ten or
fifteen more characters to the charter text.

>> /* What does "eventually" mean?? */

Well, it's still there.  So, maybe, the other dozen or so
revisions that didn't make it into charter revision #9 were
intended to be included also...?  I'll await further follow-up
until I can see whether my other comments were rejected
or simply overlooked.  Please take a look.

In particular, misuse of the definite article "the" can be
interpreted to restrict development to a single solution.
And, as has been discussed, I think that the dmm WG is
very likely to develop a suite of smoothly interacting
solutions.  Moreover, it should be observed that on a
single mobile node, different applications might require
different treatment for their end-point IP address.  This
might also encourage further use of multiple IPv6 addresses
by a single mobile node, which in my opinion is a positive
feature.  Or it could elevate the importance of proper
treatment for flow mobility.

Is it just me, or do other people prefer "RFC 6275" to
"RFC6275"?

>> Also, the suggested dates for chartered work items seem

That would at least enable some believability.

>> I could also fix that if desired.

Thanks!

For convenience, I attached the rfcdiff output from my previous
text of the charter compared to today's version #9.  If doing so is
not helpful, please let me know.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 13 Jun 2014 16:47:27 -0700

Oops, that was the wrong attachment!!

Please excuse my error.  The proper file is attached to this message.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Jouni <[email-masked]>
Date: Sat, 14 Jun 2014 02:53:34 +0300

On Jun 14, 2014, at 2:37 AM, Charles E. Perkins wrote:

>> There is the "..such as.." so I think there is no really need to lost all possible MIP6 variations.
> 

Okay.

> Well, it's still there.  So, maybe, the other dozen or so

D'oh.

> or simply overlooked.  Please take a look.

Hmm.. seems i did not include the comments
in the milestones part.. my mistake.

> Is it just me, or do other people prefer "RFC 6275" to

Spaces are cheap.. will add those.

- Jouni

> <Diff  dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 14 Jun 2014 13:34:19 +0900

Hi Jouni and all,

Thanks for updating the charter, which is much tidy now.

Sorry for my late response, but I have a couple of comments below:

o With regard to enhanced mobility anchoring (mid-session anchor
switching), there were a lot of discussions in the past as you know and
eventually that idea was not fully accepted by the community. It's ok to
handle it in DMM WG, but we also need convincing use cases and
effectiveness. Re-anchoring LMAs/HAs with preserving IP address may not
be so elegant and efficient.

o I was not very sure why virtualization needs to be mentioned. There
might have been some discussion about it, but do we really need it in
the charter?

The DMM solutions should not distinguish between physical or
virtualised networking functions. However, whenever applicable,
clarifications for specific networking function deployment models
are in scope and encouraged. o The fourth paragraph mentions UP/CP
separation, but the last sentence is about IP address change, which is
described in the fifth paragraph. That sentence may be fit there.

In contrast to existing IETF standard IP mobility protocols,
mobility management signalling paths and end user traffic
forwarding paths may differ; those mobility related functions may
be located in separate network nodes. "Solutions may also specify
the selection between the care-of addresses and home
address(es)/prefix(es) for different application use cases".

Regards,

-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[email-masked]

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sat, 14 Jun 2014 13:47:45 +0900

Hi Jouni and all,

With regard to the milestone, it looks getting more aggressive. If we
think of the current pace of creating the problem statement and
requirements documents, submitting the I-Ds to IESG by next March
doesn't seem to be very realistic...

Just a few other comments below:

>> fifteen more characters to the charter text.
Then Why not RFC5949 for PMIP? ;-)
> Spaces are cheap.. will add those.

Many RFCs don't have a space between them, but it should be ok.

Regards,
--
Hidetoshi

---

From: <[email-masked]>
Date: Sat, 14 Jun 2014 05:59:21 +0000

Hi Jouni, Hi all,

Sorry for not being able to attend the telco.

I have checked the updated charter. It looks good, but I have some comments:

Comment_1: 
Not sure which of the mentioned milestones incorporate traffic steering after re-anchoring.
Is it the milestone "Forwarding path and signalling management" or is it the milestone "Enhanced mobility anchoring"?

A sentence similar to below, could be included in one of these two work items to emphasize this:
"The steering of the traffic associated with the "mid-session mobility anchor switching" is also in the scope of this work item."

Comment_2: virtualization should be, IMHO, better emphasized in the charter.
For example, could we change the following paragraph from:

"The DMM solutions should not distinguish between physical or virtualised networking functions. 
However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged."

INTO:

"The DMM solutions should not distinguish between physical or virtualised networking functions. 
However, whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, 
e.g., in virtualized environments, are in scope and encouraged. "

Comment_3: The milestones are too ambitious. 
Please extend each of them with at least 3 months.

Best regards,
Georgios

________________________________________
Van: dmm [[email-masked]] namens Jouni Korhonen [[email-masked]]
Verzonden: vrijdag 13 juni 2014 13:41
Aan: [email-masked]
Onderwerp: Re: [DMM] draft charter text updates in github..

Folks,

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 14 Jun 2014 13:25:10 +0300

Fixed.

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 14 Jun 2014 13:54:24 +0300

Hi,

> Is it the milestone "Forwarding path and signalling management" or is it the milestone "Enhanced mobility anchoring"?

The latter. It was also stipulated that in a good case "Forwarding path 
and signalling management" could also be used for traffic steering for 
anchor switch.. or then both could be entirely separate solutions.

> "The steering of the traffic associated with the "mid-session mobility anchor switching" is also in the scope of this work item."

Ok.. works for me.

> For example, could we change the following paragraph from:

And we have an other mail saying it does not need to be mentioned ;)

> e.g., in virtualized environments, are in scope and encouraged. "

OK with that.

> Please extend each of them with at least 3 months.

Ack.

Thanks,
	Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 14 Jun 2014 14:01:13 +0300

Hi,

> be so elegant and efficient.

Right. The charter does not enforce preserving the IP during the switch, 
actually. It would be a desirable feature tough.

>        are in scope and encouraged.

I still keep it for the time being. Several folk seem to think it needs 
to be mentioned..

> o The fourth paragraph mentions
> UP/CP separation, but the last sentence is about IP address change,
> which is described in the fifth paragraph. That sentence may be fit there.
>

Ack. Done.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 14 Jun 2014 14:20:18 +0300

Folks,

Another set of tweaks in github (v12):
  o reminders of Charlie's comments
  o Hidetoshi's comments
  o Georgios' comments

Also milestones got postponed. There is still a bit of my own editing in 
the text so not everything got moved over letter by letter.

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Jun 2014 14:59:07 +0000

Hi Jouni,

What about operation in IPv4-only access networks? There may be
many enterprise networks that offer IPv4-only in their access
networks for the near future, but with IPv6 enabled internally.
For them, we should be able to tunnel IPv6 inside IPv4 if the
mechanism can support it.

Here is my suggested re-word:

OLD:
DMM solutions are primarily targeted at IPv6 deployments and
should not be required to support IPv4, specifically in situations
where private IPv4 addresses and/or NATs are used. IPv6 is
assumed to be present in both the mobile host/router and the
access networks.

NEW:
DMM solutions are primarily targeted at IPv6 mobile hosts/routers
and should not be required to support IPv4-only mobiles. Access
networks may be IPv6-enabled or IPv4-only, but with IPv6 enabled
in the network core.

Thanks - Fred

> Sent: Saturday, June 14, 2014 4:20 AM
> To: [email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 16 Jun 2014 19:41:10 +0300

Fred,

> mechanism can support it.

My personal view is still that IPv4-only access is even more past than 
"anchoring" ;-)

Anyway, if there is (rough) consensus in the WG for the below new text, 
so be it.

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Jun 2014 16:53:22 +0000

Hi Jouni,

> From: Jouni Korhonen [mailto:[email-masked]]
> Sent: Monday, June 16, 2014 9:41 AM
> To: Templin, Fred L; [email-masked]

OK, but I am just telling what I see and it is that IPv4-only
access in enterprise networks is still a reality today.

Thanks - Fred

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 18 Jun 2014 12:59:39 +0300

Fred,

It is true IPv4 is there (and will be for a long time). Although the 
charter does emphasize IPv6 as the base solution it does not prohibit 
adding IPv4 support. It is just we can accept an IPv6-only solution as a 
valid & complete solution from DMM point of view.

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jun 2014 15:25:10 +0000

Hi Jouni,

> Sent: Wednesday, June 18, 2014 3:00 AM

However, a solution that works equally well whether the access networks
are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms
of near-term deployment in real networks. Therefore, I think the charter
is currently saying _too much_. My new proposal is simply to strike the
following two sentences:

  "DMM solutions are primarily targeted at IPv6 deployments and
   should not be required to support IPv4, specifically in situations
   where private IPv4 addresses and/or NATs are used.  IPv6 is
   assumed to be present in both the mobile host/router and the
   access networks."

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Wed, 18 Jun 2014 11:43:07 -0400

Hi Fred,

>    assumed to be present in both the mobile host/router and the

The above has been a part of the DMM charter for a long time.  Taking it
out would appear to be opening the door for IPv4-only solutions.  My
assessment of the winds within the community is that people are not
interested in new protocols for IPv4.

Just my opinion...

Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jun 2014 16:07:51 +0000

Hi Brian,

> From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Wednesday, June 18, 2014 8:43 AM
> To: [email-masked]
> out would appear to be opening the door for IPv4-only solutions.

IPv4-only solutions is not my intended meaning. I agree that the
mobile hosts/routers should only support IPv6 applications (and
not IPv4 apps) but that support can be enabled over either IPv6
or IPv4 access networks through tunneling. 

> My

No, this is not a new protocol for IPv4. It is IPv6 Neighbor
Discovery over tunnels over either IPv6 or IPv4 access networks.

Thanks - Fred

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 19 Jun 2014 18:31:54 +0900

Hi Jouni,

Thanks for updating the charter, which is now v12! I'm fine with this
version (at least my comments were resolved).

Regards,

-- 
Hidetoshi Yokota

(2014/06/14 20:20), Jouni Korhonen wrote:
> Also milestones got postponed. There is still a bit of my own editing
> in the text so not everything got moved over letter by letter.
>
> - Jouni
>
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 18:20:20 +0000

Agree. We should ensure the base solution supports IPv6 transport and user
sessions. Optionally, support for IPv4 can be allowed on certain
interfaces, but clearly should not deal with IPv4, NAT's or allow
IPv4-only solutions.

Regards
Sri

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 18:30:09 +0000

Hi Sri,

> From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
> Sent: Thursday, June 19, 2014 11:20 AM
> To: Brian Haberman; [email-masked]

I don't understand that. In my enterprise, I have IPv4-only wireless
access points yet there are IPv6 services within the enterprise. When
I switch over to 4G wireless, I again get IPv4-only access but again
there are IPv6 services within the enterprise.

If the mobility management mechanism supports IPv6 over IPv4 tunneling
(possibly including NATs in the path), then the use case is satisfied;
otherwise, the use case is not satisfied.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 19:20:20 +0000

Sri,

Let me be perfectly clear - AERO works equally well whether the access
network is IPv4-only, IPv6-only, or dual-stacked. That is an advantage,
and addresses real-world use cases. Hence, I do not think it should be
discouraged by the charter.

Thanks - Fred

> From: dmm [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Thursday, June 19, 2014 11:30 AM
> To: Sri Gundavelli (sgundave); Brian Haberman; [email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 19:32:39 +0000

Hi Fred,

The DMM WG is still discussing PS and the related issues. By the time we
adopt a solution and complete the work, we will surely be in 2016. So, is
it not safer to raise the bar and limit certain interfaces to IPv6-only ?
I'm not arguing against adding any support for IPv4, but IMO the bar
should be high. We can certainly support all possible types of networks,
IPv4-only transport, IPv4-only user plane, and IPv4-only services. But,
looking at our current pace and doing some extrapolation, its safe to say
we will bake this for a long time and so limiting the work scope IMO
helps. But, this is just my opinion/comment and personally don't care if
some one wants to do the work and the chairs/AD/WG agree with it. Also, I
do not know yet how much of the solution work will really be IP-version
dependent. Mostly some network interfaces and there IPv6 possibly is a
safe assumption. 

Regards
Sri

On 6/19/14 11:30 AM, "Templin, Fred L" <[email-masked]> wrote:

>> >>> adding IPv4 support. It is just we can accept an IPv6-only solution
>>as
>> >>>a

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 19:54:25 +0000

Hi Sri,

I will just repeat that AERO works equally well on IPv4-only, IPv6-only
and dual-stacked access networks. This means that it can address real
world use cases today that cannot be addressed by other mechanisms.

As to schedule, who can truly say when IPv4 will be totally gone from
all access networks? 2016 is just a date on a calendar; we have been
waiting for IPv6 to fully replace IPv4 since about 1994, and AFAICT
it still hasn't happened.

Thanks - Fred

> From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
> Sent: Thursday, June 19, 2014 12:33 PM
> To: Templin, Fred L; Brian Haberman; [email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 20:31:37 +0000

Hi Fred,

Ack on the AERO capability.

I have come to the conclusion that I have to deal with IPv4 for the rest
of my career (assuming some left). Surely, some day in 2016 is not some
thing that I'm looking at. My point is to limit the solution scope and if
it happens that DMM solution is immensely successful, we can introduce
IPv4 interfaces in phases.

Regards
Sri

On 6/19/14 12:54 PM, "Templin, Fred L" <[email-masked]> wrote:

>> >> >> is currently saying _too much_. My new proposal is simply to
>>strike
>> >>the
>> >> >> following two sentences:
>> >> >>
>> >> >The above has been a part of the DMM charter for a long time.
>>Taking
>> >>it

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 20:34:53 +0000

Hi Sri,

> Sent: Thursday, June 19, 2014 1:32 PM

OK.

> IPv4 interfaces in phases.

Or, have IPv4 built-in from the onset for free; wouldn't that
be better?

Thanks - Fred

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 20:39:48 +0000

Hi Fred,

> Or, have IPv4 built-in from the onset for free; wouldn't that be better?

Cannot say without understanding the solution approach and the needed
effort. But, I guess with AERO, you have some effort in mind.

Any case, its WG/Chairs/AD call, but works for me.

Regards
Sri

On 6/19/14 1:34 PM, "Templin, Fred L" <[email-masked]> wrote:

>> >> adopt a solution and complete the work, we will surely be in 2016.
>>So,
>> >>is
>> >> it not safer to raise the bar and limit certain interfaces to
>>IPv6-only
>> >>?
>> >> some one wants to do the work and the chairs/AD/WG agree with it.
>>Also,
>> >>I
>> >> >> From: dmm [mailto:[email-masked]] On Behalf Of Sri
>>Gundavelli
>> >> >>(sgundave)
>> >> >> Agree. We should ensure the base solution supports IPv6 transport
>>and
>> >> >>user
>> >> >> >>> It is true IPv4 is there (and will be for a long time).
>>Although
>> >>the
>> >> >> >> of near-term deployment in real networks. Therefore, I think
>>the
>> >> >>charter

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 20:53:57 +0000

Hi Sri,

> Sent: Thursday, June 19, 2014 1:40 PM

I have code that, while not pretty, is astonishingly simple.
I should be able to release that very soon.

Thanks - Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Jun 2014 16:07:53 -0500

Isn't AERO becoming an RFC already?

Regards,

Behcet

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 21:20:31 +0000

Hi Behcet,

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Thursday, June 19, 2014 2:08 PM
> To: Templin, Fred L
> Cc: Sri Gundavelli (sgundave); Brian Haberman; [email-masked]

We already have RFC6706 as an experimental RFC, but I am working
on a (bis) that will obsolete that:

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

The (bis) does not currently have a wg home, so I thought I would
check to see if dmm would be a good home for it.

Thanks - Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Jun 2014 17:56:36 -0500

I thought you said in your presentation that this draft is being
AD-sponsored or going thru ISE?

Regards,

Behcet

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jun 2014 23:13:24 +0000

Hi Behcet,

> Sent: Thursday, June 19, 2014 3:57 PM
> To: Templin, Fred L

I think maybe you are talking about RFC6706, which was AD sponsored.
The (bis) has not been picked up by an AD sponsor nor a working group
yet, and is IMHO too far along in its evolution to fall back and take
it down the ISE path now. So, wg item would seem like a suitable path.

Thanks - Fred

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Jun 2014 10:31:09 -0500

Hi Fred,

Thanks for clarifying.

We can maybe add your solution to the bunch classified as Mobile IP
based approach, even though it does not require client software in the
MN.
We have a PMIP based solution and a routing based solution.
All of these I think, form a good basis to work on in dmm.

My 2 cents.

Regards,

Behcet

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jun 2014 15:46:21 +0000

Hi Behcet,

> Sent: Friday, June 20, 2014 8:31 AM
> To: Templin, Fred L

To clarify, AERO does require the MN to run a lightweight app.
The app is very similar in principle to OpenVPN, which may in
the long run be a suitable integration platform for the AERO
Client function.

Thanks - Fred