Subject: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 10 Jun 2011 12:50:03 -0700 (PDT)

Hi Hitoshi,
  While reading Section 3 on explicit tracking, I noticed that no mention of 
IGMP/MLD proxy architecture we have in RFC 6224 was made.

I am curious as to how the explicit tracking can be performed in a proxy 
environment where the router only gets aggregate join messages.

Maybe this section should discuss this issue which is very relevant to us.

Regards,

Behcet

> A New Internet-Draft is available from the on-line Internet-Drafts directories.  
>This draft is a work item of the Multicast Mobility Working Group of the  IETF.
> 
>     Title           :  Tuning the Behavior of IGMP and MLD for Mobile Hosts and  
>Routers
>     Author(s)       : Hitoshi  Asaeda
>                            Hui Liu
>                            Qin Wu
>      Filename        :  draft-ietf-multimob-igmp-mld-tuning-00.txt
>     Pages            : 15
>     Date             : 2011-05-26
> 
>    IGMP and MLD are the protocols  used by hosts to report their IP
>    multicast group memberships to  neighboring multicast routers.  This
>    document describes the ways  of IGMPv3 and MLDv2 protocol optimization
>    for mobility, and aims to  become a guideline for query and other
>    timers tuning.
> 
> 
> A  URL for this Internet-Draft  is:
> http://www.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-00.txt
> 
> Internet-Drafts  are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft  can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-00.txt
> _______________________________________________
> multimob b mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 11 Jun 2011 16:39:56 +0900 (JST)

Hi Behcet,

> environment where the router only gets aggregate join messages.

Above "the router" means MAG acting as IGMP/MLD proxy?
If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD
proxy, which is no difference from the standard IGMP/MLD proxy device
(rfc4605), and hence there is no special explanation for 6224 is
needed in this draft, I think.

Or am I missing something?

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 11 Jun 2011 12:36:55 +0200

Hi Hitoshi,

you're right in the sense that so far IETF work on multicast mobility 
has not produced protocols that are distinct from existing standards. 
According to the charter, we have all concentrated on efficient 
deployment and suitable tuning. This is true for 
draft-ietf-multimob-igmp-mld-tuning-00.txt, as well.

However, I agree with Behcet that - even though it is not normative in 
the sense that standard dependencies are revealed - references and 
discussions should be included to the state of IETF/IRTF work. Questions 
like "how do MLD tuning proposals affect the RFC 6224 base solution?" 
should be asked and answered in your draft.

Further, not only for the benefit of the readers, but also for the sake 
of transparency and conciseness, references and discussions should be 
included to the problem space (RFC5757) and the solution space (RFC6224 
+ existing *original* drafts) as informational pointers.

Currently, the draft does not make any reference to related work on 
multicast mobility/MLD issues (neither within IETF/IRTF nor to the 
outside world). Without these links, it appears the authors are unaware 
of the extensive discussions that happened prior to their work on this 
draft, and statements in the document fall "out of the blue". As is, 
this is a clear quality issue of the document and degrades the visible 
value of Multimob work.

Hence, I would strongly plead for adding discussions and references to 
the core aspects & documents in draft-ietf-multimob-igmp-mld-tuning to 
shift this to WG document standards.

Cheers & best wishes,

Thomas

On 11.06.2011 09:39, Hitoshi Asaeda wrote:
> multimob mailing list

-- 

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: Sun, 12 Jun 2011 02:22:21 +0900 (JST)

Thomas,

... snip ...
> outside world). Without these links, it appears the authors are
> unaware of the extensive discussions that happened prior to their work
> on this draft, and statements in the document fall "out of the
> blue". As is, this is a clear quality issue of the document and
> degrades the visible value of Multimob work.

It seems you start the different talk.

Anyway, let's go back to the original discussion.

In fact, in section 4.4 of the tuning draft, it is mentioned that
tuning the Startup Query Interval contributes to shortening handover
delay for MNs in PMIPv6 domain. This tuning is therefore helpful for
rfc6224.
Currently, section 4.4 refers to rfc5213, but if multimob people
agree, we will change the reference to rfc6224.

If there are other relevant scenarios, please point out. Thanks.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 Jun 2011 07:53:47 -0700 (PDT)

Hi Hitoshi,

> needed in this draft, I think.

Does 4605 talk about explicit tracking?

> Or am I missing  something?

What about if the router is the LMA? 
Of course LMA could be a proxy but we should consider LMA being a router as the 
most likely scenario? It seems to me that in that case explicit tracking will 
simply not work and all the timer tuning recommended. 

Maybe we should state that in the draft.

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Jun 2011 10:46:24 -0700

Hi

>>> environment where the router only gets  aggregate join messages.

You can combine proxying and explicit tracking. If you have say a
topology like this:

       R         router
     /   \
   P1    P2      proxies
   / \    | \
H11 H12 H21 H22 hosts

Then R, P1 and P2 can do explicit tracking in order to restrict
sending of multicast packets, and perform fast leave etc. The point is
to do it at each branching point. R won't be able to track the hosts,
it may only know of P1 and P2, but that is fine.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 21 Jun 2011 10:46:38 -0700

Hi

       R         router
     /   \
   P1    P2      proxies
   / \    | \
H11 H12 H21 H22 hosts

Stig

---

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

Hi Stig,

I'm very sorry for my late response, and thank you for your
explanation.

> it may only know of P1 and P2, but that is fine.

Right.

The explicit tracking function cooperates with IGMP/MLD. So, whether
LMA acts as a router or proxy, if LMA has adjacent downstream
receivers (including IGMP/MLD proxies), it maintains the downstream
membership state (which might be aggregated by downstream IGMP/MLD
proxies), and the explicit tracking function works fine.

BTW, the following draft specifying the explicit tracking function is
now proposed in PIM WG, not MBONED WG.
http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-02
So if some of you want to follow the discussion or support this draft,
please comment in PIM WG.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Jun 2011 09:03:48 -0700 (PDT)

> proxies), and the explicit tracking  function works fine.

We have use cases for explicit tracking both at the router (for Mobile IPv6 
architecture) and at the proxy (for PMIPv6 architecture).
I suggest that you add some text to clarify these two use cases in the draft.
Also those issues that Thomas raised.

Regards,

Behcet