Subject: [multimob] Proposal for a work item agenda

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 09 May 2009 14:36:45 +0200

Hi all,

as discussed yesterday on the teleconference, a proposal for a work item 
agenda has been worked out.

And here it is:

   Proposal for Multimob roadmap

  1. MLD over Wireless: BCP document on deployment of RFC 2710 and RFC 3810
     with configurations optimized for wireless.

  2. MLD extensions for enhanced mobile multicast services: Experimental /
     standards track document on additional MLD functions that improve 
multicast
     in the mobile regime (e.g., listener hold, etc.).

  3. Multicast listener deployment for multihomed mobile nodes: BCP 
document on
     multicast operations in the presence of multihoming

  4. Multicast listener deployment in PMIPv6: BCP document to describe 
minimal
     deployment for PMIPv6 remote subscription.

  5. Multicast listener optimizations in PMIPv6 (+ extensions) domains:
     Experimental / standards track document on additional multicast +
     mobility functions for traffic optimization in PMIPv6 and emerging
     extensions.

  6. Multicast listener extensions for MIPv6 Fast Handovers:  Experimental
     / standards track document on multicast extensions in FMIPv6.

  7. Multicast listener extensions for Hierarchical MIPv6:  Experimental
     / standards track document on multicast extensions in HMIPv6.

  8. Transparent multicast transmission from mobile nodes: Experimental
     / standards track document for a basic mobile multicast sender 
support.

As we want to converge rapidly to meet BoF deadlines, please comment 
sprightly :-)

Best wishes from sunny Europe,

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: 陈刚 <[email-masked]>
Date: Sun, 10 May 2009 22:51:13 +0800

Dear all,

I want to clarify one thing in work item agenda.
With regard to No.6, it should be PMIPv6 Fast handover, other than MIPv6
fast handover.
Thanks.

Chen Gang
China Mobile

2009/5/9 Thomas C. Schmidt <[email-masked]>

>  3. Multicast listener deployment for multihomed mobile nodes: BCP document
> on
>    / standards track document for a basic mobile multicast sender support.
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

-- 
陈刚
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 11 May 2009 00:59:55 +0900 (JST)

Hi,

>      with configurations optimized for wireless.

RFC2710 is not explicitly obsolete, but currently no necessary to
adapt any spec mentioned in rfc2710. Hence I recommend to describe,
"... deployment of RFC3810 with ..." or "... deployment of MLDv2 (or
LW-MLDv2) with ...".

>   4. Multicast listener deployment in PMIPv6: BCP document to describe minimal

What is the major difference between 4 and 5?
5 includes "local subscription" but 4 does not?
What is the minimal deployment you expexted?

Anyway, PBU with multicast extension and/or CT extension is necessary
even with remote subscription.
Although I need to know the conditon of the minimal deployment
described in 4, in my current thought, dividing 4 and 5 is not very
useful.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 10 May 2009 18:28:51 +0200

Hi Chen,

> With regard to No.6, it should be PMIPv6 Fast handover, other than MIPv6 

I would not see a reason why FMIPv6 / PMIPv6 should be mutually
exclusive. One might want to add Fast PMIPv6, but I guess there is point
in taking FMIPv6 off the agenda.

Best regards,

Thomas

> 2009/5/9 Thomas C. Schmidt <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Hi all,
> 
>     as discussed yesterday on the teleconference, a proposal for a work
>     item agenda has been worked out.
> 
>     And here it is:
> 
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
> 
> ------------------------------------------------------------------------
> 

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 10 May 2009 19:15:44 +0200

Hi Hitoshi,

> "... deployment of RFC3810 with ..." or "... deployment of MLDv2 (or

