Subject: [multimob] Multimob charter v2

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 May 2009 08:46:09 -0700 (PDT)

Hi all,
  I updated the charter based on the discussions.

Regards,

Behcet

---

From: <[email-masked]>
Date: Tue, 19 May 2009 18:15:57 +0200

Dear Behcet, all,
Thanks for your effort towards progress of the charter. I agree mainly with the latest version. Just for reasons of logic and readability I would however prefer the proposal by Thomas - i.e. after stating the problems with unicast mobility protocols (...loss of data during handovers.) not to continue with the somewhat disruptive sentence 'The WG will address these issues within the context of Proxy Mobile IPv6 (PMIPv6).' but rather with
'Current mobility extension protocols like PMIPv6, FMIPv6, HMIPv6 ... do 
(also) not support multicasting explicitely. In particular, the current PMIPv6 
specification does not allow for unencapsulated, continued multicast 
reception at the mobility-agnostic mobile node.'

And BTW we should include the new AD Ralph Droms <[email-masked]> :-)

Best regards

Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Dienstag, 19. Mai 2009 17:46
An: [email-masked]
Betreff: [multimob] Multimob charter v2

Hi all,

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 May 2009 11:52:23 -0700 (PDT)

Hi Dirk,
  Pls see my replies below.

Regards,

Behcet

----- Original Message ----
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Tuesday, May 19, 2009 11:15:57 AM
Subject: Re: [multimob] Multimob charter v2

Dear Behcet, all,

[behcet] It sounds disruptive but it expresses better what we have in the charter, esp. the work items. Also this sentence connects better with the next paragraph.

[behcet] I think this sentence provide too much detail we possibly don't need in a charter.

Best regards

Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Dienstag, 19. Mai 2009 17:46
An: [email-masked]
Betreff: [multimob] Multimob charter v2

Hi all,

Regards,

Behcet

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

---

From: Liu Hui <[email-masked]>
Date: Wed, 20 May 2009 09:54:33 +0800

Behcet,

I have some questions in the charter v2:

1 " Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and also Mobile IPv4)..."

Why in the beginning of this paragraph MIPv6, Dual-Stack Mobile IPv6 and  MIPv4 is mentioned, while in the end they should be considered "within the context of Proxy Mobile IPv6 (PMIPv6)" ?

2 "Currently PMIPv6 (and mobility extension protocols like  FMIPv6 and HMIPv6)" : 

Why FMIP and HMIP are mentioned combined with PMIP, what's the relationship between PMIP and FMIP and HMIP ?

I feel it's not so clear to illustrate so many mip protocols and make this classification

Because the wg hasn't yet seen clearly many works for other unicast MIP protocols except for PMIP.   These protocols should be mentioned with some examples instead being listed "exhaustively". Otherwise the charter may look too inclusive or miscellaneous to be accepted.

Best Regards,

Liu Hui

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
> Sent: 2009年5月19日 23:46
> To: [email-masked]
> Subject: [multimob] Multimob charter v2
> 
> Hi all,

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 20 May 2009 10:02:56 +0100

I see what you are saying, and this really depends on what the WG has 
hopes to study.... others please "speak-up" too on this list.

I'd personally like to keep the text focussed on the goals, but we 
should also identify any wider possibilities in the (near) future - if 
people hope to work on FMIP or HMIP, it could be OK to include this in 
the charter text.

The *goals* listed should be driven by need and current energy (we can 
update these later with IESG support, and would not necessarily need to 
re-charter).

The Milestones should be *very* focussed, and specific. If approved, an 
AD can add new milestones consistent with the charter text and goals.

That said - would anyone like to say something about their hopes (in 
future or otherwise) of working on HMIP or FMIP - if nobody thinks this 
is important, we can indeed safely condense these words....

Gorry

---

From: Liu Hui <[email-masked]>
Date: Wed, 20 May 2009 17:47:51 +0800

Hi Gorry,

I agree that the work of the group should not be too restrictive.
Previously I think if a unicast MIP protocol itself is too complicated, it
even has little chance to be deployed when incoorperated with multicast
support. Thus maybe not all of the MIP protocols will produce feasible
solutions.  But maybe it is too earlier to make this judgment or decision.  

