Subject: [multimob] Charter discussion

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Jun 2009 08:06:11 -0700 (PDT)

Hello Folks,
  This is the latest charter I have. Please comment. 

Regards,

Behcet

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 Jun 2009 16:42:59 +0100

Hi Bechet,

Just to be clear, this is NOT YET the charter of the group. The draft 
you posted was for comment by people with some ideas to improve the 
charter. I'd also welcome thoughts on whether we have the current 
charter and milestones correct.

The current approved charter for the BoF is at:
http://www.arkko.com/ietf/ietf-75/multimob/charter.txt

My own take would be that the Charter text was OK. However, I would like 
to see the milestones updated. Here are my suggestions:

Six months:
- Submit a document on minimal deployment for PMIPv6 remote subscription 
for multicast as a BCP RFC

One year:
- Submit a document on tuning of IGMP/MLD in mobile multicast mobility 
as a BCP RFC.
- Submit a document on IGMP/MLD extensions for multicast mobility as an 
EXP/PS RFC.
- Submit a document on extensions for multicast mobility in PMIPv6 as an 
EXP/PS RFC.
- Submit a document on multihoming requirements for multicast as a INFO 
RFC.

As a co-Chair, I would be *REALLY* interested on views on the last item 
above, to understand whether people there is a need for this document 
and whether it is realistic to see this work completed by a WGLC one 
year after this work is started.

Thoughts welcome, either sent to the chairs (cc us both) or via the list.

Gorry Fairhurst
(as Co-Chair)

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Jun 2009 09:02:01 -0700 (PDT)

Hi Gorry,
  Yes, this is a draft and the idea is to keep discussing it on the list. We will post the latest one when IETF BoF page is on.

Yes, I agree that we should concentrate on the milestones, so please use the list below rather than repeat the whole charter text.

Regards,

Behcet

----- Original Message ----
> From: Gorry Fairhurst <[email-masked]>
> To: [email-masked]
> Cc: Behcet Sarikaya <sarikaya@ieee..org>
> Sent: Monday, June 22, 2009 10:42:59 AM
> Subject: Re: [multimob] Charter discussion
> 
> 
> Hi Bechet,
> 
> Just to be clear, this is NOT YET the charter of the group. The draft you posted 
> was for comment by people with some ideas to improve the charter. I'd also 
> welcome thoughts on whether we have the current charter and milestones correct..
> 
> My own take would be that the Charter text was OK. However, I would like to see 
> the milestones updated. Here are my suggestions:
> 
> Six months:
> - Submit a document on minimal deployment for PMIPv6 remote subscription for 
> multicast as a BCP RFC
> 
> One year:
> - Submit a document on tuning of IGMP/MLD in mobile multicast mobility as a BCP 
> RFC.
> - Submit a document on IGMP/MLD extensions for multicast mobility as an EXP/PS 
> RFC..
> - Submit a document on extensions for multicast mobility in PMIPv6 as an EXP/PS 
> RFC.
> - Submit a document on multihoming requirements for multicast as a INFO RFC.
> 
> As a co-Chair, I would be *REALLY* interested on views on the last item above, 
> to understand whether people there is a need for this document and whether it is 
> realistic to see this work completed by a WGLC one year after this work is 
> started.
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 23 Jun 2009 01:18:41 +0900 (JST)

Hi,

> Six months:
> - Submit a document on minimal deployment for PMIPv6 remote
> subscription for multicast as a BCP RFC

I may just drop some discussion in this ML, but what does the
"minimal" deployment for "remote" subscription mean?
I remember there was some discussion about home subscription (or
bi-directional tunneling method) for forwarding multicast data without
any protocol modification.
Doesn't this statement mean it?

> As a co-Chair, I would be *REALLY* interested on views on the last
> item above, to understand whether people there is a need for this
> document and whether it is realistic to see this work completed by a
> WGLC one year after this work is started.

It is not only for mobility, too.
I think describing multihoming support should not be included in the
initial charter for this group. Clarifying multihoming "requirement"
may not be a bad idea, but, well, in any case multihoming related
stuff is not the primary work of this group, I guess.

One question.
Previously we agreed to describe "problem statement" drafts and
"requirement" drafts for both IGMP/MLD and PMIPv6 stuff. They are not
needed any more? If yes, why? I think clarifying problem statement is
at least necessary.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 22 Jun 2009 20:09:15 +0200

Hi Gorry,

I pretty much agree with the charter and modified list of milestones 
below. In particular, it sounds reasonable to move multihoming out of 
the first 6 month. There might be also interest to treat mobility 
protocols other than PMIP.

Regarding problem-statements/ requirement drafts: I suppose, a general 
problem statement is not needed (but there). Specific requirements 
drafts have been around (and should be improved), but will not be needed 
for the initial BCP-type of activities: requirements here are obvious as 
given from the related specs in mcast and mobility.

Best regards,

Thomas

