I have completed a pass of the document. The document
is shaping up well.Once again thanks for the good work.
The comments follow. I would also recommend a closer check
for editorial nits in the next draft.
1. Please make the usages uniform. e.g.
"Multicast VPN (MVPN)" vs "Multicast VPN" (MVPN)
MVPN vs Multicast VPN
"Inclusive PMSI (I-PMSI)" vs "Inclusive PMSI" (I-PMSI)
2. Page 3, Sec 1, para 2
This document describes managed objects to configure and/or monitor
3. Page 3, Sec 1.1, para 3
s/A PE uses to/A PE uses a P-tunnel to/
4. Page 3, Sec 1.1, para 5
What is the minimum number of VRFs on a PE? 0? 1? Please update
the paragraph accordingly.
5. Page 4, Sec 3.1 Summary of MIB Module
s/attribute informations of MVRFs of MVPNs/attributes of MVPNs/
s/Configuring some timers/Monitoring and configuring some timers/
s/Monitoring attribute informations of PMSIs/
Monitoring PMSI attribute information/
s/Monitoring advertisement exchanged/Monitoring statistics on
6. Table naming.
mvpnIpmsiAdvtTable, mvpnInterAsIpmsiAdvtTable, mvpnSpmsiAdvtTable
These are tables containing counters about advertisements received.
But the names seem to imply that they contain advertisements. Please
7. Page 5, Sec 3.1 Summary of MIB Module (contd)
s/contain information of MVRFs of MVPNs/contain information of MVPNs/
s/Selective PMSI (S-PMSI)/S-PMSI/
s/that is advertised/that are advertised/
8. This MIB, particularly mvpnGenericTable, uses MPLS-L3VPN-STD-MIB. Please
mention this explicitly.
9. Page 62 Sec 4.
mvpnGenCustomerSiteType, mvpnGenSPTunnelLimit, mvpnBgpGenMode,
10. Please do the '[TBD]'
On 2018/05/13 18:56, Glenn Mansfield Keeni wrote:
I have done a review of the MIB. The comments follow.
Only the MIB has been reviewed.
1. Naming: Please review.
if it is a condition for import name accordingly
2. Usage: Please make the usages of the following uniform in the document
tunnel type/Tunnel type
3. Units: The units for the following MOs are unspecified.
InetAddress and INetAddressType objects
for several MOs, usage of InetAddressType unknown(0)
is described. In all such cases the corresponding
InetAddress MO value MUST be a string of length 0.
Plese explain that case in the respective DESCRIPTIONs
5. mvpnSpmsiAdvtCmcastSourceAddr OBJECT-TYPE
==> corresponding InetAddressType object
mvpnSpmsiAdvtCmcastSourceAddrType is missing
MO: mvpnMrouteCmcastSourceAddrType OBJECT-TYPE
"A value indicating the address family of the address
contained in mvpnMrouteSourceAddr.
7. Table descriptions:
The DESCRIPTIONs are unclear.
Do the tables 'contain' all advertisements or,
Statistics related to the advertisements?
8. Additional suggestions:
o For INDEX clauses of variable size where the size may potentially
exceed 128 octets, a statement like the following will be good.
Implementors need to be aware that if the total number of
octets in MO1, MO2 and MO3 exceeds NNN, then OIDs of column
instances in this row will have more than 128 sub-identifiers
and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
o In REFERENCES be more specific if possible. Eg.
"RFC2863 Sec. 3.1.5
On 2018/05/02 6:59, Glenn Mansfield Keeni wrote:
Thanks for the good work.
I will start reviewing this right away.
On 2018/05/01 12:14, Hiroshi Tsunoda wrote:
Thank you for waiting the update.
I have submitted the updated version of
Links to the draft and diff are as follows.
This version contains some major changes as follows.
I hope this update make the role and usage of the MIB clear for you.
1. Support for row creation in all tables is removed
Reason: The utility of row creation is dubious.
It increases complexity of the MIB implementation.
Unless an immediate need for row creation, we will go ahead
with the current draft and review the need for row creation
at a later date if and when it arises.
2. Added objects to make the role and usage of this MIB clear.
Reason: This MIB will provide the following management functions.
- Configuration of MVRF related timers
- Generation of Notifications to indicate creation, deletion,
and/or modification of MVRFs
- Generation of Notification when a member joins or leaves a
- Monitoring of the following
- attributes of MVRFs of MVPNs
- statistics of advertisements exchanged by a PE
- routing entries in a MVRF
- next-hops for a multicast destination in a MVRF
MIB-DOCTORS mailing list
MIB-DOCTORS mailing list
BESS mailing list