Of course it's OK to include all of them at present and make adjustment of
the charter in the future according to the situations of the work presented,
as you suggested.  As long as there is interests in the work, it should not
be excluded from the group. 

Thanks,

Liu Hui 

> 
> I see what you are saying, and this really depends on what 
> the WG has hopes to study.... others please "speak-up" too on 
> this list.
> 
> I'd personally like to keep the text focussed on the goals, 
> but we should also identify any wider possibilities in the 
> (near) future - if people hope to work on FMIP or HMIP, it 
> could be OK to include this in the charter text.
> 
> The *goals* listed should be driven by need and current 
> energy (we can update these later with IESG support, and 
> would not necessarily need to re-charter).
> 
> The Milestones should be *very* focussed, and specific. If 
> approved, an AD can add new milestones consistent with the 
> charter text and goals.
> 
> That said - would anyone like to say something about their 
> hopes (in future or otherwise) of working on HMIP or FMIP - 
> if nobody thinks this is important, we can indeed safely 
> condense these words....
> 
> Gorry
> 
> 
> Liu Hui wrote:
> > Behcet,
> > 
> > Why in the beginning of this paragraph MIPv6, Dual-Stack 
> Mobile IPv6 and  MIPv4 is mentioned, while in the end they 
> should be considered "within the context of Proxy Mobile IPv6 
> (PMIPv6)" ?
> > 
> > Why FMIP and HMIP are mentioned combined with PMIP, what's 
> the relationship between PMIP and FMIP and HMIP ?
> > 
> > 
> > I feel it's not so clear to illustrate so many mip 
> protocols and make 
> > this classification
> > 
> > Because the wg hasn't yet seen clearly many works for other 
> unicast MIP protocols except for PMIP.   These protocols 
> should be mentioned with some examples instead being listed 
> "exhaustively". Otherwise the charter may look too inclusive 
> or miscellaneous to be accepted.
> > 
> > 
> > 
> > Best Regards,
> > 
> > Liu Hui
> > 
> > 
> >

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 20 May 2009 12:02:27 +0100

So,

Let me check - you're saying it is OK to have the MIP variants in the
"charter", but that it is more important to devote energy to PMIP -
because this is so much nearer to deployment?

To me, the latter means we should focus energy on PMIP, and seems to
suggest the milestones should ONLY relate to PMIP. Anyone disagree?

Gorry

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 20 May 2009 13:47:49 +0200

Hi Gorry,

> is important, we can indeed safely condense these words....

We would argue for keeping HMIPv6 and FMIPv6 in the agenda - being 
placed next to PMIPv6 or elsewhere.

HMIPv6 / FMIPv6 are the mobility optimization protocols that sustain the 
end-to-end design principle. I guess that's important at least for a 
systematic Internet development, even if operators don't like this 
end-to-end concept.

We also would want to continue work in this direction.

Cheers,

Thomas

>> Why in the beginning of this paragraph MIPv6, Dual-Stack Mobile IPv6 
>> and  MIPv4 is mentioned, while in the end they should be considered 
>> "within the context of Proxy Mobile IPv6 (PMIPv6)" ?
>>
>> Why FMIP and HMIP are mentioned combined with PMIP, what's the 
>> relationship between PMIP and FMIP and HMIP ?
>>
>>
>> Because the wg hasn't yet seen clearly many works for other unicast 
>> MIP protocols except for PMIP.   These protocols should be mentioned 
>> with some examples instead being listed "exhaustively". Otherwise the 
>> charter may look too inclusive or miscellaneous to be accepted.
>>
>>
>>
>> Best Regards,
>>
>> Liu Hui
>>
>>
>>
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Behcet Sarikaya
>>> Sent: 2009年5月19日 23:46
>>> To: [email-masked]

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 20 May 2009 23:08:30 +0900 (JST)

> > approved, an AD can add new milestones consistent with the charter
> > text and goals.
> > That said - would anyone like to say something about their hopes
> > (in future or otherwise) of working on HMIP or FMIP - if nobody
> > thinks this is important, we can indeed safely condense these
> > words....

I agree.

> HMIPv6 / FMIPv6 are the mobility optimization protocols that sustain
> the end-to-end design principle. I guess that's important at least
> for a systematic Internet development, even if operators don't like
> this end-to-end concept.