---

From: Frank Xia <[email-masked]>
Date: Mon, 22 Jun 2009 14:24:16 -0500

Hi Guys

Mostly I am fine with the charter.
However, it would be better to remove
multihoming work from first 6 month work.

IMO, getting multimob approved
is our common goal, and  starting small
is probably a good strategy.

BR
Frank

----- Original Message ----- 
From: "Thomas C. Schmidt" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 22, 2009 1:09 PM
Subject: Re: [multimob] Charter discussion

> below. In particular, it sounds reasonable to move multihoming out of the 
> first 6 month. There might be also interest to treat mobility protocols 
> other than PMIP.
>
> problem statement is not needed (but there). Specific requirements drafts 
> have been around (and should be improved), but will not be needed for the 
> initial BCP-type of activities: requirements here are obvious as given 
> from the related specs in mcast and mobility.
>
> Best regards,
>
> Thomas
>
> Gorry Fairhurst wrote:
>>
>> Hi Bechet,
>>
>> Just to be clear, this is NOT YET the charter of the group. The draft you 
>> posted was for comment by people with some ideas to improve the charter. 
>> I'd also welcome thoughts on whether we have the current charter and 
>> milestones correct.
>>
>> - Submit a document on tuning of IGMP/MLD in mobile multicast mobility as 
>> a BCP RFC.
>> above, to understand whether people there is a need for this document and 
>> whether it is realistic to see this work completed by a WGLC one year 
>> after this work is started.
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 22 Jun 2009 14:24:00 -0700 (PDT)

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Monday, June 22, 2009 1:09:15 PM
> I pretty much agree with the charter and modified list of milestones below. In 
> particular, it sounds reasonable to move multihoming out of the first 6 month. 
> There might be also interest to treat mobility protocols other than PMIP.
> 
> Regarding problem-statements/ requirement drafts: I suppose, a general problem 
> statement is not needed (but there). Specific requirements drafts have been 
> around (and should be improved), but will not be needed for the initial BCP-type 
> of activities: requirements here are obvious as given from the related specs in 
> mcast and mobility.

Yes, specific requirements draft like:
http://ietfreport.isoc.org/all-ids/draft-deng-multimob-pmip6-requirement-01.txt
http://ietfreport.isoc.org/all-ids/draft-liu-multimob-igmp-mld-mobility-req-01.txt

need to be improved, the authors, please post a revised version and let us know.

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 23 Jun 2009 12:10:49 +0900 (JST)

> problem statement is not needed (but there).

What is "general" problem?
And why do you think problem statement is not needed?

I wonder the same discussion will come up again and again, "why
multicast support for mobility should be discussed and why multicast
does not properly work with mobility protocol, say PMIPv6?".
If people already shared the problems and have the concensus of
multimob work, then the problem statement draft wouldn't be necessary.
I've thought the reason why many people always doubt multimob work is
that there is no good problem statement draft to answer the question.

> Specific requirements
> drafts have been around (and should be improved), but will not be
> needed for the initial BCP-type of activities: 

Why you assume "BCP" here?

> requirements here are
> obvious as given from the related specs in mcast and mobility.

If requirements were obvious, the requirements draft wouldn't be
needed. I've just suspected it.

Regards,
--
Hitoshi Asaeda

---

From: Liu Hui <[email-masked]>
Date: Tue, 23 Jun 2009 14:22:55 +0800

Hi  all,

We authors will try to improve the "igmp requirement draft" below before
this meeting.

For the discussed charter, 'start small' is a good policy that we should
follow, but before we decide what proper specific things to start from, some
general analysis may also be needed. For without the comprehensive view, how
can we tell the value of each specific solution?

For most drafts contributed to multimob, they must have their standpoints
and their wits. But, do they solve a real problem? Can they be merged into
the multicast mobility architecture? Are they a good solution to solve the
problem? And finally, do they deserve being published as an RFC? Before
answering these questions, at least a general picture should be depicted in
our mind and be agreed beforehand. 

I have no negative viewpoint against the charter. I suggest before we decide
a final version, some general discussions on the list may be helpful both
for clarification and for quality improvement. 

Best Regards,
Liu Hui 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, June 23, 2009 5:24 AM
> To: Thomas C. Schmidt; [email-masked]
> Cc: [email-masked]
> > below. In particular, it sounds reasonable to move 
> multihoming out of the first 6 month.
> > needed for the initial BCP-type of activities: requirements 
> here are

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 23 Jun 2009 12:28:21 +0200

Hi Hitoshi,

> What is "general" problem?

I don't know: I spoke about a "general problem statement" regarding 
multicast mobility.

> And why do you think problem statement is not needed?

Because it's there: 
http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

> Why you assume "BCP" here?

Because it is written in the charter / in the list Gorry sent.
> needed. I've just suspected it.

??? Unclear what you mean.

