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

From: "David McWalter" <[email-masked]>
Date: Wed, 5 Oct 2005 12:48:25 +0100

Bharat,

Thanks again.  I'll apply some of the editorial improvements you suggest in the next draft.

You've raised one big point - Can we run more than one multicast routing protocol on a single interface?

I believe the answer remains 'no', at least when 'interface' has the meaning from RFC 2932 and IP-MCAST-MIB.

If anyone has a counterexample, let me know and I'll make the change.
DMcW.

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

Hi David,

    I do not agree that we should not modify[enhance] the text if it was
previously not very clear.

    This is exactly what we did for PIM MIB when we started. I agree
thar if a new draft is being generated, we should keep the previous
stuff as much as possible but if with some improvements in text, we can
make it more understandable, I think we should do that.

    Also we have mentioned that this new draft obsoletes the RFC 2932 so
people who are referring to this draft is suppose to expect differences.
Right??

    Please see my replies in line.

Thanks & Regards,
Bharat

On Wed, 2005-10-05 at 11:44 +0100, David McWalter wrote:
> 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.
> 

I am not sure if this is completely correct. I think today, there might
be network configurations where more than one Multicast Routing Protocol
runs on the same Interface.

As I mentioned above, what RFC 2932 defined, should be updated as and
where required. I think we should update this part.

> * 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.

Ok. Got you. I think you are talking about other layer#3 protocols.

> 
> * 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.
> 

Please see above.

> * 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.)
> 

Got your point.

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

Please see above.

> * 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.
> 

Please see above.

> * 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.
> 

Please add this very same explanation to the description. It will surely
help.

> * 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.
> 

Though I think one of them should be enough to findout if a particular
route or nexthop is in use but I saw that one is using octets and other
is using packets so lets complete both of them by providing objects for
both of them.

If we can change this, I would prefer to see noOfPkt being maintained
for both of them.

> * 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.
> 

Yes. Now I understood what this table is used for. Can you please put
almost the same working in the Table description.

Thanks & Regards,
Bharat

**************** 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/