A. MIB design related --------------------- 1. smilint -s -e -l 5 mibs/MCAST-VPN-MIB gives some valid warnings: mibs/MCAST-VPN-MIB:485: [5] {index-exceeds-too-large} warning: index of row `mvpnPmsiConfigEntry' can exceed OID size limit by 399 subidentifier(s) mibs/MCAST-VPN-MIB:627: [5] {index-exceeds-too-large} warning: index of row `mvpnSpmsiConfigEntry' can exceed OID size limit by 431 subidentifier(s) mibs/MCAST-VPN-MIB:749: [5] {index-exceeds-too-large} warning: index of row `mvpnIpmsiEntry' can exceed OID size limit by 431 subidentifier(s) mibs/MCAST-VPN-MIB:846: [5] {index-exceeds-too-large} warning: index of row `mvpnInterAsIpmsiEntry' can exceed OID size limit by 175 subidentifier(s) mibs/MCAST-VPN-MIB:923: [5] {index-exceeds-too-large} warning: index of row `mvpnSpmsiEntry' can exceed OID size limit by 688 subidentifier(s) Each of the warnings are examined below. 1.1 mvpnPmsiConfigEntry: index items are mvpnPmsiConfigTunnelType, mvpnPmsiConfigTunnelAuxInfo, mvpnPmsiConfigTunnelPimGroupAddressType, mvpnPmsiConfigTunnelPimGroupAddress, mvpnPmsiConfigTunnelOrTemplateName without any restrictions on the size of mvpnPmsiConfigTunnelOrTemplateName (type SnmpAdminString; max size 255 octets) the index will indeed be too large. the max size of the index is 128 octets. Question: Do you really need mvpnPmsiConfigTunnelOrTemplateName in the index? 1.2 mvpnSpmsiConfigEntry: problem similar to 1.1 1.3 mvpnIpmsiEntry: warning can be ignored. It will have to taken care of by explicitly describing the restriction of the elements in each item. 1.4 mvpnInterAsIpmsiEntry the index items are mplsL3VpnVrfName, mvpnInterAsIpmsiAfi, mvpnInterAsIpmsiRD, mvpnInterAsIpmsiSrcAs without any restrictions on the size of mvpnInterAsIpmsiRD (max size is 266 octets) the index will be indeed be too large. 1.5 mvpnSpmsiEntry: the warning can be ignored. It will have to taken care of by explicitly describing the restriction of the elements in each item. 2. Page:4 The configuration and states specific to an MVPN include the following information elements: What are the "states" referred to above? 3. Page:4 The following four tables are designed for configuring MVPNs on PEs. There is a mvpnModuleReadOnlyCompliance which will allow read only access to these tables. So, there may be an compliant implementation that does not allow configuration but allows monitoring. We should probably say The following four tables represent the MVPN configurations on PEs. 4. Page:6 The following four tables are designed for monitoring MVPNs on PEs. It may be better to be more specific about the "monitoring MVPNs on PEs" is. It appears that mvpnIpmsiTable mvpnInterAsIpmsiTable mvpnSpmsiTable contain only the MVPN Advertisements and, mvpnMrouteTable extends ipMcastRouteTable with some VPN specific information. B. Coverage and applicability. ----------------------------- 1. It will be immensely helpful if a use case scenario of the MIB is given. I am yet to figure out a use case scenario of the MIB. That is more likely due to lack of understanding of the operational and management issues of MCAST-VPN. Please help me understand. 2. RFC6514: Page13 Sec5 An implementation MUST provide debugging facilities to permit issues caused by a malformed PMSI Tunnel attribute to be diagnosed. At a minimum, such facilities MUST include logging an error when such an attribute is detected. RFC6514: Page16 Sec8. An implementation MUST provide debugging facilities to permit issues caused by malformed PE Distinguisher Label attribute to be diagnosed. At a minimum, such facilities MUST include logging an error when such an attribute is detected. Looks like there should be a counter for such malformed atributes received. Then a monitor/NMS could periodically check for the presence of malformed attributes.. 3. RFC6514: Page54 Sec16.1.1 A PE/ASBR/route reflector can OPTIONALLY delay the advertisement of withdrawals of C-multicast routes. An implementation SHOULD provide the ability to control the delay via a configurable timer, possibly with some backoff algorithm to adapt the delay to multicast routing activity. Looks like there should be an object which implements "configurable timer" 4. RFC6514: Page55 Sec17 Security considerations: When C-multicast routing information is exchanged among PEs using BGP, an implementation SHOULD provide the ability to rate limit BGP messages used for this exchange. This SHOULD be provided on a per- PE, per-MVPN granularity. An implementation SHOULD provide capabilities to impose an upper bound on the number of S-PMSI A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per- PE, per-MVPN granularity. In conjunction with the procedures specified in Section 14, an implementation SHOULD provide capabilities to impose an upper bound on the number of Source Active A-D routes, as well as on how frequently they may be originated. This SHOULD be provided on a per- PE, per-MVPN granularity. Looks like the above mechanisms should be provisioned for in the MIB. 5. There are no counters/gauges in the MIB. Are counter object like Number of MVPN advertisements received Number of MVPN advertisements rejected etc. of no interest? C. Editorial Nits. ----------------- 1. Page:3 This document borrowed.... I suggest this sentence be moved to the Acknowledgment section. 2. Page:3 s/A PE uses to send/A PE sends/ 3. Page:3,4 Interchangeably, the term Multicast Virtual Routing and Forwarding table (MVRF) and MVPN are used to refer to a particular Multicast VPN instantiation on a particular PE. As described in [RFC4382], each PE router maintains one default forwarding table and "VPN Routing and Forwarding tables", or "VRFs". Throughout this document, we will use the term "multicast VRF (MVRF)" to refer a VRF that is configured to contain the multicast routing information. Looks like the order of these 2 paragraphs should be interchanged. 4. A thorough editorial check for syntax and semantics is required.