Subject: mboned: RE: Review comment on IP MCAST MIB

From: "David McWalter" <[email-masked]>
Date: Wed, 5 Oct 2005 11:44:16 +0100

Hi Bharat.

Thanks for reviewing the draft.  Replies inline.

DMcW.

-----Original Message-----
From: Bharat Joshi [mailto:[email-masked]]
Sent: 05 October 2005 10:33
To: [email-masked]
Cc: [email-masked]; [email-masked]; David McWalter
Subject: Review comment on IP MCAST MIB

Hi All,

    I have following comments on this draft:

* ipMcastInterfaceTable has InterfaceIndex as the key. What happens if
more than one multicast routing protocol is running on the same
inteface?
[DMcW] As in RFC 2932, an interface is assumed to run at most one multicast routing protocol.

* Description of ipMcastInterfaceTtl object says that "0" is a default
value but we don't have a DEFVAL defined for it. Can we add it?
[DMcW] Yes.  I'll add DEFVAL and remove the text.

* Is there any specific reason to keep InetAddressType defined for
Group, Source and RP address? I think only one such object should be
enough per table.
[DMcW] Group and source address types can differ, because source address type can be 'unknown'.  Having a single address type would mean we must use the zero source address to mean 'unknown', which is undesirable.  (There is no concept of RP in this MIB.  That's specific to PIM.)

* Can we add the SIZE to syntax "InetAddress"? Its missing at couple of
places like ipMcastRouteGroup, ipMcastRouteSource etc.
[DMcW] I don't think so.  PIM MIBs use (SIZE (0|4|8|16|20)) because only unknown, ipv4, ipv4z, ipv6 and ipv6z types are allowed by PIM.  That restriction does not apply generally to this MIB.  I believe only ipMcastSsmRangeAddress needs the restricted syntax, but correct me if you know more.

* The description of ipMcastRoutePkts seems to be a little complex. Can
we rephrase the same as "Number of packets which has been routed using
this Multicast Route Entry".
[DMcW] Your wording is simpler, but I'm keeping the text from RFC2932 to make it clear that the meaning hasn't changed.  If we change the text, people might wonder whether we've changed what the field means.

* What would be the ipMcastRouteProtocol and ipMcastRouteRtProto when a
multicast route entry is learned from IGMP or MLD?
[DMcW] ipMcastRouteEntries are mappings from upstream interfaces to downstream ones.  These mappings are not usually learned from IGMP/MLD.  IGMP/MLD provide listener information for some multicast routing protocols, and it is those protocols that are named by ipMcastRouteProtocol.  (The exception is IGMP proxy routing, which generates ipMcastRouteEntries for which ipMcastRouteProtocol is igmpOnly(10), I think.)

* Can we rename ipMcastRouteRtProto to ipMcastRouteRtProtocol?
[DMcW] I'd prefer to keep field names from RFC2932, and only change what we're really changing.

* Can we make the description of ipMcastRouteNexthopExpiryTime a little
more elaborte as follows:
if ipMcastRouteNextHopState is pruned(1), this object represents the
remaining time until the prune expires. If this timer expires, state
reverts to "forwarding". Otherwise, this object represents the time
until this entry is removed from the table.
[DMcW] Agree that your wording is slightly superior, but ditto above comments.  We're not changing it, so let's leave it the same.

* Can we add some text to describe the mechanism used to collect the
number of Hops for ipMcastRouteNextHopClosestMemberHops object?
[DMcW] That's a protocol-specific optimization. If the protocol you're working on has no way to determine this, then set it to zero or one.

* For ipMcastRouteTable, we have added an object for "number of octets"
while for ipMcastNextHopTable, we have added an object for "number of
packets". Is there any particular reason to keep it like this? I prefer
both "packets" and "octets" to be available in both the tables.
[DMcW] No change from RFC 2932.  I don't think I have a strong enough case to add ipMRouteNextHopOctets as you suggest.  Feel free to make a case for why this statistic would be very useful.  Adding an octet count where we already have a packet count could be hard for some implementations - depends what layer implements this MIB table.

* Typo "other other writable" in description of ipMcastBoundaryStatus
object.
[DMcW] Thanks.

* From the description of ipMcastLocalListenerSourceAddress, its not
very clear if we are talking about the source address of the host who
has generated a IGMP/MLD join or its the source address of (S,G)
mapping. 
[DMcW] The text must be unclear - it has mislead you.  This table does not describe MGMD listeners, but local applications on the device where the agent is running.  If you're thinking about a PIM/IGMP network, then this table would have entries returned by agents on the hosts, not by agents on the PIM routers.

* What is represented by object ipMcastLocalListenerRunIndex? An example
can be added to explain it.
[DMcW] A UNIX process ID would be an example.  I'm not sure I should put platform-specific examples in the MIB description.

* Should not we add the InterfaceIndex in ipMcastLocalListenerTable from
which a local join has been received?
[DMcW] As above, you've misunderstood.

There are couple of things which I am not sure gets a place in this MIB
but will send it across later.

Thanks & Regards,
Bharat

-- 
Bharat Joshi <[email-masked]>
Infosys Technologies Ltd

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/