Subject: RE: [magma] Multicast Group Membership Discovery MIB questions &comments

From: "kishore P" <[email-masked]>
Date: Mon, 01 Aug 2005 02:52:27 -0400

Hi  Karen,

Here are some of my comments to your suggestions -

1. There is no need for mgmdHostInterfaceVersion3QuerierTimer, (section 
7.2.1 of RFC 3376). If both Version2 and version1 Querier timer are not 
running means the interface is in IGMPv3 or MLD2.

4. This is a good one, I don't think this should be ever  zero (last 
reporter IP address). The explaination of this variable should change.

Rgds,
Kishore

>From: "Kimball, Karen E" <[email-masked]>
>To: <[email-masked]>
>Subject: [magma] Multicast Group Membership Discovery MIB questions 
>&comments
>Date: Fri, 29 Jul 2005 16:03:51 -0700

>
>Sorry for such late feedback, and please forgive any areas that have
>already been discussed to death.
>
>What follows are some suggestions/issues for the Multicast Group
>Membership Discovery MIB.
>
>1) In the MgmdHostInterfaceEntry table, there is no object for
>mgmdHostInterfaceVersion3QuerierTimer.
>	It seems that at this point, with specs well out for IGMPv3 and
>MLDv2, this should be added.
>
>2) In the MgmdHostInterfaceEntry table, the   "mgmdHostInterfaceVersion"
>object seems as if it ought to either be RENAMED
>"mgmdHostMaxInterfaceVersion" (for clarity), or that if this is in fact
>the CURRENT Interface Version on the host, that the text description for
>the object should be modified.
>
>3) In the MgmdHostCacheEntry table, the object
>"mgmdHostCacheLastReporter"  describes the last membership report
>RECEIVED for a given group address. Being as this is a  host table,
>should that instead be the last membership report SENT for the group
>address?
>
>4) In both the MgmdHostCacheEntry table, and the MgmdRouterCacheEntry
>table, the description says that the mgmdXXXCacheLastReport object value
>is 0::0 if no membership report has been received (sent?). IF no report
>has been received/sent yet, why is the entry in the table at all? It
>seems that it should not be added to the cache until an actual report
>occurs.
>
>The MIB is otherwise looking good, and is much more concise than the
>original (so many years ago).
>
>Best Regards,
>	Karen Kimball
>
>
>
>_______________________________________________
>magma mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/magma

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

---

From: Julian Chesterfield <[email-masked]>
Date: Sun, 31 Jul 2005 12:42:38 -0400

Karen,

Thanks for the comments, some replies inline.

> MLDv2, this should be added.

My interpretation is that IGMPv3/MLDv2 compatibility is implied as the 
default, and once the earlier timers expire, the host/router will 
switch to the highest compatibility mode. Therefore a node that 
supports v3 does not maintain an internal timer for v3 hosts to expire.

> the object should be modified.

Good point, this ties in with the comment from kishore that we need to 
add a current compatibility mode for hosts/router. I suggest leaving 
the InterfaceVersion object as is, and adding a currentInterfaceVersion 
variable to show current compatibility state.

> should that instead be the last membership report SENT for the group

Agreed.

> seems that it should not be added to the cache until an actual report

I think this was left in by accident from when the cache table entries 
were writeable, i.e. while state is being created by an external 
manager, so I'll remove this sentence.

> original (so many years ago).

Thanks!

- Julian