Subject: [magma] IGMP MIB inputs

From: Karen Kimball <[email-masked]>
Date: Thu, 9 Jan 2003 15:55:29 -0800 (PST)

Hello, Everyone,

In reviewing the proposed IGMP MIB, there are a few areas that,
while described for routers, also would be meaningful for IGMP 
snooping switches. A few minor modifications or additional 
considerations could aid this more general use.

Specifically, while for routers the network interface (subnet) and 
physical port are one and the same, on switches there can be multiple 
port interfaces for a given network interface. Some of the proposed 
objects for interfaces would be more useful if they were per-physical
-port and not just per-subnet. For instance, the Cache Table could
provide more information as a per-port table when implemented on a
switch (and there would be no difference in the information returned
if implemented on a router).

Could we consider a naming convention that allows this? While switch 
vendors could lump all of their applicable ports together when 
returning an interface object, this would sometimes result in more 
refined information being lost.

On to the comments for the proposed MIB.

1) igmpInterfaceStatus

   Although this is of type "RowStatus," it is being used as a 
   configuration object. I believe that the label	  

     igmpInterfaceState

   is typically what is used in this case.

2) It appears that igmpInterfaceVersion should be modified as follows:

igmpInterfaceVersion OBJECT-TYPE 
    SYNTAX     Integer32 { igmpV1 (1),
			   igmpV2 (2),
		           igmpV3 (3)  }
    MAX-ACCESS read-create 
    STATUS     current 
    DESCRIPTION 
            "The version of IGMP which is running on this interface. 
            This object can be used to configure a router or switch
	    capable of running more than one version. For IGMP to 
	    function correctly, all routers on a LAN must be 
	    configured to run the same version of IGMP on that LAN." 
    DEFVAL     { 2 } 
    ::= { igmpInterfaceEntry 4 } 

3) For     igmpInterfaceQuerier      what is the value if the local
   system is the Querier? This should be indicated in the description.

4) The description for the object below should be modified as follows:

igmpInterfaceQueryMaxResponseTime OBJECT-TYPE 
    SYNTAX     Unsigned32 (0..255) 
    UNITS      "tenths of seconds" 
    MAX-ACCESS read-create 
    STATUS     current 
    DESCRIPTION 
            "The maximum query response time advertised in IGMPv2 
            or IGMPV3 General Membership Queries on this interface." 
    DEFVAL     { 100 } 
    ::= { igmpInterfaceEntry 6 } 

5) For      igmpInterfaceQuerierUpTime    what is the value if the
   local system is and has always been the Querier? Is it 0? That
   would be "The time since igmpInterfaceQuerier was last changed" 
   as the description indicates. Or should the description be changed 
   instead to something like,

   "The time since igmpInterfaceQuerier was initiated (if this local
   system is Querier) or since it was last changed." 

6) The    igmpInterfaceJoins    object could provide additional
   information on switches if it was per-each-interface-port-member 
   rather than for the interface as a whole (this goes along with my 
   suggestion to make the Cache Table per-interface-port-member as
   well). 

   Can the object be restructured so that it is instead a table of
   port entries for this interface? On a router, the table would
   always be referenced as 1.1 { interface1, port member 1 } because
   interface and port are always the same for routers.

   The    igmpInterfaceGroups    object could also benefit from this
   same restructuring, i.e., becoming a table of port member entries
   for the interface.

7) Restructuring     igmpCacheIfIndex    to instead be a series of
   member-port entries for each interface would provide additional
   information on switches. This would then show how the multicast
   group address is being used on each physical port rather than
   just on the subnet.

8) Regarding the    igmpCacheSelf   object, I am not sure what it
   means for a local system to be a member of a group address on an
   interface. If the local sytem is the Querier, is it always 
   considered a member? Even if it generates no membership reports?
   What about when the local system is snooping the group? Is it a
   member then?

9) I can see    igmpCacheExpiryTime   being useful as an indication
   of the Membership Timer for a given group, when the local system
   is the Querier. On a switch, however, this is again per-member-port
   and not per-subnet. Could we restructure this entry as well? 

   Also, in the case where the local system is not the Querier and is 
   merely snooping the given group, it appears that a value of 0 would 
   again be appropriate. However, the description does not cover any 
   0 cases unless igmpCacheSelf is true. Can we expand the meaning of 
   this object, and its description?

10) For switches,     igmpCacheSourceFilterMode    is again per-
   member-port and not per-subnet. Could we restructure this entry?

11) For switches,     igmpSrcListIfIndex    is per-member-port and
   not per-subnet.

Best regards,
     Karen Kimball
     [email-masked]  

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