Subject: [multimob] Multicast deployment in PMIPv6

From: Brian Haberman <[email-masked]>
Date: Mon, 08 Dec 2008 15:07:51 -0500

All,
      As I mentioned in an earlier message, one of the takeaways from 
the BoF is that there is some confusion of how multicast can be deployed 
in the current PMIPv6 architecture.  Some people argued that multicast 
in PMIPv6 already exists using the base MIPv6 protocol.  Others argued 
that either the MIPv6 multicast extensions can't be used or that they 
were insufficient.

      From those arguments, I would see a work item being the 
investigation of what the baseline deployment of multicast in PMIPv6 
would look like.  This would preclude (for the time being) optimizations 
such as different approaches to supporting LMA to MAG multicast transit. 
  I view this task as requiring a tight involvement with the NETLMM 
working group in order to ensure complete understanding of their 
evolving PMIPv6 specification.

      Thoughts?  Comments?

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Dec 2008 12:22:59 -0800 (PST)

Brian, I suggest combining this thread with Suresh's idea of coming up with a description of the intended deployment model(s) for multicast with PMIP.

A quick draft could help stimulate the discussions and I am hoping that Suresh will do something .

Regards,

Behcet

________________________________
From: Brian Haberman <[email-masked]>
To: [email-masked]
Sent: Monday, December 8, 2008 2:07:51 PM
Subject: [multimob] Multicast deployment in PMIPv6

All,
     As I mentioned in an earlier message, one of the takeaways from the BoF is that there is some confusion of how multicast can be deployed in the current PMIPv6 architecture.  Some people argued that multicast in PMIPv6 already exists using the base MIPv6 protocol.  Others argued that either the MIPv6 multicast extensions can't be used or that they were insufficient.

     From those arguments, I would see a work item being the investigation of what the baseline deployment of multicast in PMIPv6 would look like.  This would preclude (for the time being) optimizations such as different approaches to supporting LMA to MAG multicast transit.  I view this task as requiring a tight involvement with the NETLMM working group in order to ensure complete understanding of their evolving PMIPv6 specification.

     Thoughts?  Comments?

Regards,
Brian

---

From: "john.zhao" <[email-masked]>
Date: Tue, 09 Dec 2008 14:51:08 +0800

Hi,Brian and all
	IMHO, what is the scope of the discussion about the deployment is
needed to be defined or suggested. Without the comparison of the solution
between multicast with MIPv6 or PMIPv6, how to decide if it need to be done
again? I remember this kind of discussion has been already existed in Dublin
. So my suggestion is a assumption is very important and can be treated as
our startup point for next step. So what is our current common idea? None or
something? And in which scope and level , the deployment should be
discussed?

	Best Rgds,
Thanks

John.zhao

-----邮件原件-----
All,

      Thoughts?  Comments?

Regards,
Brian

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 11 Dec 2008 00:54:32 +0900 (JST)

>       As I mentioned in an earlier message, one of the takeaways
> from the BoF is that there is some confusion of how multicast can be
> deployed in the current PMIPv6 architecture.  Some people argued
> that multicast in PMIPv6 already exists using the base MIPv6
> protocol.  Others argued that either the MIPv6 multicast extensions
> can't be used or that they were insufficient.

I suppose their solutions are "home subscription only".
It is possible to give multicast services in PMIPv6-domain without any
protocol modification or special configuration, especially in home
subscription only PMIPv6-domain. But whether home subscription or
remote subscription is adopted, multicast protocol modification or
special configuration will be required for "effective" communication,
such as effective network resource use, effective (smooth/seamless)
handover, effective traffic or quality control, and so on.

For instance, the same multicast data may be replicated on LMA and
unicasted multiple times (for individual MNs) over an LMA-MAG
bi-directional tunnel if PMIPv6 adopts home subscription only
configuration. This unwilling situation can be avoided if MAG is
configured as a multicast router or MLD proxy. But if MAG is
configured as a multicast router or MLD proxy, how LMA can be
configured and interoperate with MAG effectively (i.e. low traffic
cost but high convergence)?
And in what kind of situation or requirement MAG should work as a
router, not an MLD proxy? What is the benefit for each? In either
case, how MAG can support MNs' movement with smooth handover?

I believe these considerations and clarifications necessary. To obtain
much consensus for the work, creating a problem statement document
is the first step. After the problem statement clarification, the
requirement statements become much feasible, and people understand the
discussion about protocol extension or tuning is necessary.

> would look like.  This would preclude (for the time being)
> optimizations such as different approaches to supporting LMA to MAG
> multicast transit.

I don't know whether we should start discussion from the baseline
deployment.
The important steps are that we provide scenarios to enable multicast
routing functions in PMIPv6-domain (from protocol-oriented
perspective), clarify PS and requirements, and consider effective
solutions including special configurations and protocol extensions if
needed.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Dec 2008 13:26:08 -0800 (PST)

________________________________
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Sent: Wednesday, December 10, 2008 9:54:32 AM
Subject: Re: [multimob] Multicast deployment in PMIPv6

[behcet] The considerations you mentioned are all described in Thomas' draft and even more.
In the past Suresh and I attempted to write a PS draft. Later on it became evident that there was no need.
Jari told us that we can take draft-irtf-mobopts-mmcastv6-ps as PS draft and there is no need to write another PS draft.

Please take a look at Multimob BoF agenda at http://www.ietf.org/proceedings/08nov/agenda/multimob.html, it is clearly shown that that PS draft is draft-irtf-mobopts-mmcastv6-ps-04.txt. 

We did not emphasize this strongly enough at the BoF, I guess.
Or no matter what we did, there would be some people to question the PS.

Regards, 

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 11 Dec 2008 10:39:45 +0900 (JST)

> Jari told us that we can take draft-irtf-mobopts-mmcastv6-ps as PS
> draft and there is no need to write another PS draft. 
> 

Ok, so I'm more curious why no good consensus for the working items?
Am I missing something?
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob