Subject: mboned: draft-ietf-mboned-ip-mcast-mib-03 - planned changes

From: "David McWalter" <[email-masked]>
Date: Fri, 10 Nov 2006 05:36:16 -0000

Folks,

Bill had some good feedback on -03, see mail below.  I'll make changes to address his comments.

The planned changes were discussed in the MBONED meeting, and are summarized below for the list.

Next steps agreed with the chairs in the meeting were:
-  I will generate -04 next week.
-  We will then run another WGLC.
-  Hopefully we can then send this for publication.  It's about time.

Comments are welcome.  If anyone has questions about the detail, I'll be happy to address them.
DMcW.

_Planned changes_
-  LanguageTag TC should move to a separate MIB module.
-  ipMcastInterfaceTable needs InetVersion in the index.
   This changes behavior; separates interface statistics for IPv4 and IPv6.
-  ipMcastRouteNextHopTable needs GroupPrefixLength in the index.
-  We don't need Counter32s any more.  We can just have Counter64s.
-  Deprecated fields from RFC 2932 should just be removed.

In the meeting, Martin Horneffer suggested that the best index ordering for interfaceTable would be InetVersion first, and InterfaceIndex next, so that all interfaces with a specified version can be returned in sequence.  This would work better with some existing applications.  It would also match the indexing for ipIfStatsTable in RFC 4293.

I think that is the right thing to do.  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David McWalter
Sent: 08 August 2006 06:06
To: Bill Fenner
Cc: [email-masked]
Subject: RE: mboned: draft-ietf-mboned-ip-mcast-mib-03 - Request
publication?

Hi Bill.

Ta for the review.  Thoughts and answers on all points below.

I'll forward you my number in case you'd like to talk.  I'll propose any changes back to the MBONED list before touching the draft.

Cheers,
DMcW.

-----Original Message-----
From: Bill Fenner [mailto:[email-masked]]
Sent: 07 August 2006 19:37
To: David McWalter
Cc: [email-masked]
Subject: Re: mboned: draft-ietf-mboned-ip-mcast-mib-03 - Request
publication?

David,

  I made some really horribly abbreviated notes while reading
through the MIB, which I delayed sending until I could expand
some of the abbreviations.  However, that delay stretched too
long so I'll send what I have with an apology and an offer to
chat on the phone or otherwise if you need clarifications or
to discuss any of these items.

Thanks,
  Bill

Top-level Q's:
- Why are deprecated objects included at all?

[DMcW] There are two deprecated objects.  Yes, we could just delete these if we wanted to.
  ipMcastInterfaceProtocol, which is the old/wrong configuration model of one protocol per interface.
  ipMcastMIBMRouteCompliance, equivalent to ipMRouteMIBBasicGroup (from RFC 2932 IPMROUTE-STD-MIB).
My feeling is that these objects have some utility.  For example, below you suggest ipMcastInterfaceProtocol description should state the correct solution.  This is linked to the next question.

- The REVISION doesn't point to a previous version of this *module*, that was a different module - it should be removed(?) or this module should be renamed(?)

[DMcW] I'd say this should be a new MIB module, obsoleting RFC 2932 IPMROUTE-STD-MIB, and yet it is clearly a revision of that module.  D'you think we should go for a clean break; delete the deprecated objects and the REVISION text?  It might be the cleanest way.

- Reorder objects (e.g., ipMCastRouteHCOctets w/ ipMCastRouteOctets, ipMcastRouteDifferentInIfOctets w/ ipMcastRouteDifferentInIfPackets?)

[DMcW] Sure, I'll tidy up ordering.  I'll avoid alternating Counter32/Counter64, as that might encourage some implementations to waste packing space.

- general issue: prefix bits w/ v*z description needs to make it clear that it doesn't mask off the zone

[DMcW] Agree.  This excerpt is from ipMcastSsmRangeAddress.  I'll paste it to other prefixed addresses that can take v*z types.
            For addresses of type ipv4z or ipv6z, the appended zone
            index is significant even though it lies beyond the prefix
            length.  The use of these address types indicate that this
            SSM range entry applies only within the given zone.  Zone
            index zero is not valid in this table.

- LanguageTag raises a red flag - is this really the best we have?  Defining this generic TC in this specific MIB makes me uncomfortable.

