Hi,

> Some of the issues you're addressing with this can also be encountered
> in highly scaled host networks, I'm thinking 10000+ hosts on a single
> link.  To give an example, in such cases a single query from the
> router will trigger 10 thousands of reports, the router could adapt
> his response delay according to the number of hosts, thus avoiding any
> queue overflows and message drops.
> 
> I was wondering whether you ever considered broadening the scope of
> this draft beyond mobility?

There are several ways to escape from the issue you raised up.

1. Disperse solicited report messages by tuning max resp code
   MLDv2 (rfc3810) query message specifies the max resp code, which
   allows the exponential values if you prefer to set it up longer
   than 32.768 sec. The longer you set it up, the more solicited
   report messages triggered by a single General query are dispersed.
   This tuning is very easy and can be done without any protocol
   modification, but the longer max resp code takes longer convergence
   for membership information and leads longer leave latency.
   This is written in rfc6636.

2. Reduce the number of unsolicited report messages by enabling the
   explicit tracking function
   The number of solicited report messages triggered by Specific query
   can be also reduced, if you turn on "the explicit tracking
   function" on leaf routers. This is because the router enabling that
   function can expect the existence of the last member whenever it
   receives a leave message and hence no need to confirm by sending
   Specific query.
   This function is not clearly defined in rfc3810, but recent
   routers may already support it.
   As the specification, it is written in the following I-D;
   http://tools.ietf.org/id/draft-ietf-pim-explicit-tracking-01.txt

3. Control solicited report message transmission by unicasting General
   query
   When a multicast router enables the above explicit tracking
   function, it is possible for the router to track the membership
   status for each member host by unicasting General query. This
   contributes to reduction of flooding General query messages on a
   link, and hence reduces the network resource and the CPU usage of
   hosts.
   However, as written in Appendix A of rfc6636, this would require
   IGMP/MLD protocol extension.

Hope this helps.

Regards,
--
Hitoshi Asaeda
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob

Reply via email to