Subject: [MBONED] Comments to draft-asaeda-mboned-explicit-tracking-00

From: <[email-masked]>
Date: Mon, 4 Oct 2010 15:18:09 +0200

Hi,

In addition in support the draft becoming WG  document I do have a few
comments and suggestions in order to enhance the draft (see below).

General comment:
  - IGMP Proxy devices. Many deployments are using IGMP proxies on L2 
    devices or devices which lack full L3 functionality (e.g. only
supporting
    L3 for MC forwarding). Those devices have limited processing
capabilities
    suffering from performance issues in case of a huge number of IGMP 
    membership reports. From a functional point of view the difference
between
    a proxy device and a "real querier" should be big, but from a
practical
    point of view there might be a significant difference (e.g.
performance).
    Therefore I propose to add a short section addressing/mentioning the

    use of IGMP/MLD proxies in combination with explicit tracking (I
think
    the benefit for a  proxy device is higher than for a fully fledged
L3
    device).

Section 3.1.
------------
Depending on the scenario the additional network ressources needed in
case 
of group-/group-source specific queries might not be the main problem.
In 
Typical IPTV deployments network ressources (bandwidth) are usually
plentiful. 
I think an additional problem is the ressource consumption on the IGMP 
Querier (or Proxy) devices itself. Because the querier/proxy has to
process 
all IGMP messages within a relativ short time (depending on the max
response time). 
If a devices has only limited CPU power this behaviour can cause also 
impact on the overall network and service performance. My suggestion is
to 
add something like

"The processing of IGMP Membership reports consumes CPU ressources
 on the IGMP querier devices itself. Thefore the explicit tracking
function 
 reduces not only the network load but also the CPU load on the querier
devices 
 as well. "

to the draft.

Section 3.3.
------------
Certain scenarios assume that it is not necessary to set an IP address
to
an interface, if the interface only uses Multicast but no unicast
(Multicast
specific service VLAN). This could be added to the considerations
section.

Section 5
---------
I would expect that the membership database will be updated based on the
general queries.

Kind regards
Nicolai Leymann

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 4 Oct 2010 19:07:24 -0700

>     the benefit for a  proxy device is higher than for a fully fledged

I thought about this as well, but i wonder about the *sigh* process
implications when we start to include snooping devices. Remember that
IGMP snooping is only informational and not standards track. IGMP proxy
routing on the other hand is standards track. I think it would be great if
we could drive explicit tracking for immediate leave on routers
to standards track.  I fear we can not do this if we define it for both
routing and snooping in the same document. We may have to duplicate the 
work into two documents again *sigh*. Of course it would be easier if
we could somehow do it in a single document. Maybe via a non-normative
appendix mentioning the same functionality for IGMP/MLD snooping switches ?

This question becomes IMHO even more funny if we consider whether/how a
router side explicit tracking implementation could/should reduce
queries based on whether or not snooping switches are present that
do not support explicit tracking. I leave that up as an exercise to the
reader ;-))

Cheers
    Toerless

---

From: <[email-masked]>
Date: Wed, 6 Oct 2010 16:33:33 +0200

Hi Toerless, 

> to standards track.  
Agree.

> I fear we can not do this if we define it for both
Right; from what I understand "IGMP/MLD Proxying" (RFC4605) is standards

track. Therefor there should be possible to include a section addressing
explicit tracking implications for devices doing IGMP proxy. Including
devices
which are also doing IGMP snooping in addition might be a differenc
exercise.

  Regards

     Nic

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 6 Oct 2010 08:21:58 -0700

Thanks. 

Btw: The hope to apply explicit tracking for standards would be
both for IGMP proxying routers and PIM/IGMP routers. Just for snooping
switches we may need to be careful i fear. I just mentioned only
IGMP proxy routing vs. snooping tomake the point.

Cheers
    Toerless

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 25 Oct 2010 23:39:50 +0900 (JST)

Hi Nic,

Sorry for late response.

> Section 3.1.

Thanks, I add some text in the revised draft.

> Section 3.3.

IGMPv3 routers accept a report with a source address of 0.0.0.0, while 
MLDv2 routers do not accept unspecified address and invalid link-local
addr as the listerner address.
I follow these specs.

> I would expect that the membership database will be updated based on the

Yes.
The current draft already descrives;
   When a multicast router receives a Current-State or State-Change
   Report message, it adds the receiver IP address to or delete from the
   receiver records or creates the corresponding membership state
   information.
Above current-state report implies the response of general query.

Thanks,
--
Hitoshi Asaeda