What I intended to say - and what work I wanted to stimulate: Those 
items of the charter that are BCP-type of documents do not change specs. 
In complying to the existing specs, the requirements for this type of 
work are pretty clearly available. That's why work can easily progress 
right now.

The picture may change once we look at modifying protocols for optimization.

Best regards,

Thomas
-- 

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: Tue, 23 Jun 2009 20:18:15 +0900 (JST)

Thomas,

> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps

Maybe it does not help making people recognize the problems this
multimob group wants to address. It just says many things. It is
difficult to understand "what is the real problem?".

Ok, then how about improving the following two requirement drafts

> need to be improved, the authors, please post a revised version and

It is good to clarify also the problems for supporting multicast
with PMIPv6 and IGMP/MLD protocols in these drafts, isn't it?

> Because it is written in the charter / in the list Gorry sent.

Maybe a category of problem statement and requirement draft would be
Informational?

> ??? Unclear what you mean.

I mean both problem statement and requirement should be clarified in
either one or separate drafts (for each target protocol).

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 23 Jun 2009 13:32:36 +0200

Hi Hitoshi,

> difficult to understand "what is the real problem?".

I guess you expect me to disagree :-): We consider the major 
contribution of the PS to bring densely together all the different key 
aspects of the problem space. This is indeed not a trivial collection 
and cannot be "easy reading".

The problem we had with all the other drafts was a very partial focus 
that missed major parts of the problems - leading to confusion and also 
to the diverse positions arising at the previous BoF (remember the wise 
words of Rajeev).

So our argument would be: if you carefully read the PS, the "real" 
problems of multicast + mobility will be very clear. Details on specific 
tasks can then be easily derived by just doing transfers.

>> http://ietfreport.isoc.org/all-ids/draft-deng-multimob-pmip6-requirement-01.txt

I promised to work on this - however, I would put higher priority on the 
BCP-type solution for PMIPv6, so I beg some patience.

>> http://ietfreport.isoc.org/all-ids/draft-liu-multimob-igmp-mld-mobility-req-01.txt

We had a volunteer just two mails ago.

[...]

> Maybe a category of problem statement and requirement draft would be

Yes, I guess so.

Best regards,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 23 Jun 2009 20:50:02 +0900 (JST)

> problems of multicast + mobility will be very clear. Details on
> specific tasks can then be easily derived by just doing transfers.

I tend to disagree.
I cannot imagine one can recognize the real problem after he/she reads
the irtf-mobopts-mmcastv6-ps draft.

My opinion is that it is good to improve two requirement drafts with
clear problem statement.

Regards,
--
Hitoshi Asaeda

---

From: Liu Hui <[email-masked]>
Date: Wed, 24 Jun 2009 13:03:47 +0800

Hi Gorry,

I think the milestones listed below should be improved by introducing some
works describing general issues, for they are the foundations for the group.
Please indicate if you have different viewpoints then we can take a
discussion.

First,  there are two requirement drafts which was submitted to this group
in the early stage and have had positive influences on the later work
submitted. They are respectively "PMIP requirements"  and "Group management
requirements" drafts, as Behcet listed in a previous mail. They should be
improved and included in the milestones.

Secondly, an architecture draft is needed in the milestone because it helps
to make a framework and should support all the work in the group, and helps
to prevent uselessness and aimlessness of the our work. This is also the
initiative for me to prepare the architecture draft for "Multicast Mechanism
for Receiver Mobility".  It is just a startpoint and needs the coorporation
of the participants to make a good construction based on it. A milestone for
architecture draft should be added. 

Thirdly, if PMIP is considered first, may the work for PMIP handover
optimization be added to the milestones? Such as:

     - Submit an intial document on PMIP handover optimization. 

Some drafts already includes this aspect and they will definitely been
discussed in the future.

Best Regards,
Liu Hui

