Subject: [magma] Re: Last Call: draft-ietf-magma-mgmd-mib (Multicast Group Membership Discovery MIB) to Proposed Standard

From: Stig Venaas <[email-masked]>
Date: Sun, 02 Sep 2007 19:14:03 +0200

I've had a quick read through the draft and think I found some issues.
The last one is possibly me just revealing my lack of MIB clue though.

For all definitions using the InetAddress and InetAddressType syntaxes
a size of 4|16 is specified. This is of course only correct for the
former syntax.

For mgmdHostInterfaceQuerier it should perhaps be specified what it
should be when there is no known querier?

Regarding mgmdHostCacheLastReporter. Not sure what this should be for a
host. The draft says:

             "The IP address of the source of the last membership report
             received for this IP Multicast group address on this
             interface.  If no membership report has been received, this
             object has a value of 0. The InetAddressType, e.g.
             IPv4 or IPv6, is identified by the mgmdHostCacheAddressType
             variable in the mgmdHostCache table."

This sounds reasonable for a router, but not so sure about a host.
Depending on what versions of IGMP/MLD it might be that a host sees a
report from another host, is that what this is for? I don't think hosts
are supposed to track this though.

Then I found something I've never seen before, but I'm a MIB novice. It
says:

MgmdRouterInverseCacheEntry ::= SEQUENCE {
     mgmdRouterInterfaceIfIndex            InterfaceIndex,
     mgmdRouterCacheAddressType            InetAddressType,
     mgmdRouterCacheAddress                InetAddress
}

(well, there is also the index definition prior to this). Is this kind
of referencing really ok? Is it implicit that these are
{ MgmdRouterInverseCacheEntry 1}
{ MgmdRouterInverseCacheEntry 2}
{ MgmdRouterInverseCacheEntry 3}
?

There might be something fundamental I don't know about MIBs here.

Stig

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

---

From: Princy Elizabeth <[email-masked]>
Date: Mon, 17 Sep 2007 22:07:34 -0700 (PDT)

Hi,
   
  I had a question regarding the expected router behavior during the last member query timeout(LMQT) period. Consider 2 IGMPv3 hosts, H1 and H2 sitting on a LAN. Both have subscribed to a group G1. Host H1 now sends a leave for the group G1. On receiving this the querier would reduce its GMI to LMQT and schedule RV number of group specific queries to be sent, one every last member query interval (LMQI) seconds. Since IGMPv3 state change records are retransmitted by the host to guard against packet loss, H1 would retransmit its Leave (TO_INCLUDE{}) after the unsolicited report interval. What should the router do on receiving this leave? 
   
  a) Should it reset the group timer LMQT again and again send out RV number of group specific queries 
  OR
  b) Should it simply ignore this leave?
   
  If it is (b), what should it do if it gets a leave from the other host H2 also during this LMQT period(i.e. H2 leaves the group immediately after sending an overriding join in response to the first group specific query)? Shouldn't that be treated as described in (a)? But how can the router distinguish between leaves from 2 different hosts unless it is explicitly tracking hosts?
   
  Thanks,
  Princy

---------------------------------
Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.

---

From: "Ashish Yadav" <[email-masked]>
Date: Tue, 18 Sep 2007 11:29:46 +0530

Hi,

In IGMP version 3, explicit Host Tracking is done by the router.

Please refer to Appendix B of RFC 3376 (Summary of Changes from IGMPv2),
here it mentions many differences. However, the below mentioned excerpt
from the RFC are relevant for your question. 

*	Hosts no longer perform suppression, to simplify implementations
and permit explicit membership tracking.

Another excerpt supporting the explicit host tracking at router in case
of IGMP v3 RFC 3376 Section A.2 (Host Suppression)

In IGMPv1 and IGMPv2, a host would cancel sending a pending membership
reports if a similar report was observed from another member on the
network.  In IGMPv3, this suppression of host membership reports has
been removed.  The following points explain the reasons behind this
decision.

*	Routers may want to track per-host membership status on an
interface.  This allows routers to implement fast leaves (e.g., for
layered multicast congestion control schemes) as well as track
membership status for possible accounting purposes.

Regards,

Ashish

________________________________

From: Princy Elizabeth [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 10:38 AM
To: [email-masked]
Subject: [magma] IGMP router behavior during LMQT period

Hi,

I had a question regarding the expected router behavior during the last
member query timeout(LMQT) period. Consider 2 IGMPv3 hosts, H1 and H2
sitting on a LAN. Both have subscribed to a group G1. Host H1 now sends
a leave for the group G1. On receiving this the querier would reduce its
GMI to LMQT and schedule RV number of group specific queries to be sent,
one every last member query interval (LMQI) seconds. Since IGMPv3 state
change records are retransmitted by the host to guard against packet
loss, H1 would retransmit its Leave (TO_INCLUDE{}) after the unsolicited
report interval. What should the router do on receiving this leave? 

a) Should it reset the group timer LMQT again and again send out RV
number of group specific queries 

OR

If it is (b), what should it do if it gets a leave from the other host
H2 also during this LMQT period(i.e. H2 leaves the group immediately
after sending an overriding join in response to the first group specific
query)? Shouldn't that be treated as described in (a)? But how can the
router distinguish between leaves from 2 different hosts unless it is
explicitly tracking hosts?

Thanks,

Princy

________________________________

Tonight's top picks. What will you watch tonight? Preview the hottest
shows
<http://us.rd.yahoo.com/tv/mail/tagline/tonightspicks/evt=48220/*http:/t
v.yahoo.com/%20%0d%0a>  on Yahoo! TV. 

Conexant E-mail Firewall (Conexant.Com) made the following annotations---------------------------------------------------------------------********************** Legal Disclaimer **************************** 

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." 

********************************************************************** 

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

---

From: <[email-masked]>
Date: Tue, 18 Sep 2007 11:56:11 +0530

Hi,
 
If host tracking is not implemented on router it makes sense to reset
the timers on reception of leave from H2. Since H2 showed its interest
by sending a report to the Query, Router has to refresh the group timer
and subsequent leave should be used to reset the timer to LMQT in
Router. 
 
"But how can the router distinguish between leaves from 2 different
hosts unless it is explicitly tracking hosts?"
Why should Router distinguish between leaves from 2 different hosts
(considering they are connected to same interface)? Router has to make a
decision whether to forward the streams for the multicast group or not
on that interface. Even if a host is leaving the group but some other
host is interested then it needs to forward the streams.  
 
I too faced a similar if not exact problem. The issue was that the group
timer was reset every time (until RV) the leave was received for a
multicast group. This resulted in higher leave latency. Higher the RV
value higher the leave latency. Resetting the timers only for first
leave solves the problem, but should it be done that way, can anyone
tell me? 
 
Does RFC 3376 section quoted below is referring to the same problem as I
have faced or is it referring to something else? 
 
8.14.1. Robustness Variable
 
   The Robustness Variable tunes IGMP to expected losses on a link.
   IGMPv3 is robust to (Robustness Variable - 1) packet losses, e.g., if
   the Robustness Variable is set to the default value of 2, IGMPv3 is
   robust to a single packet loss but may operate imperfectly if more
   losses occur.  On lossy subnetworks, the Robustness Variable should
   be increased to allow for the expected level of packet loss. However,
   increasing the Robustness Variable increases the leave latency of the
   subnetwork.  (The leave latency is the time between when the last
   member stops listening to a source or group and when the traffic
   stops flowing.)

Regards,
Sandeep.

 
Hi,

 
 
Thanks,
Princy