Personally, I'm not a friend to restrict views to SSM unless there is a 
convincing need for it. Currently, we have quite a number of ASM-based 
IPTV deployments in Europe. So I'd like to argue that MLDv1 aspects 
should be addressed up to the point at which source-specific 
restrictions become vital. (Currently I don't see many of those).

> What is the minimal deployment you expexted?

This is meant as a simple formal division, at first: 4. is a BCP, thus 
giving a use / deployment guide of combining solutions standardized 
elsewhere. In the current model, this will lead to easy, but somewhat 
inefficient point-to-point transmissions.

5. would address real protocol extensions and be open for additional 
PMIP work as expected from NETEXP or so.

The division is intended to produce a document at first, that is not 
endangered in tampering with PMIPv6 protocol operations (which appear 
somewhat counter-intuitive for group communication). It would be easier 
to complete, as well.

Best regards,

Thomas

--

---

From: 陈刚 <[email-masked]>
Date: Mon, 11 May 2009 10:30:14 +0800

Hi Thomas,

There is not intention to take FMIPv6 off the agenda.

I want to clarify information I have mentioned during the teleconference
last week, because we are preparing draft related to FPMIPv6 for 75th IETF.

We can put both FMIPv6/FPMIPv6 into agenda, if you think that is necessary.

BRs

Chen Gang

2009/5/11 Thomas C. Schmidt <[email-masked]>

-- 
陈刚
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 11 May 2009 12:52:30 +0900 (JST)

Thomas,

> Personally, I'm not a friend to restrict views to SSM unless there
> is a convincing need for it. Currently, we have quite a
> number of ASM-based IPTV deployments in Europe. So I'd like
> to argue that MLDv1 aspects should be addressed up to the
> point at which source-specific restrictions become
> vital. (Currently I don't see many of those).

MLDv2 supprots both ASM and SSM. No necessity to explicitly focus on
MLDv1 anymore.

> This is meant as a simple formal division, at first: 4. is a BCP,
> thus giving a use / deployment guide of combining solutions
> standardized elsewhere. In the current model, this will lead
> to easy, but somewhat inefficient point-to-point
> transmissions.

If we need to describe such issues or situations, the draft should be
explicitly categorized as "problem statement" or "requirement" draft.
And if it just takes a role of some "guidance", it should be intended
as informational RFC.

> PMIP work as expected from NETEXP or so.

??
Is there any aspect to give some task to NETEXT for multicast support?
(I assume s/NETEXP/NETEXT.)
Does this multimob group tend to PMIP extension for multicast support?

> endangered in tampering with PMIPv6 protocol operations (which
> appear somewhat counter-intuitive for group communication). It would
> be easier to complete, as well.

If our target is to support pure *IP multicast" in PMIP domain,
protocol modification is definitely needed.

People may say that IP multicast services have already provided in
their PMIP domains. I expect their services wouldn't be only with IP
multicast, but with a multicast service implementation by some
architectural modification or configuration.
If describing such *service* implementation (which would be without
any protocol modification), you must explicitly say so and should not
include remote subscription or some common words in the text.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 11 May 2009 14:38:52 +0900 (JST)

> Does this multimob group tend to PMIP extension for multicast support?

I mean, I think this multimob group has the mission to take care of
any PMIP extension for multicast support, while NETEXT won't.
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 May 2009 13:57:49 -0700 (PDT)

Hello all,
  This proposal will be discussed in Thursday's call. Please post your opinion especially if you are not attending the call.

Regards,

Behcet

________________________________
From: Thomas C. Schmidt <[email-masked]>
To: [email-masked]
Sent: Saturday, May 9, 2009 7:36:45 AM
Subject: [multimob] Proposal for a work item agenda

Hi all,

as discussed yesterday on the teleconference, a proposal for a work item agenda has been worked out.

And here it is:

2. MLD extensions for enhanced mobile multicast services: Experimental /
    standards track document on additional MLD functions that improve multicast
    in the mobile regime (e..g., listener hold, etc.).

3. Multicast listener deployment for multihomed mobile nodes: BCP document on
    multicast operations in the presence of multihoming

As we want to converge rapidly to meet BoF deadlines, please comment sprightly :-)

Thomas

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 12 May 2009 21:08:45 +0100

Looks good Thomas!

  - I could help with 1,2 (and have notes pending that I should type up 
soon).

- I am not sure I understand 3 yet.

- Can someone remind me how these relate to current drafts?

Gorry

Behcet Sarikaya wrote:
> Hello all,
>   This proposal will be discussed in Thursday's call. Please post your 
> opinion especially if you are not attending the call.
> Regards,
>  
> Behcet
> *From:* Thomas C. Schmidt <[email-masked]>
> *To:* [email-masked]
> *Sent:* Saturday, May 9, 2009 7:36:45 AM
> *Subject:* [multimob] Proposal for a work item agenda
> 
> Hi all,
> 
>     in the mobile regime (e.g., listener hold, etc..).
>

---

From: <[email-masked]>
Date: Wed, 13 May 2009 12:02:52 +0200

Hi all,

I agree with this list of items, it would give more consistence to Multimob. Just one question:

It is proposed Multicast listener optimizations in PMIP. However, some of the current solution drafts are proposing extensions to PMIP, is it out of scope of the proposed item?

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Thomas C. Schmidt
> Envoyé : samedi 9 mai 2009 14:37
> À : [email-masked]
> Objet : [multimob] Proposal for a work item agenda
> 
> Hi all,
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 13 May 2009 12:10:19 +0200

Thanks Pierrick,

> It is proposed Multicast listener optimizations in PMIP. However, some of the current solution drafts are proposing extensions to PMIP, is it out of scope of the proposed item?
No, it was the idea to separate this in 4 and 5. The thought behind this 
suggestion is the following:

A BCP regarding "how to use multicast with the existing PMIPv6 best" is 
a document that is easy to produce and progress. So this could be a 
fast, helpful result to the community.

Extension to PMIP, either proposed by the PMIP community or by Multimob, 
are more intricate and probably require longer discussions and 
coordination.

That's why the list suggests to do stuff in separate steps.

Best regards,

Thomas

--

---

From: Liu Hui <[email-masked]>
Date: Thu, 14 May 2009 10:39:55 +0800

Hi,

My understanding towards multicast mobility (as the group name "multimob"
shown)  are:

- The receiver mobility (i.e the source and network are not moving) should
be considered with some priority because it has more specific requirements,
less deployment cost and lest effect on current fixed multicast achitercure.
Other senarios should also not be excluded if there is application prototype
and practical solution. 

- The multicast mobility should not be restricted to one or two mobile IP
protocol, unless there is clear decision in industry that these one or two
mobile IP protocols will be definitely used while others will not.  Thus the
mainstream mobile IP protocols will be in the scope (e.g MIP,PMIP, even FMIP
)  while possibly with priority orders;

- The network type should include both IPv4 and IPv6 networks.  The reason
is that currently IPv4 network is widely used while IPv6 network hasn't seen
its scale deployment.  It is possible for IPv4 network to support mobile
multicast service .

- Handover will be payed special consideration because it has direct
performace effect on the multicast service delivery.

- The extension of any protocol is possible.  But it is encouraged that they
should be beneficial while not introduce obvious complexity and
interoperability issues and should not confuse original mobile and multicast
architectures.

- And for the solutions under the multicast mobility architecture the
*practicability* should be emphisized because it is highly regarded at IETF.

For the items Thomas listed below, I suggest IPv4 network and MIP protocol
should also be included in the scope with the reasons given above.  Other
 
>      with configurations optimized for wireless.

IMHO, apart from wirless optimization, optimization for *mobility* may also
be considered unless "wireless" is equivalent to "mobility" 

>      multicast operations in the presence of multihoming> 
>      mobility functions for traffic optimization in PMIPv6 
> and emerging extensions. 
>      / standards track document on multicast extensions in FMIPv6.> 
>      / standards track document on multicast extensions in HMIPv6.> 

For item 3 and 4  "multicast listener deployment" is not quite clear in
meaning.  For IP multicast, *multicast listener* is only defined and used in
MLD protocol.  Does this phrase mean MLD deployment?  If does, MLD protocol
should be definitely pointed out, otherwise more precise expression should
be used.  It is same for "Multicast listener optimizations" and "Multicast
listener extensions" in the following items.

Best Regards,

Liu Hui

---

From: <[email-masked]>
Date: Thu, 14 May 2009 11:27:22 +0200

Dear all,
I agree that it is important to emphasize first that a multicast support is feasable also for PMIPv6 as this will be deployed by several mobile operators (following 3GPP/3PGG2 and WiMAX standards). The approach to set up a BCP document should be beneficial for this.

While covering generally all existing MIP solutions and all scenarios we then should start with priority for
- listeners
- performance optimization in terms of low HO loss and delay, route optimization and control effort reduction 

With regard to the complete list of topics (and e.g. multi-homing): Do we really need a draft for each issue for the BoF?

Best regards
Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Liu Hui
Gesendet: Donnerstag, 14. Mai 2009 04:40
An: 'Thomas C. Schmidt'; [email-masked]
Betreff: Re: [multimob] Proposal for a work item agenda

Hi,

 

Best Regards,

Liu Hui

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 14 May 2009 11:18:23 +0100

As you suggest, it seems OK to me to have some work items less mature - 
A talk by someone who wants to use the documents to build real networks 
is the next best thing to a draft - a promise of a "future" draft by an 
individual is OK, but less impressive ... These items could even be 
within the scope of the *Charter*, but not assigned a milestone.

I can't speak for the BoF organisers, but generally the most important 
thing is to show there are PEOPLE willing to write sections of the key 
documents, and that there are more people willing to review the 
documents - it is especially good if a group of these people represent 
implementors and operators (these are ideal people to SAY the work is 
needed). It is normally necessary to have a good set of drafts that get 
this sort of support.

Is IPv4 multicast to be in or out of scope???? - If so, how do we handle 
this?

Gorry

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 14 May 2009 13:45:01 +0200

Hi Gorry,

  agree ... as far as I know, IPv4 is out of scope, which is probably 
fine, otherwise it would be two chaotic.

Best 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

On Thu, 14 May 2009, Gorry Fairhurst wrote:

> 
> As you suggest, it seems OK to me to have some work items less mature - A talk
> by someone who wants to use the documents to build real networks is the next
> best thing to a draft - a promise of a "future" draft by an individual is OK,
> but less impressive ... These items could even be within the scope of the
> *Charter*, but not assigned a milestone.
> 
> I can't speak for the BoF organisers, but generally the most important thing
> is to show there are PEOPLE willing to write sections of the key documents,
> and that there are more people willing to review the documents - it is
> especially good if a group of these people represent implementors and
> operators (these are ideal people to SAY the work is needed). It is normally
> necessary to have a good set of drafts that get this sort of support.
> 
> 
> Is IPv4 multicast to be in or out of scope???? - If so, how do we handle this?
> 
> Gorry
> 
> 
> > I agree that it is important to emphasize first that a multicast support is
> > feasable also for PMIPv6 as this will be deployed by several mobile
> > operators (following 3GPP/3PGG2 and WiMAX standards). The approach to set up
> > a BCP document should be beneficial for this.
> > 
> > - performance optimization in terms of low HO loss and delay, route
> > optimization and control effort reduction 
> > With regard to the complete list of topics (and e.g. multi-homing): Do we
> > really need a draft for each issue for the BoF?
> > 
> > Best regards
> > Dirk
> > 
> > >      in the mobile regime (e.g., listener hold, etc.).   3. Multicast
> > > listener deployment for multihomed mobile nodes: BCP document on
> > >      multicast operations in the presence of multihoming>   4. Multicast
> > > listener deployment in PMIPv6: BCP document to describe minimal
> > >      deployment for PMIPv6 remote subscription.   5. Multicast listener
> > > optimizations in PMIPv6 (+ extensions) domains:
> > > extensions.   6. Multicast listener extensions for MIPv6 Fast Handovers:
> > > Experimental
> > >      / standards track document on multicast extensions in FMIPv6.>   7.
> > > Multicast listener extensions for Hierarchical MIPv6:  Experimental
> > >      / standards track document on multicast extensions in HMIPv6.>   8.
> > > Transparent multicast transmission from mobile nodes: Experimental