> [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Monday, June 22, 2009 11:43 PM
> To: [email-masked]
> Just to be clear, this is NOT YET the charter of the group. 
> The draft you posted was for comment by people with some 
> ideas to improve the charter. I'd also welcome thoughts on 
> whether we have the current charter and milestones correct.
> 
> My own take would be that the Charter text was OK. However, I 
> would like to see the milestones updated. Here are my suggestions:
> 
> Six months:

> 
> One year:
> - Submit a document on tuning of IGMP/MLD in mobile multicast 
> mobility as a BCP RFC.

> - Submit a document on IGMP/MLD extensions for multicast 
> mobility as an EXP/PS RFC.

> - Submit a document on extensions for multicast mobility in 
> PMIPv6 as an EXP/PS RFC.

> 
> As a co-Chair, I would be *REALLY* interested on views on the 
> last item above, to understand whether people there is a need 
> for this document and whether it is realistic to see this 
> work completed by a WGLC one year after this work is started.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 24 Jun 2009 10:09:33 +0100

I need to re-assess what needs to be done. I would welcome comments on 
the list before the end of Thursday 25th - to allow the chairs to 
discuss what needs to be done. I would like to see a final charter 
adopted early next week.

Others please feel free to also express your thoughts.

See specific comments, in-line.

Best wishes,

Gorry

> Please indicate if you have different viewpoints then we can take a
I may have different viewpoints, but I am keen to find how others 
perceive the intended work to be undertaken. It is important we scope 
the work correctly.

I thought (was I right?) that the group understood both the intended 
areas of work and had now draft documents (i.e. drafts that could become 
BCPs or PS Updates). As I see it, the currently proposed charted 
milestones consist of small, but important, updates to existing 
specifications, achievable in 6-12 months.

If the problem space is larger, this group would need a set of 
problem-statements and requirements (for each work item?). If so, I'd be 
keen to check that these specific documents have been widely accepted by 
other related IETF groups prior to any BoF.

> improved and included in the milestones.
Yes, I was aware of these, but was not aware that the group intended 
these for publication - key parts of problem-statements often mutate 
into parts of other documents.

> architecture draft should be added. 
Yes, I saw your contribution, thanks. On this I need to understand more 
clearly why we also need a wider-scope Info architecture document on 
IPv4, FMIP, etc. Could we take these wider-items as a part of a future 
set of milestones, and initially focus on PMIP and MLD?

>      - Submit an initial document on PMIP handover optimization. 
> 
So, you see this as an additional charter item? I'd hoped it could be 
reflected as a part of the current milestone:
- Submit a document on minimal deployment for PMIPv6 remote subscription 
for multicast as a BCP RFC.

Do you think this is possible?

> Some drafts already includes this aspect and they will definitely been
I was hoping we would have one document that sets out the architecture 
and how to do a minimal deployment, and one that updates PMIP on how to 
do optimised deployment.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 24 Jun 2009 18:42:17 +0900 (JST)

Hi,

> Yes, I saw your contribution, thanks. On this I need to understand
> more clearly why we also need a wider-scope Info architecture
> document on IPv4, FMIP, etc. Could we take these wider-items as a
> part of a future set of milestones, and initially focus on PMIP and
> MLD?

I agree. Smaller charter is a good start.

> > - Submit an initial document on PMIP handover optimization. 

It will be (actually, it "is") included in one PMIP extension draft.
I don't think any benefit to split the handover scenario from the
extension draft at this phase.

> So, you see this as an additional charter item? I'd hoped it could
> be reflected as a part of the current milestone:
> subscription for multicast as a BCP RFC.

I'm sorry, but I still cannot imagine this.
Well, whether I imagine this or not, is this really needed for the
initial charter? Smaller charter is good for booting.

Regards,
--
Hitoshi Asaeda

---

From: Liu Hui <[email-masked]>
Date: Wed, 24 Jun 2009 19:29:11 +0800

Hi Gorry,

Thanks for your comments. please see mine inline and forgive me if I'm too
straight.

> > 
> > I think the milestones listed below should be improved by 
> introducing 
> > some works describing general issues, for they are the 
> foundations for the group.
> I may have different viewpoints, but I am keen to find how 
> others perceive the intended work to be undertaken. It is 
> important we scope the work correctly.
> 
> I thought (was I right?) that the group understood both the 
> intended areas of work and had now draft documents (i.e. 
> drafts that could become BCPs or PS Updates). As I see it, 
> the currently proposed charted milestones consist of small, 
> but important, updates to existing specifications, achievable 
> in 6-12 months.
> 
> If the problem space is larger, this group would need a set 
> of problem-statements and requirements (for each work item?). 

Should not be a separate requirement for each item. These two requirements
scope two major area that have been filled with the work you think
important.   

> If so, I'd be keen to check that these specific documents 
> have been widely accepted by other related IETF groups prior 
> to any BoF.

Do you mean to check all the documents have been and will be listed in the
milestone? 

> 
> > First,  there are two requirement drafts which was 
> submitted to this 
> > group in the early stage and have had positive influences 
> on the later work
> > requirements" drafts, as Behcet listed in a previous mail. 
> They should 
> > be improved and included in the milestones.
> > 
> Yes, I was aware of these, but was not aware that the group 
> intended these for publication - key parts of 
> problem-statements often mutate into parts of other documents.

Should they be deleted because they are mutated. Could we mutate drafts
included in current milestone by some manner to some other forms of drafts
and then delete them because they haven been mutated? 

 If this is a rule, there should be no requirement draft in IETF, because
they mostly have the possibility to be mutated to other documents. 

> 
> > Secondly, an architecture draft is needed in the milestone 
> because it 
> > helps to make a framework and should support all the work in the 
> > group, and helps to prevent uselessness and aimlessness of the our 
> > work. This is also the initiative for me to prepare the 
> architecture 
> > draft for "Multicast Mechanism for Receiver Mobility".  It 
> is just a 
> > startpoint and needs the coorporation of the participants to make a 
> > good construction based on it. A milestone for architecture 
> draft should be added.
> > 
> Yes, I saw your contribution, thanks. On this I need to 

You are welcome. And it's my pleasure that you saw it :)

> understand more clearly why we also need a wider-scope Info 
> architecture document on IPv4, FMIP, etc. Could we take these 
> wider-items as a part of a future set of milestones, and 
> initially focus on PMIP and MLD?

Yes. It's good that the initial draft is focused on PMIP and MLD. But our
future work should not be limited to them. 

For multicast mobility, to intergrate the multicast and MIP, no matter what
kind of group managment protocol, multicast routing protocol and MIP used,
there exists a common infrastructure that make this intergration work and
scale.  It is already abstracted in the draft. 

Can we definitely say we will not support IPv4 and FMIP in our future work?
If they are possible and usable in multicast mobility, why should they be
scoped out?  If we write a small architecture scoped in PMIP and MLD, will
we write other architecture ones when we consider other MIP protocols or
other type of IP network?  If anyone can stand and say this MIP protocol or
this network type will definitely kick out others, I will immediately sit
down to revise my draft to only include the winners.

Thus small is good manner to start to work, but not necessarily good for an
architecture draft. And as you see, it is possible, as the draft show.

> So, you see this as an additional charter item? I'd hoped it 
> could be reflected as a part of the current milestone:

The superficial words do not indicate these milestones include "handover
optimization".  Handover is a complicated and important issue,  .  For
example the remote subscription in the above milestone requires handover
optimization, but the tunnel method should also need one.  Sometimes they
are close coupled to a solution, sometimes they are relatively independent. 

> I was hoping we would have one document that sets out the 
> architecture and how to do a minimal deployment, and one that 
> updates PMIP on how to do optimised deployment.

Please show your detailed thinking about what's the minimal and optimised
deployments and why you think it's necessary to have them.

Best Regards,
Liu Hui

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 24 Jun 2009 15:11:22 +0200

Hi Liu, hi Gorry,

  I would limit the list of milestones (as proposed) and in particular not 
add an architecture document. This seems a bit overburden: Desgining a 
protocol independent, all-fit solution in the timeline of the charter is a 
bit ambitious. If a strong need arises, we can recharter after 1 1/2 year.

  Regarding the "minimal and optimised deployments" discussion: I'm not 
sure, if I understand it correctly. Obviously, a minimal deployment 
solution has not to be optimal (with respect to tunnel states, traffic 
flow ...), but it does not require changes to the core specs (MIP, PMIP, 
...). However, both classes of solutions provide "handover" support.

Regards
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Jun 2009 09:08:46 -0700 (PDT)

Hello everybody,

----- Original Message ----
> Cc: Behcet Sarikaya <[email-masked]>
snipped

> - Submit a document on multihoming requirements for multicast as a INFO RFC.

Can we say that there is consensus on the above? If yes, we can set the above as our milestones.

Regards,

Behcet

---

From: Frank Xia <[email-masked]>
Date: Wed, 24 Jun 2009 11:15:06 -0500

I am fine with the these.

BR
Frank
----- Original Message ----- 
From: "Behcet Sarikaya" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 24, 2009 11:08 AM
Subject: Re: [multimob] Charter discussion

Hello everybody,

----- Original Message ----
snipped

> a BCP
> EXP/PS
> EXP/PS

Can we say that there is consensus on the above? If yes, we can set the 
above as our milestones.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Jun 2009 13:28:46 -0700 (PDT)

Hi Hui,

----- Original Message ----
> From: Liu Hui <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Wednesday, June 24, 2009 6:29:11 AM

I think this is a good suggestion. If you wish to revise your draft, it is a good idea to revise it in this direction, i.e. focus the architecture on PMIP and MLD.

Regards,

Behcet

---

From: Liu Hui <[email-masked]>
Date: Thu, 25 Jun 2009 09:46:43 +0800

Hi, Behcet,

> initially 
> > > focus on PMIP and MLD?> > 
> 
> 
> I think this is a good suggestion. If you wish to revise your 
> draft, it is a good idea to revise it in this direction, i.e. 
> focus the architecture on PMIP and MLD.

Yes. Gorry's suggestion is really good. 

And I suggest it's better that the work is taken by the cooperation of the
group.

Best Regards,
Liu Hui

---

From: Liu Hui <[email-masked]>
Date: Thu, 25 Jun 2009 09:46:24 +0800

Hi Matthias 

>  I would limit the list of milestones (as proposed) and in 
> particular not add an architecture document. This seems a bit 
> overburden: Desgining a protocol independent, all-fit 
> solution in the timeline of the charter is a bit ambitious. 
> If a strong need arises, we can recharter after 1 1/2 year.

It should not be an all-fit solution.  As I see it, the work of this group
has some differences from other group that it majorly should not be the
design of new protocols, but should be the intergration of different
independent protocols in MIP and multicast area.  An architecture is useful
for picking out the appropriate components from these miscellaneous
techniques and make the construction. 

If a timeline must be strictly limited. It's OK not to include this
architecture work in current milestone.  The draft could be continued to be
improved to see the work of other protocols currently not being processed,
if I'm able to. 

>   Regarding the "minimal and optimised deployments" 
> discussion: I'm not sure, if I understand it correctly. 
> Obviously, a minimal deployment solution has not to be 
> optimal (with respect to tunnel states, traffic flow ...), 
> but it does not require changes to the core specs (MIP, PMIP, 

We'll welcome them if they are good thinking.

Best Regards, 
Liu Hui

---

From: jouni korhonen <[email-masked]>
Date: Thu, 25 Jun 2009 12:32:37 +0300

Hi,

I got few comments. My overall feeling is that this proposed charter  
just tries to tackle too many things. I would start with the absolute  
minimal work that is needed to identify/clarify/fix possible issues  
with (network based) mobility and multicast. Once that is done, re- 
evaluate and re-charter if necessary (assuming the WG would be formed  
in the first place).

Then some more specific comments inline prefixed with [JiK]. I did  
this based on the "original" charter text and shamelessly bypassed the  
recent discussion on the mailing list ;)

Cheers,
	Jouni

----------

Description of Working Group

The Multicast mobility (multimob) will develop a set of protocol  
extensions and provide guidance appropriate for IPv4 and IPv6  
multicast in a mobile environment. It will consider both source  
specific multicast (SSM)  and any source multicast (ASM) multicast  
models.

The scope of work will be limited to group management and mobile IP  
protocols - proxied or client-based. Work requiring modifications of  
multicast routing protocols (PIM-SM, PIM-DM, etc.) is out of scope.  
Specific goals are:

- Specify PMIPv6 extensions to support IPv6 multicast including remote  
subscription and fast handover.
- Specify IGMP/MLD extensions methods for reducing join/leave latency.
- Specify a dormant mode operation for IGMPv3/MLDv2.
- Provide guidance and specify methods for multi-homing support for  
multicast.

[JiK] imho specific first step goals could be
[JiK] - Identify and document issues that prevent use of multicast  
with IETF defined IP mobility protocols
[JiK] - Provide guidance and base line specification how to deploy  
multicast with IETF defined IP mobility protocols
[JiK] Scoping could be more strict. For example, scope the first round  
mobility protocol only to PMIP and listener mobility. Other stuff can  
be mentioned to be "in future scope".

Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and  
also Mobile IPv4) provide basic multicast support and enable mobile  
nodes to perform bi-directional tunneling and receive multicast  
traffic anchored at the home agent. However, such basic support  
suffers from the 'avalanche' problem as the home agents replicate the  
packets and unicast them to the mobile nodes as well as from non- 
optimal, triangular routing, 'remote subscription' suffers from  
possible loss of data during handovers. The WG will address these  
issues within the context of Proxy Mobile IPv6 (PMIPv6).