I don't have strong opinions for HMIP6/FMIP6, but is (are) there
Standards Track document(s) for these protocols, like RFC5213?
If not, this multimob group cannot propose any Standards Track
document for them.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 May 2009 07:39:35 -0700 (PDT)

Hello Folks,
  It seems like v2 charter is acceptable to most so we keep it.
Regarding Hitoshi's comment, please see my reply below.

If you have any other comments please post.

Regards,

Behcet

----- Original Message ----
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Sent: Wednesday, May 20, 2009 9:08:30 AM
Subject: Re: [multimob] Multimob charter v2

I agree.

[behcet] HMIP6 RFC 4140 is experimental. but the new one RFC 5380 is standards track FMIP6 RFC 5268 is standards track. So maybe we should keep both?

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 21 May 2009 00:48:36 +0900 (JST)

> [behcet] HMIP6 RFC 4140 is experimental. but the new one RFC 5380 is
> standards track FMIP6 RFC 5268 is standards track. So maybe we
> should keep both?

If there are many supporters and no negative opinion, I think they
could be kept in it.
Regards,
--
Hitoshi Asaeda

---

From: "Romdhani, Imed" <[email-masked]>
Date: Wed, 20 May 2009 16:50:02 +0100

Dear Folks,

Substantial progress has been made to finalise the second version of the chapter. I would like to share with you these extra comments about it:

.	It seems to me that we are omitting the source mobility issues, however in RFC5110, section 2.6.1, it is stated that (In intra-domain or Embedded-RP scenarios, ASM senders may move to a new IP address without significant impact on the delivery of their transmission. SSM senders cannot change the IP address unless receivers join the new channel or the sender uses an IP mobility technique that is transparent to the receivers). I think we need here to decide whether we are going to investigate and define a possible mobility technique that can help to sort out this problem or not. If source mobility is out of the scope of our work, we need to clarify it too.
.	I think multicast data loss during handover is a common issue for both remote and bi-directional subscription methods and it is not a specific problem for remote subscription only. Therefore, Multimob can focus on how to reduce packet loss by enhancing the functionality of the mobility agents (Home Agent, Access Router, Mobility Anchor Point, Mobile Proxy, etc.). Example of enhancement could include buffering techniques on these agents (not only on PMIPv6). 
.	The statement "PMIPv6 will be extended to also support multicasting in IPv4" seems confusing. Are we going to specify another version for IPv4 (PMIPv4) or a more generic version for both (PMIP that handles IPv4 and IPv6).
.	If our group is going to propose solutions for the receiver's issues (tunnel avalanche, triangle routing, packet loss and fast handover capability) by considering PMIPv6 only, in this case the scope of the work should be rephrased: "the scope of this work will be limited to group management and PMIPv6 protocols".
.	In my own point of view, the multi-homing issue is not a key problem to address. A Multi-homed receiver inherits the same problem (Join delay, packet loss, battery consumption, etc.) as a simple receiver with a single network interface.  The multicasting issues are linked to the type of the subscription method used and not the number of network interfaces or the number of multicast groups.
In brief, I do believe that multicast mobility issues can be addressed by either enhancing Mobile IP protocols (Functionality and behaviour of mobile IP components) or adapting current multicast protocols to handle mobile devices. In both cases, we need to choose which roadmap we are going to take. For future direction, we can focus on security issues and multicast routing extensions for Mobile IPv4 and IPv6.

Cheers,
Imed
---------------------------------------------------
Imed Romdhani, PhD
IEEE Member 
Lecturer in Networking
Room C 64
Edinburgh Napier University
School of Computing
10 Colinton Road
Edinburgh, EH10 5DT
UK
E-Mail:   [email-masked]
Home Page: http://www.dcs.napier.ac.uk/~cs244/
Telephone: +44(0)131 455 2726
Fax: +44(0)131 455 2727
---------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: 20 May 2009 15:40
To: Hitoshi Asaeda; [email-masked]
Subject: Re: [multimob] Multimob charter v2

Hello Folks,

Regards,

Behcet

----- Original Message ----
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Sent: Wednesday, May 20, 2009 9:08:30 AM
Subject: Re: [multimob] Multimob charter v2

