Subject: [multimob] FW: WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04

From: "Seil Jeon" <[email-masked]>
Date: Mon, 22 Feb 2010 15:10:24 +0900

As I revealed my opinion, I am for ADOPTING this draft.

But I have some questions for this draft.

1. aggregated join could reduce redundant MLD signal but earlier arrived node should wait for aggregating periodic time.

So, it can lead to handover latency. MLD signaling would be trivial compared to redundant multicast traffic.

2. "On the occurrence of a mobility handover, the LMA will receive
   Binding Lifetime De-Registrations and Binding Lifetime Extensions
   that will cause a re-mapping of home network prefixes to Proxy-CoAs
   in its Binding Cache.  Correspondingly, the multicast forwarding
   states require updating, as well.  In the absence of explicit
   tracking, the LMA MUST proceed as follows"

But, how LMA can know these event of MNs? LMA uses link-local address and performs MN-specific management?

IMHO, if it is true, multicast router (LMA) performs not group member management but group management.

how can it be?

And link-local address can be identified for MN in LMA? because a LMA has a lot of MAGs that consists of each link-local.

Best your regards,

Seil Jeon

-----Original Message-----
From: Seil Jeon [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2010 11:59 AM
To: 'Behcet Sarikaya'
Cc: [email-masked]'
Subject: RE: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04

Dear all,

I think that this draft is in accordance with this charter among tunneling mode approach.

I am for ADOPTING this draft.

Best Regards,

Seil Jeon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, February 09, 2010 6:23 AM
To: [email-masked]
Subject: [multimob] WG Adoption call ondraft-schmidt-multimob-pmipv6-mcast-deployment-04

This mail starts a WG adoption call on this draft.

The intended status for this document is BCP.
If adopted, the draft will be named:

draft-ietf-multimob-pmipv6-base-solution.

Please respond if you are for ADOPTING or

you are NOT for ADOPTING it by February 21, 2010.

Regards,

Behcet

----- Forwarded Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: [email-masked]
> Sent: Mon, February 8, 2010 3:02:03 PM
> Subject: [multimob] [Fwd: New Version Notification for 
> draft-schmidt-multimob-pmipv6-mcast-deployment-04]
> 
> Hi,
> 
> we have submitted a revised version of the PMIPv6 deployment draft.
> This version includes all contributions from the extensive and 
> fruitful discussions since the last update in December.
> 
> From the Change Log
> 
>   The following changes have been made from
>   draft-schmidt-multimob-pmipv6-mcast-deployment-03.
> 
>   1.  Detailed outline of multicast reconfiguration steps on handovers
>       added in protocol overview (section 3).
> 
>   2.  Clarified the details of proxy operations at the MAG along with
>       the expected features of IGMP/MLD Proxy implementations (section
>       4.2).
> 
>   3.  Clarified querying in dual-stack scenarios (section 4.4).
> 
>   4.  Subsection added on the special case, where multicast is
>       available throughout the access network (section 4.5).
> 
>   5.  Appendix on IGMP/MLD behaviour added with test reports on 
> current
>       Proxy implementations.
> 
> 
> We now believe the approach has been thoroughly discussed and the 
> document is mature enough to be considered as a WG item.
> 
> Best wishes,
> 
> Thomas
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-schmidt-multimob-pmipv6-mcast-deployment-04
> Date: Mon,  8 Feb 2010 12:53:11 -0800 (PST)
> From: IETF I-D Submission Tool
> To: [email-masked]
> CC: 
> [email-masked],[email-masked],suresh.krishnan@eric
> sson.com
> 
> 
> A new version of I-D,
> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been successfuly submitted by Thomas Schmidt and posted to the IETF repository.
> 
> Filename:    draft-schmidt-multimob-pmipv6-mcast-deployment
> Revision:    04
> Title:        A Minimal Deployment Option for Multicast Listeners in
> PMIPv6 Domains
> Creation_date:    2010-02-08
> WG ID:        Independent Submission
> Number_of_pages: 19
> 
> Abstract:
> This document describes deployment options for activating multicast 
> listener functions in Proxy Mobile IPv6 domains without modifying 
> mobility and multicast protocol standards.  Similar to Home Agents in 
> Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast 
> subscription anchor points, while Mobile Access Gateways provide MLD 
> proxy functions.  In this scenario, Mobile Nodes remain agnostic of 
> multicast mobility operations.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> --
> 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 °
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 22 Feb 2010 11:48:40 +0100

Dear Seil,

thanks for your comments. Please see inline:

> So, it can lead to handover latency. MLD signaling would be trivial compared to redundant multicast traffic.

The aggregation on an MLD proxy is equivalent to the local maintenance 
of its membership database. This comes basically at no delay. The delays 
on handover experienced by the first node that arrives for a given group 
(first subscriber) are composed of

  1. Unicast handover management, unicast address(prefix) configuration ...
  2. MLD query by MAG (MLD proxy)
  3. MLD report from MAG to LMA (LMA already is subscribed to the 
multicast group)
  4. Traffic forwarding from LMA to MN.

Steps 1 and 2 can partly be operated in parallel.

> But, how LMA can know these event of MNs? LMA uses link-local address and performs MN-specific management?

The steps you point at here are part of the unicast handover - this 
section of the draft just tries to generate coherence with RFC 5213.

> And link-local address can be identified for MN in LMA? because a LMA has a lot of MAGs that consists of each link-local.

Group members as seen by the LMA are MAGs (the proxies that aggregate 
MNs). Is it that what you are pointing at?

Best regard

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: "Seil Jeon" <[email-masked]>
Date: Mon, 22 Feb 2010 22:14:31 +0900

Dear Thomas,

My response is as follows. Please see this mark "=>"

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Monday, February 22, 2010 7:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: FW: [multimob] WG Adoption call ondraft-schmidt-multimob-
pmipv6-mcast-deployment-04

Dear Seil,

Seil Jeon wrote:
> 1. aggregated join could reduce redundant MLD signal but earlier arrived
node should wait for aggregating periodic time.
> So, it can lead to handover latency. MLD signaling would be trivial
compared to redundant multicast traffic.

The aggregation on an MLD proxy is equivalent to the local maintenance of
its membership database. This comes basically at no delay. The delays on
handover experienced by the first node that arrives for a given group
(first subscriber) are composed of

  1. Unicast handover management, unicast address(prefix) configuration ...
  2. MLD query by MAG (MLD proxy)
  3. MLD report from MAG to LMA (LMA already is subscribed to the multicast
group)
  4. Traffic forwarding from LMA to MN.

=> Thank you for detailed description but I didn't point out it.

In your handover scenario in Figure 2, there are two MNs (MN1, MN2).

When there is no "G" channel multicast stream from LMA, the MN1 arrived
earlier than MN2 in MAG1, 

but the MN1 sended "join (G)" message to the MAG1 but MAG1 directly do not
send the "join (G)" message 

to the LMA because the MAG performs "aggregated Join" report process

In that case, I mentioned that handover latency may happen.

> But, how LMA can know these event of MNs? LMA uses link-local address and
performs MN-specific management?

The steps you point at here are part of the unicast handover - this section
of the draft just tries to generate coherence with RFC 5213.

=> Yes, of course. I did not intend the question.

My question is, when a LMA receives the de-registration message from MAG
for specific MN,

how can LMA know whether this MN is last node belong to specific multicast
group or not?

Now I can understand through next paragraph.

> And link-local address can be identified for MN in LMA? because a LMA has
a lot of MAGs that consists of each link-local.

Group members as seen by the LMA are MAGs (the proxies that aggregate MNs).
Is it that what you are pointing at?

=> My question is whether link-local address is used for maintaining
multicast group?

Because a link-local address is not unique identifier.

Best regard

Seil Jeon

> Subject: RE: [multimob] WG Adoption call 
> ondraft-schmidt-multimob-pmipv6-mcast-deployment-04
> 
> 
> Dear all,
> 
> Subject: [multimob] WG Adoption call 
> ondraft-schmidt-multimob-pmipv6-mcast-deployment-04
> 
>> draft-schmidt-multimob-pmipv6-mcast-deployment-04.txt has been
successfuly submitted by Thomas Schmidt and posted to the IETF repository.

-- 

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: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 22 Feb 2010 16:45:48 +0100

Dear Seil,

please see my comments marked with  Thomas>>

> earlier than MN2 in MAG1, 

Thomas>> This seems like a misunderstanding. In Fig., MN2 moves from
MAG1 to MAG2, but MN1 stays with MAG1.

> In that case, I mentioned that handover latency may happen.

Thomas>> Each MAG sends a join to its upstream interface, whenever a
first join for G is received on one of its downstream interfaces. As
mentioned, the aggregation will not cause a dedicated latency apart from
the normal signaling delay.

> how can LMA know whether this MN is last node belong to specific multicast

Thomas>> Unicast deregistration will not cause multicast group leaves.
Multicast group management is done via the proxies, so LMA will hear a
Done Report from the MAG after the last MN has left.

> Because a link-local address is not unique identifier.

Thomas>> As said before, the LMA will not keep record of MN-specific
multicast states. It will only know about forwarding states per LMA-MAG
tunnel as learned from the MAGs / Multicast Proxies.

Does this answer your question?

Best regards,

Thomas

--