[JiK] What are "unicast mobility protocol"? The text seems to indicate  
they actually are client based mobility protocols.
[JiK] What does "remote subscription" mean? Does it mean a) the MN is  
roaming in a visited network using telecom terminology, or b) the MN  
has joined a multicast group that is not available in the visited  
foreign network, or c) the MN has joined to a multicast group it  
intends to receive though the IP mobility solution provided means  
(i.e. forwarded to the MN via the HA/LMA).

[JiK] Honestly, my original impression was that multimob would  
concentrate on PMIP6 at the beginning. If it is so, then the charter  
text should also be more biased towards it. There can be a backdoor in  
the text to add more stuff after re-chartering, for example saying  
that the WG will study/evaluate whether client MIP or IGMP/MLD needs  
more work. The current mixing of both client MIP and proxy MIP issues  
& descriptions make the charter confusing, and I would assume also  
makes a forming a WG more challenging.

Currently PMIPv6 (and mobility extension protocols like  FMIPv6 and  
HMIPv6) does not  support multicasting explicitly. Basic support for  
multicast with bi-directional tunneling will be documented for PMIPv6  
(with no new message types or  changes to the message parameters).  
PMIPv6 that handles IPv4 and IPv6 will be extended to also support  
multicasting with IPv4. Finally, PMIPv6 basic multicast support will  
be extended to support remote subscription and fast handover.

[JiK] I agree that current PMIP specification is vague when it comes  
to handling of multicast and imho that deserves to be clarified/fixed.  
Imho the paragraph above should not mix FMIP & HMIP with PMIP here,  
just for clarity and keeping things simple.

[JiK] I would not propose a solution (e.g. bi-directional tunneling)  
immediately here in the description text, especially as we are not  
sure bi-directional tunneling type of solution is even applicable in  
the context of PMIP and unmodified hosts. Just say "a solution" or  
extension or deployment guidance is needed.

Multimob will specify a set of extensions to IGMPv3/MLDv2 for mobile  
environments. IGMPv3/MLDv2 has been specified for wired networks with  
shared links. Mobile nodes also have other needs (e.g.  entering a  
dormant mode to conserve battery power, minimising the

[JiK] Would say multimob will study/evaluate whether extensions to  
IGMP3/MLDv2 are needed for supporting mobile environments.

latency for joining and leaving a group in support of movement).  The  
working group will assess existing solutions for group management, and  
determine if these methods are sufficient. This will include defining  
best current practice for selection of timer values and protocol  
parameters. If these methods are not sufficient, the working group  
shall propose new solutions as updates to

[JiK] BCP/informational type of guidelines is OK regarding timers and  
such. Do we actually have operational data on those in wireless/mobile  
environments?