[DMcW] Existing rot.  LanguageTag TC was defined in RFC2932, e.g. RFC3559 MALLOC-MIB includes IPMROUTE-STD-MIB just for LanguageTag.  We could tidy up by putting the TC in its very own MIB module.  I'd be happy to write that trivial draft if you think it's worth the process trouble to do so.

- What's the difference between 0.0.0.0 / 0::0 and a 0-zised InetAddress?

[DMcW] 0.0.0.0 and :: have an address type, but a 0-sized InetAddress has no type.  This is from RFC 4001 definition for InetAddressType, which forbids zero-length IPv4 and IPv6 addresses.  Note that RFC 4001 definition for InetAddressPrefixLength carefully leaves zero-prefix-length as context-specific.  So we could use 0.0.0.0 / 0::0 with zero prefix length to mean 'no address specified' in this MIB, but I think that's undesirable because it would give two distinct values for 'no address', and possibilities for muddling 'no address' with the IPv4 global zone as well.
http://www.ietf.org/rfc/rfc4001.txt

ipMcastInterfaceProtocol
 - say what to use instead in DESCRIPTION

[DMcW] Sure, will refer to ipMcastRouteProtocol and describe how multiple protocols can be used for disjoint group addresses (though we might delete ipMcastInterfaceProtocol entirely - see first point).

compare ipMcastInterfaceOutMcastOctets with ifOutOctets?

[DMcW] Sure.  ipMcastInterfaceInMcastOctets and ipMcastInterfaceOutMcastOctets should make the same comparisons.

ipMcastSsmRangeAddress:
 - sounds like the zone-ID is masked off by the prefix, so is useless?

[DMcW] No - here's the text from ipMcastSsmRangeAddress stating zone index is not affected.
            For addresses of type ipv4z or ipv6z, the appended zone
            index is significant even though it lies beyond the prefix
            length.  The use of these address types indicate that this
            SSM range entry applies only within the given zone.  Zone
            index zero is not valid in this table.

ipMcastRouteGroup: once again zone-id masked by prefix?

[DMcW] Will paste text from ipMcastSsmRangeAddress to clarify.

ipMcastRouteTable has G-prefix, ipMcastRouteNextHopTable doesn't

[DMcW] A bug!  Will fix.

Relationship between ipMcastRouteNextHopClosestMemberHops and interface threshold?

[DMcW] Implicit in ipMcastRouteTtlDropPackets description.  Will make explicit in ipMcastInterfaceTtl and ipMcastRouteNextHopClosestMemberHops descriptions.

no ipMcastRouteNextHopOctets HC version?

[DMcW] Yep, should add.  Will do.

Really ipMcastBoundaryHCDroppedMcastPkts?  If HC here for pkts why not HC elsewhere?  (what's the guideline for HC on pkts?)

[DMcW] I'd say yes - organization/AS edge filters might be busy and rarely inspected.  Hrm - perhaps best to have HC versions of every Counter32.

ipMcastLocalListenerRunIndex has the problem that the UDP MIB has wrt socket-based systems - multiple PIDs may have the same socket open, the process that initially opened it may hand it off to someone else and close it, etc.

[DMcW] Right.  Note that RunIndex is part of the index for this table.  So the table doesn't map (S,G)/socket/whatever to *a* PID, it *lists* the listeners' PIDs associated with the (S,G)/socket/whatever.

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

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

---

From: "David McWalter" <[email-masked]>
Date: Thu, 16 Nov 2006 09:31:15 -0000

These changes are now applied.
DMcW.

http://www.ietf.org/internet-drafts/draft-ietf-mboned-ip-mcast-mib-04.txt

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David McWalter
Sent: 10 November 2006 05:36
To: [email-masked]
Subject: mboned: draft-ietf-mboned-ip-mcast-mib-03 - planned changes

Folks,

_Planned changes_

-----Original Message-----

Hi Bill.

Cheers,
DMcW.

-----Original Message-----
From: Bill Fenner [mailto:[email-masked]]
Sent: 07 August 2006 19:37
To: David McWalter
Cc: [email-masked]
Subject: Re: mboned: draft-ietf-mboned-ip-mcast-mib-03 - Request
publication?

David,

Thanks,
  Bill

Top-level Q's:

ipMcastInterfaceProtocol

ipMcastSsmRangeAddress:

[DMcW] A bug!  Will fix.