I agree.

      

On 25 February 2009, the University launched its new name, Edinburgh Napier University.  

For more information please visit our website.

Edinburgh Napier University is the number one in Scotland for graduate employability (HESA 2008)

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else out-with the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 May 2009 10:57:54 -0500

Hi Imed

IMHO, receiver mobility seems to be
more pragmatical, such as IPTV.

It is better to start small.

BR
Frank

----- Original Message ----- 
From: "Romdhani, Imed" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 20, 2009 10:50 AM
Subject: Re: [multimob] Multimob charter v2

Dear Folks,

Substantial progress has been made to finalise the second version of the 
chapter. I would like to share with you these extra comments about it:

. It seems to me that we are omitting the source mobility issues, however in 
RFC5110, section 2.6.1, it is stated that (In intra-domain or Embedded-RP 
scenarios, ASM senders may move to a new IP address without significant 
impact on the delivery of their transmission. SSM senders cannot change the 
IP address unless receivers join the new channel or the sender uses an IP 
mobility technique that is transparent to the receivers). I think we need 
here to decide whether we are going to investigate and define a possible 
mobility technique that can help to sort out this problem or not. If source 
mobility is out of the scope of our work, we need to clarify it too.
. I think multicast data loss during handover is a common issue for both 
remote and bi-directional subscription methods and it is not a specific 
problem for remote subscription only. Therefore, Multimob can focus on how 
to reduce packet loss by enhancing the functionality of the mobility agents 
(Home Agent, Access Router, Mobility Anchor Point, Mobile Proxy, etc.). 
Example of enhancement could include buffering techniques on these agents 
(not only on PMIPv6).
. The statement "PMIPv6 will be extended to also support multicasting in 
IPv4" seems confusing. Are we going to specify another version for IPv4 
(PMIPv4) or a more generic version for both (PMIP that handles IPv4 and 
IPv6).
. If our group is going to propose solutions for the receiver's issues 
(tunnel avalanche, triangle routing, packet loss and fast handover 
capability) by considering PMIPv6 only, in this case the scope of the work 
should be rephrased: "the scope of this work will be limited to group 
management and PMIPv6 protocols".
. In my own point of view, the multi-homing issue is not a key problem to 
address. A Multi-homed receiver inherits the same problem (Join delay, 
packet loss, battery consumption, etc.) as a simple receiver with a single 
network interface.  The multicasting issues are linked to the type of the 
subscription method used and not the number of network interfaces or the 
number of multicast groups.
In brief, I do believe that multicast mobility issues can be addressed by 
either enhancing Mobile IP protocols (Functionality and behaviour of mobile 
IP components) or adapting current multicast protocols to handle mobile 
devices. In both cases, we need to choose which roadmap we are going to 
take. For future direction, we can focus on security issues and multicast 
routing extensions for Mobile IPv4 and IPv6.

Cheers,
Imed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Behcet Sarikaya
Sent: 20 May 2009 15:40
To: Hitoshi Asaeda; [email-masked]
Subject: Re: [multimob] Multimob charter v2

Hello Folks,

Regards,

Behcet

----- Original Message ----
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Sent: Wednesday, May 20, 2009 9:08:30 AM
Subject: Re: [multimob] Multimob charter v2

I agree.

[behcet] HMIP6 RFC 4140 is experimental. but the new one RFC 5380 is 
standards track FMIP6 RFC 5268 is standards track. So maybe we should keep 
both?

On 25 February 2009, the University launched its new name, Edinburgh Napier 
University.

Edinburgh Napier University is the number one in Scotland for graduate 
employability (HESA 2008)

This message is intended for the addressee(s) only and should not be read, 
copied or disclosed to anyone else out-with the University without the 
permission of the sender.
It is your responsibility to ensure that this message and any attachments 
are scanned for viruses or other defects. Edinburgh Napier University does 
not accept liability for any loss or damage which may result from this email 
or any attachment, or for errors or omissions arising after it was sent. 
Email is not a secure medium. Email entering the University's system is 
subject to routine monitoring and filtering by the University.

Edinburgh Napier University is a registered Scottish charity. Registration 
number SC018373