existing protocols (including possible introduction of additional  
message types). It is a goal for the working group to ensure backward  
compatibility with the current implementations of group management  
protocols. Message structures supported in current deployed networks  
will not be modified.

A multi-homed mobile node may wish to join multicast groups and to  
direct different multicast flows to its interfaces. The working group  
will define multi-homing support for multicast, including an efficient  
per-interface subscription management in the case of multi-homed  
mobility and multicast flow binding.

[JiK] I would strongly consider _not_ to include this multihoming  
topic here. Work on this in Mif or re-charter later.

In performing this work, the Multimob working group will work closely  
with NETLMM
working group and will coordinate work on IGMP/MLD extensions with the  
MBONED working group.

GOALS and MILESTONES:

six months:

- Submit an informational document explaining the use of multicast in  
PMIPv6.

[JiK] This is Ok and imho needed.
[JiK] Also would like to see a short evaluation document of issues  
with mobility & multicast. The IRTF I-D type of thing (by Thomas  
et'al) but probably slightly more compact and written in a way that it  
could be used to justify exact possible future work topics.. as a tool  
for re-chartering.
[JiK] Maybe 6 months is a bit too ambitious?

One year:
- Submit a document on extensions for multicast mobility in PMIPv6 as  
an EXP/PS RFC.
- Submit a BCP document on how to tune MLD best in wireless domains  
and mobile regimes.

[JiK] Would not have these in the first round of goals/documents..
[JiK] Concentrate on the minimum requirements & set of documents (like  
the first two), work on those few documents and output quality specs.  
During the course we will learn what is really needed as for the  
future work and meanwhile we might even get better signals from the  
deployments where the real weak points are that industry needs to have  
fixed.

Recharter or close working group.

On Jun 22, 2009, at 6:06 PM, Behcet Sarikaya wrote:

> <multimobcharter06.txt>_______________________________________________
> multimob mailing list
> [email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 25 Jun 2009 13:15:21 -0700 (PDT)

Hi all,
  Based on Jouni's comments, I modified the charter. Please find it attached to this mail.

Regards,

Behcet

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 25 Jun 2009 21:31:39 +0100

Let's talk about all the various proposals in the Chair's chat tomorrow,

Gorry

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 25 Jun 2009 15:28:49 -0700 (PDT)

Hi Jouni,
  Thanks for your detailed comments and insight on our charter.
  Please see my post on the list. Does it capture everything you wanted to see in Multimob charter?

Regards,

Behcet

----- Original Message ----
> From: jouni korhonen <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, June 25, 2009 4:32:37 AM
> I got few comments. My overall feeling is that this proposed charter just tries 
> to tackle too many things. I would start with the absolute minimal work that is 
> needed to identify/clarify/fix possible issues with (network based) mobility and 
> multicast. Once that is done, re-evaluate and re-charter if necessary (assuming 
> the WG would be formed in the first place).
> 
> Then some more specific comments inline prefixed with [JiK]. I did this based on 
> the "original" charter text and shamelessly bypassed the recent discussion on 
> the mailing list ;)
> 
> Cheers,
>     Jouni
> 
> ----------
> 
> The Multicast mobility (multimob) will develop a set of protocol extensions and 
> provide guidance appropriate for IPv4 and IPv6 multicast in a mobile 
> environment. It will consider both source specific multicast (SSM)  and any 
> source multicast (ASM) multicast models.
> 
> The scope of work will be limited to group management and mobile IP protocols - 
> proxied or client-based. Work requiring modifications of multicast routing 
> protocols (PIM-SM, PIM-DM, etc.) is out of scope. Specific goals are:
> 
> - Provide guidance and specify methods for multi-homing support for multicast.
> 
> [JiK] - Identify and document issues that prevent use of multicast with IETF 
> defined IP mobility protocols
> [JiK] - Provide guidance and base line specification how to deploy multicast 
> [JiK] Scoping could be more strict. For example, scope the first round mobility 
> protocol only to PMIP and listener mobility. Other stuff can be mentioned to be 
> "in future scope".
> 
> 
> Unicast mobility protocols (Mobile IPv6, Dual-Stack Mobile IPv6 and also Mobile 
> IPv4) provide basic multicast support and enable mobile nodes to perform 
> bi-directional tunneling and receive multicast traffic anchored at the home 
> agent. However, such basic support suffers from the 'avalanche' problem as the 
> home agents replicate the packets and unicast them to the mobile nodes as well 
> as from non-optimal, triangular routing, 'remote subscription' suffers from 
> possible loss of data during handovers. The WG will address these issues within 
> the context of Proxy Mobile IPv6 (PMIPv6).
> 
> [JiK] What are "unicast mobility protocol"? The text seems to indicate they 
> actually are client based mobility protocols.
> [JiK] What does "remote subscription" mean? Does it mean a) the MN is roaming in 
> a visited network using telecom terminology, or b) the MN has joined a multicast 
> group that is not available in the visited foreign network, or c) the MN has 
> joined to a multicast group it intends to receive though the IP mobility 
> solution provided means (i.e. forwarded to the MN via the HA/LMA).
> 
> [JiK] Honestly, my original impression was that multimob would concentrate on 
> PMIP6 at the beginning. If it is so, then the charter text should also be more 
> biased towards it. There can be a backdoor in the text to add more stuff after 
> re-chartering, for example saying that the WG will study/evaluate whether client 
> MIP or IGMP/MLD needs more work. The current mixing of both client MIP and proxy 
> MIP issues & descriptions make the charter confusing, and I would assume also 
> Currently PMIPv6 (and mobility extension protocols like  FMIPv6 and HMIPv6) does 
> not  support multicasting explicitly. Basic support for multicast with 
> bi-directional tunneling will be documented for PMIPv6 (with no new message 
> types or  changes to the message parameters). PMIPv6 that handles IPv4 and IPv6 
> will be extended to also support multicasting with IPv4.. Finally, PMIPv6 basic 
> multicast support will be extended to support remote subscription and fast 
> handover.
> 
> [JiK] I agree that current PMIP specification is vague when it comes to handling 
> of multicast and imho that deserves to be clarified/fixed. Imho the paragraph 
> above should not mix FMIP & HMIP with PMIP here, just for clarity and keeping 
> things simple.
> 
> [JiK] I would not propose a solution (e.g. bi-directional tunneling) immediately 
> here in the description text, especially as we are not sure bi-directional 
> tunneling type of solution is even applicable in the context of PMIP and 
> unmodified hosts. Just say "a solution" or extension or deployment guidance is 
> needed.
> 
> 
> environments. IGMPv3/MLDv2 has been specified for wired networks with shared 
> links. Mobile nodes also have other needs (e.g.  entering a dormant mode to 
> conserve battery power, minimising the
> 
> [JiK] Would say multimob will study/evaluate whether extensions to IGMP3/MLDv2 
> are needed for supporting mobile environments.
> 
> latency for joining and leaving a group in support of movement).  The working 
> group will assess existing solutions for group management, and determine if 
> these methods are sufficient. This will include defining best current practice 
> for selection of timer values and protocol parameters. If these methods are not 
> sufficient, the working group shall propose new solutions as updates to
> 
> [JiK] BCP/informational type of guidelines is OK regarding timers and such. Do 
> we actually have operational data on those in wireless/mobile environments?
> 
> existing protocols (including possible introduction of additional message 
> types). It is a goal for the working group to ensure backward compatibility with 
> the current implementations of group management protocols. Message structures 
> supported in current deployed networks will not be modified.
> 
> A multi-homed mobile node may wish to join multicast groups and to direct 
> different multicast flows to its interfaces. The working group will define 
> multi-homing support for multicast, including an efficient per-interface 
> subscription management in the case of multi-homed mobility and multicast flow 
> binding.
> 
> [JiK] I would strongly consider _not_ to include this multihoming topic here. 
> Work on this in Mif or re-charter later.
> 
> 
> In performing this work, the Multimob working group will work closely with 
> NETLMM
> working group and will coordinate work on IGMP/MLD extensions with the MBONED 
> working group.
> 
> GOALS and MILESTONES:
> 
> six months:
> 
> - Submit an informational document explaining the use of multicast in PMIPv6.
> 
> [JiK] Also would like to see a short evaluation document of issues with mobility 
> & multicast. The IRTF I-D type of thing (by Thomas et'al) but probably slightly 
> more compact and written in a way that it could be used to justify exact 
> possible future work topics.. as a tool for re-chartering.
> - Submit a BCP document on how to tune MLD best in wireless domains and mobile 
> regimes.
> 
> [JiK] Concentrate on the minimum requirements & set of documents (like the first 
> two), work on those few documents and output quality specs. During the course we 
> will learn what is really needed as for the future work and meanwhile we might 
> even get better signals from the deployments where the real weak points are that 
> industry needs to have fixed.
> 
>