Re: [bess] Update to draft-ietf-bess-mvpn-mib-08

[Glenn Mansfield Keeni]

Dear Tsuno,
 This draft is looking good. Thank you for the
good work. I have no further issues with the document
and the MIB. I believe the MIB review is complete.

Thanks again for your cooperation during this rather
long and tedious review.

Glenn

On 2018/07/30 19:39, Hiroshi Tsunoda wrote:

Hi Glenn,

I have submitted draft-ietf-bess-mvpn-mib-08.
Links to the draft and diff are as follows.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-08.txt
Htmlized:   https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-08
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-08

Please see some notes below.


1. Delete the last paragraph of IANA considerations.


Done.


2. Move
  mvpnBgpCmcastRouteWithdrawalTimer,
  mvpnBgpSrcSharedTreeJoinTimer,
   from mvpnBgpGroup to mvpnScalarGroup
   unless there is a good reason to keep those in mvpnBgpGroup


I have added new OBJECT-GROUP called mvpnBgpScalarGroup.
All BGP-specific scalar objects (see the list below) are in the group now.
This is for providing more appropriate compliance statements.

- mvpnMldpMvrfs,
- mvpnBgpV4Mvrfs,
- mvpnBgpV6Mvrfs,
- mvpnBgpCmcastRouteWithdrawalTimer,
- mvpnBgpSrcSharedTreeJoinTimer

I hope this version clears all of your requirements.

Best,

-- tsuno



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Update to draft-ietf-bess-mvpn-mib-07

[Glenn Mansfield Keeni]

Hi Tsuno,
   Thanks for the quick response.
Will confirm the changes and get back to you
before the end of the week.

Glenn
On 2018/07/23 20:44, Hiroshi Tsunoda wrote:

Hi Glenn,

I have submitted the updated version of draft-ietf-bess-mvpn-mib.
Links to the draft and diff are as follows.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-07.txt
Htmlized:   https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-07
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-07

I believe that all comments that you gave as of now are
addressed in this version.
I hope this revision fulfills your requirements.

- Major changes are as follows ---

   - Simplification of branch structure
mvpn{Generic, Config, States} branches are removed.
All tables are directly under mvpnObjects branch now.

   - Re-organization of table structures
mvpnAdvtStatsTable was added and
mvpn{Ipms, InterAsIpmsi, Spmsi}AdvtTable were removed.
All objects representing advertisement statistics
are defined in mvpnAdvtStatsTable now.

   - Relocation and removal of some managed objects

  - mvpnSPTunnelLimit, mvpnBgpCmcastRouteWithdrawalTimer, and
mvpnBgpSrcSharedTreeJoinTimer are defined per PE instead of
per MVPN.
  - mvpnSpmsiThreshold, mvpnSpmsiAdvtRefCnt, and
some objects representing "address family" in a table
are removed.

   - Update of security considerations



-- tsuno

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] [MIB-DOCTORS] Update to draft-ietf-bess-mvpn-mib-06

[Glenn Mansfield Keeni]

Hi Tsunoda,
   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.

Glenn
--

draft: draft-ietf-bess-mvpn-mib-06.txt

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
   MVPN.
   s/MVPN/MVPNs/

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 
advertisements

exchanged/

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
   rename appropriately.


7. Page 5, Sec 3.1 Summary of MIB Module (contd)
   s/contain information of MVRFs of MVPNs/contain information of MVPNs/
   s/represetns/represents/
   s/Selective PMSI (S-PMSI)/S-PMSI/
   s/mvpnGeneralTable/mvpnGenericTable/
   s/mvpnSpmsiConfigTable/mvpnSpmsiTable/
   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.
   s/read- write/read-write/
   s/mvpnGenCmcastRouteProtocol, mvpnGenIpmsiInfo,
 mvpnGenInterAsPmsiInfo, mvpnGenUmhSelection,
 mvpnGenCustomerSiteType, mvpnGenSPTunnelLimit, mvpnBgpGenMode,
 mvpnBgpGenVrfRtImport, mvpnPmsiEncapsulationType,
 mvpnSpmsiThreshold, mvpnSpmsiPmsiPointer/
 mvpnBgpGenCmcastRouteWithdrawalTimer,
 mvpnBgpGenSrcSharedTreeJoinTimer,
 mvpnBgpGenMsgRateLimit,
 mvpnBgpGenMaxSpmsiAdRoutes,
 mvpnBgpGenMaxSpmsiAdRouteFreq,
 mvpnBgpGenMaxSrcActiveAdRoutes,
 mvpnBgpGenMaxSrcActiveAdRouteFreq,
 mvpnSpmsiThreshold/
10. Please do the '[TBD]'



On 2018/05/13 18:56, Glenn Mansfield Keeni wrote:

Hi Tsunoda,
    I have done a review of the MIB. The comments follow.
Glenn

draft: draft-ietf-bess-mvpn-mib-06.txt
    Only the MIB has been reviewed.

COMMENTS:

1. Naming: Please review.
     MO: mvpnBgpGenVrfRouteImport:
   if it is a condition for import name accordingly

2. Usage:  Please make the usages of the following uniform in the document
   MVPN/mvpn/MVRF
   tunnel type/Tunnel type
   Source AS/source-as


3. Units:  The units for the following MOs are unspecified.
     Please check.
     MO: mvpnBgpGenCmcastRouteWithdrawalTimer
     MO: mvpnBgpGenSrcSharedTreeJoinTimer
     MO: mvpnBgpGenMsgRateLimit
     MO: mvpnBgpGenMaxSpmsiAdRoutes
     MO: mvpnBgpGenMaxSpmsiAdRouteFreq
     MO: mvpnBgpGenMaxSrcActiveAdRoutes
     MO: mvpnBgpGenMaxSrcActiveAdRouteFreq
4. Semantics:
     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
     E.g. mvpnMrouteUpstreamNeighborAddr
  mvpnMrouteNextHopSourceAddr
  mvpnMrouteCmcastSourceAddr
  mvpnMrouteSourceAddr

5. mvpnSpmsiAdvtCmcastSourceAddr OBJECT-TYPE
  SYNTAX    InetAddress
  ==> corresponding InetAddressType object
  mvpnSpmsiAdvtCmcastSourceAddrType is missing

6. Nits:
     MO:  mvpnMrouteCmcastSourceAddrType OBJECT-TYPE
  DESCRIPTION
  "A value indicating the address family of the address
   contained in mvpnMrouteSourceAddr.
  s/mvpnMrouteSourceAddr/mvpnMrouteCmcastSourceAddr/

7. Table descriptions:
  mvpnIpmsiAdvtTable
  mvpnSpmsiAdvtTable
     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
 

Re: [bess] Update to draft-ietf-bess-mvpn-mib-06

[Glenn Mansfield Keeni]

Hi Tsunoda,
   Thanks for the good work.
I will start reviewing this right away.

Glenn

On 2018/05/01 12:14, Hiroshi Tsunoda wrote:

Dear Glenn,

Thank you for waiting the update.
I have submitted the updated version of
draft-ietf-bess-mvpn-mib.

Links to the draft and diff are as follows.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-06.txt
Htmlized:   https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-06
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-0

This version contains some major changes as follows.
I hope this update make the role and usage of the MIB clear for you.

+--+
Changes:

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
  multicast group

- Monitoring of the following
  - attributes of MVRFs of MVPNs
  - PMSIs
  - statistics of advertisements exchanged by a PE
  - routing entries in a MVRF
  - next-hops for a multicast destination in a MVRF
+--+

-- tsuno



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-11

[Glenn Mansfield Keeni]

Hi Tsuno,
   Thanks for addressing the issues in the new draft. It
looks good. I do not have any major issues with the MIB.
But before we give a go-ahead I would like to ask to you
do another editorial check for nits.These are basically
  s/network/networks/
type of fixes.
A minor issue with the MIB on naming related mater-
I would suggest
  s/l2L3VpnMcastPmsiFieldGroup/l2L3VpnMcastCoreGroup/

Glenn

On 2017/10/22 1:14, Hiroshi Tsunoda wrote:

Dear Glenn,

Thank you for your comments and for waiting for the update.
I posted a new revision (-11) as follows.

URL:
   
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-11.txt
Htmlized:
   https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11
Htmlized:
   
https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11
Diff:
  https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-11

Please see the responses for your comments in the followings.

2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>:

1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION
1.1   It will be good to give a reference (RFC) for
  noTunnelInfo   (0) : no tunnel information present
   That will make it consistent with the other items.
   This change will require adding RFC to the REFERENCE clause.


Fixed.


1.2  pimBidir   (5) : BIDIR-PIM Tree  [RFC5015]
   RFC5015 needs to be added to the Reference section


RFC5015 added to the Reference section.


3. Page-7,8: says
" A L2L3VpnMcastProviderTunnelType object of value
  noTunnelInfo(0) indicates that the corresponding
  Provider Multicast Service Interface (PMSI) Tunnel
  attribute does not have a Tunnel Identifier."
It may be better to align the wording with RFC6514 (Page 11)
' When the Tunnel Type is set to "No tunnel information
  present", the PMSI Tunnel attribute carries no tunnel
  information (no Tunnel Identifier).'


Fixed. Thank you for your advice.


4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION:
  E: Extension flag [RFC7902]
   RFC7902 needs to be added to the Reference section


Fixed. RFC7902 is now in the Reference section.


5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE
   "RFC6514, Section 5
RFC7902
   "
   It will be nice to have a section pointer for RFC7902 too.
   (User-friendly and consistency).
   Please check the same for all the REFERENCE clause pointers


Added a section point for Sec.3 of RFC7902.


6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION
   "When UDP-based S-PMSI signaling is used, the value of
   this object is zero."
This is actually a 48-bit string. What would be the
representation of "zero" above be? Will it be a string of
length 0, a string containing a single ascii character "0"
6 ascii "0"s, 48 '0' bits ?

7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION:
   "When UDP-based S-PMSI signaling is used, the value of
   this object is zero that indicates the absence of MPLS
   Label."
Once again.  "zero" above is imprecise.


In the current revision, these parts are revised as follows.
   When the P-tunnel does not have a correspondent PMSI tunnel
   attribute, the value of this object will be 0.


8. Compliance:
It would be good to design the compliance module as follows:
   l2L3VpnMcastCoreCompliance:
   MANDATORY-GROUPS {
l2L3VpnMcastPmsiFieldGroup
   }
   l2L3VpnMcastFullCompliance:
   MANDATORY-GROUPS {
l2L3VpnMcastPmsiFieldGroup
l2L3VpnMcastOptionalGroup
   }


Fixed along with your comments. Thank you.


General:
10Page-2 Section-1
10.1In BGP/MPLS Virtual Private Networks (VPN)
 In BGP/MPLS Virtual Private Networks (VPNs) ?


Fixed.


10.2Throughout this document, we will use the term
 "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support
 multicast.

 Throughout this document, we will use the term
 "L2L3VpnMCast network" to mean a network that comprises of
 BGP/MPLS L2 and L3 VPNs and supports multicast.


Fixed. Now, the term "L2L3VpnMCast network" is used throughout the document.


10.3  Page-4 Section-3 bullet 2
   Please review the paragraph for readability.


Revised the paragraph in order to improve readability.


10.4  It will be good to avoid page-breaks within quoted clauses.
   example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE


Thank you for your comments. I adjusted the page-breaks along with this comment.

Thanks again.

-- tsuno

2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni &

Re: [bess] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-10

[Glenn Mansfield Keeni]

Dear Tsuno,

Thanks for the revised draft. I have reviewed the draft.
Some issues remain. These are listed below
Please consider the issues/comments and update the draft.

Glenn

++

1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION
1.1   It will be good to give a reference (RFC) for
 noTunnelInfo   (0) : no tunnel information present
  That will make it consistent with the other items.
  This change will require adding RFC to the REFERENCE clause.
1.2  pimBidir   (5) : BIDIR-PIM Tree  [RFC5015]
  RFC5015 needs to be added to the Reference section

2. Page-6: L2L3VpnMcastProviderTunnelType: SYNTAX
  The rewritten SYNTAX clause without the repetitions looks better.
  Thanks.

3. Page-7,8: says
   " A L2L3VpnMcastProviderTunnelType object of value
 noTunnelInfo(0) indicates that the corresponding
 Provider Multicast Service Interface (PMSI) Tunnel
 attribute does not have a Tunnel Identifier."
   It may be better to align the wording with RFC6514 (Page 11)
   ' When the Tunnel Type is set to "No tunnel information
 present", the PMSI Tunnel attribute carries no tunnel
 information (no Tunnel Identifier).'

4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION:
 E: Extension flag [RFC7902]
  RFC7902 needs to be added to the Reference section

5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE
  "RFC6514, Section 5
   RFC7902
  "
  It will be nice to have a section pointer for RFC7902 too.
  (User-friendly and consistency).
  Please check the same for all the REFERENCE clause pointers
6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION
  "When UDP-based S-PMSI signaling is used, the value of
  this object is zero."
   This is actually a 48-bit string. What would be the
   representation of "zero" above be? Will it be a string of
   length 0, a string containing a single ascii character "0"
   6 ascii "0"s, 48 '0' bits ?

7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION:
  "When UDP-based S-PMSI signaling is used, the value of
  this object is zero that indicates the absence of MPLS
  Label."
   Once again.  "zero" above is imprecise.

8. Compliance:
   It would be good to design the compliance module as follows:
  l2L3VpnMcastCoreCompliance:
  MANDATORY-GROUPS {
   l2L3VpnMcastPmsiFieldGroup
  }
  l2L3VpnMcastFullCompliance:
  MANDATORY-GROUPS {
   l2L3VpnMcastPmsiFieldGroup
   l2L3VpnMcastOptionalGroup
  }


General:
10Page-2 Section-1
10.1In BGP/MPLS Virtual Private Networks (VPN)
In BGP/MPLS Virtual Private Networks (VPNs) ?

10.2Throughout this document, we will use the term
"L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support
multicast.

Throughout this document, we will use the term
"L2L3VpnMCast network" to mean a network that comprises of
BGP/MPLS L2 and L3 VPNs and supports multicast.

10.3  Page-4 Section-3 bullet 2
  Please review the paragraph for readability.

10.4  It will be good to avoid page-breaks within quoted clauses.
  example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE



On 2017/08/28 3:27, Hiroshi Tsunoda wrote:

Dear Glenn,

Thank you for your comments and for waiting for the update.
I posted a new revision (-10) as follows.

URL:

https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-10.txt
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10
Htmlized:

https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-10

In the new revision, the following changes are made.
  - Updated the description of following TC and objects
in order to clarify the role of this MIB and to improve
the readability
 -- L2L3VpnMcastProviderTunnelId
 -- l2L3VpnMcastPmsiTunnelAttributeTable
  - Removed some redundant expressions
  - Updated compliance statements

Please see the responses for your comments
in the followings.

2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>:

   L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type
   `L2L3VpnMcastProviderTunnelId' has no format specification
This may be avoided by specifying a format in which the
L2L3VpnMcastProviderTunnelId should be printed.
Is there a preferred format? How will this be printed?
One continuous octet string?


The size and format of TunnelID depends on Tunnel Type.
and no preferred format is exist as of now.
Therefore, I have decided to no

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07

[Glenn Mansfield Keeni]

Dear Tsuno/Zhang,
 > Thank you for your comments. I posted a new revision (-09)
This draft looks good. Thank you very much.

L2L3-VPN-MCAST-TC-MIB is almost OK.
smilint gives warnings
  L2L3-VPN-MCAST-TC-MIB:63: [5] {type-unref} warning: current type
  `L2L3VpnMcastProviderTunnelType' is not referenced in this module
  L2L3-VPN-MCAST-TC-MIB:112: [5] {type-unref} warning: current type
  `L2L3VpnMcastProviderTunnelId' is not referenced in this module
These may be ignored.
  L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type
  `L2L3VpnMcastProviderTunnelId' has no format specification
This may be avoided by specifying a format in which the
L2L3VpnMcastProviderTunnelId should be printed.
Is there a preferred format? How will this be printed?
One continuous octet string?

L2L3-VPN-MCAST-MIB is also syntactically OK.

But before we go on to the next stage could you please confirm that
A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the following
   four MOs as index for its rows
 l2L3VpnMcastPmsiTunnelAttributeFlags,
 l2L3VpnMcastPmsiTunnelAttributeType,
 l2L3VpnMcastPmsiTunnelAttributeLabel,
 l2L3VpnMcastPmsiTunnelAttributeId
   The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate? If yes
   please explain it to me. Or point to the text that contains the
   explanation.
I have been unable to confirm the above from the draft - that is very
likely due to my lack of understanding of the l2L3VpnMcast technology.

Glenn

On 2017/06/22 2:35, Hiroshi Tsunoda wrote:

Dear Glenn,

Thank you for your comments. I posted a new revision (-09) as follows.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-09.txt
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-09
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-09
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-09

In the new revision, all of your comments are addressed and
the following additional changes are made.

-   Update the definition and description of L2L3VpnMcastProviderTunnelType
 Describe the enumerated values and the corresponding
 tunnel type.
 I added new valule, transportTunnel (8) defined in [RFC7524].

  - Add some description related to transportTunnel (8)
into the defi L2L3VpnMcastProviderTunnelId

  - Update the description of l2L3VpnMcastPmsiTunnelAttributeFlags
according to [RFC7902]

  -  Added a new object, l2L3VpnMcastPmsiTunnelAttributeAddlFlags.
 This is defined in [RFC7902]

I also removed some paragraph from 1.1 Terminology section,
because those seem verbose.

Please see some other notes below.

2017-06-05 12:24 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>:

1. The explanations for the size of the identifiers for each tunneling
technology in TC L2L3VpnMcastProviderTunnelId
is nicely done. These are aligned with definitions in rfc6514.
In
noTunnelId (0), -- No tunnel information
is there a specific reason to name it 'noTunnelId' instead of
'noTunnelInfo'.


Fixed.


2. The TCs
L2L3VpnMcastProviderTunnelPointerType, and
L2L3VpnMcastProviderTunnelPointer
Are probably not required. The value of the RowPointer [rfc2579]
object is ' the name of the instance of the first
accessible columnar object in the conceptual row'
So the pointer will explicitly contain the name of the table.
An auxilliary type object to indicate the table name is not
necessary.
   [This is an oversight on my part. I should have noticed this earlier.]


These TCs were removed and related descriptions in other parts
in the document were updated.


Other Editorials:
P-2. Sec-1.
1.   para-1 makes tedious reading. Could this be improved?

2.   "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)"
  The usage of the '/' here is unclear.


Updated.
In the new revision, BGP/MPLS VPN is explained in para-1, and
multicast support in BGP/MPLS Layer 2 and Layer 3 is explained in para-2
separately.


3.   "and L3 VPNs.  Therefore, TCs and MOs defined"
  The context of the 'Therefore' is not clear.


Fixed. I removed the related sentence because it seemed not
required already.


4.   "The are two type"
  Probably s/The/There/ ?


Fixed. Thank you for pointing it out.

-- tsuno

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt

[Glenn Mansfield Keeni]

Hi Tsuno,
   Got this. I will be working on this. It is massive-
40 pages. I hope to get back to you on this by the end
of next week.

Cheers,

Glenn
On 2017/06/07 1:22, Hiroshi Tsunoda wrote:

Hi Glenn,

I posted a new revision (-04) of MVPN-MIB document.
In this revision, "Summary of MIB Module" has been rewritten.
I hope this change improves the readability.

URL:https://www.ietf.org/internet-drafts/draft-ietf-bess-mvpn-mib-04.txt
Htmlized: https://tools.ietf.org/html/draft-ietf-bess-mvpn-mib-04
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-mib-04
Diff:  https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-mib-04

Please see notes below for other changes.

2017-03-01 16:00 GMT+01:00 Hiroshi Tsunoda :

1.  Abstract:
1.2 "In particular, it describes managed objects to configure and/or
 monitor Multicast in MPLS/BGP IP VPNs (MVPN) on a router."
Is this for any router or, a "Provider Edge" router ?
Please fix accordingly.


This point will be fixed in the next revision.


Fixed. "Provide Edge" router is correct.


2.  Introduction
Are the objects "generic" to PIM-MVPN and BGP-MVPN or "common"
to  PIM-MVPN and BGP-MVPN ? Please change accordingly.


This point will be fixed in the next revision.


Fixed. "common" is correct.


2.5 The terminology section is a bit terse. Explaining the terms
that are used, with reference to the protocol documents will
improve readability.
e.g.
 - MVPN, PE, PMSI/tunnels,
 - C-multicast routing exchange protocol (PIM or BGP),
   C-multicast states
 - I-PMSI, S-PMSI, provider tunnels


Partially fixed. I will give more detailed explanation in the next revision.


I have added some more explanation in this revision.


3.  MVPN MIB.
This gives the overview of the MVPN MIB.
The MIB module aims to provide "configuring and/or monitoring"
3.1 In
 "This MIB enables configuring and/or monitoring of MVPNs on PE
 devices: the whole multicast VPN machinery."
"the whole multicast VPN machinery" is very difficult to define.
Please use precisely defined terms.
3.2 In "To represent them,"
"them" seems ambiguous, please clarify.
3.3 The diagram needs some explanation.
What do the boxes represent? Tables ? The labels are meant to be
table names ? The table names do not match the labels.
What do the arrows signify? Please explain.
3.4 The short explanation of the tables could be augmented with some
information on what they represent and an idea of how they will
be used. ( RFC 4382 provides a good example).


I have rewritten "Sec.3.1 Summary of MIB Module".
Eight tables can be categorized into two groups: tables for configuration and
tables for monitoring.
In this revision, the diagram representing the relationship among tables is
divided to two separated diagrams based on the roles of tables.


MIB definitions:
7. Wherever possible, please provide references for objects used in the
MIB. The references will point to specific sections/sub-sections of
RFCs defining the protocol for which the MIB is being designed.


This will be addressed in the next revision.


I have added some references but more are required.
I will keep working on this.


8. MOs.
8.2 mvpnMvrfNumber OBJECT-TYPE
   SYNTAX Unsigned32
   DESCRIPTION
   "The total number of MVRFs that are present on this device,
whether for IPv4, IPv6, or mLDP C-Multicast."
o Please make the description precise. E.g. if it is the sum of
  IPv4 MVRFs, IPv6 MVRFs and mLDP C-Multicast MVRFs state it
  explicitly.
o The expression "present on this device" is used.
  Does "present" imply "configured" MVRFs or "active" MVRFs.
  If it is number of active MVRFs then one would expect that
  the number will vary (increase or decrease). If that is the
  case:
  replace
   SYNTAXUnsigned32
  by
   SYNTAXGauge32


I will try to update description in the next revision.


8.5 mvpnGenOperStatusChange OBJECT-TYPE
SYNTAX  INTEGER { createdMvrf(1),
  deletedMvrf(2),
  modifiedMvrfIpmsiConfig(3),
 modifiedMvrfSpmsiConfig(4)
}
   DESCRIPTION
   "This object describes the last operational change that
o The name does not look right. From the SYNTAX and the DESCRIPTION
  it appears that this is about config or MVRF change rather than
  "OperStatus" change. Please check and fix.
o Please confirm that the values in the row itself will not be changed
  after creation. ( you do not have a 'modifiedMvrfConfig')


The name has been changed into mvpnGenMvrfStatusChange.
The name of the related object (mvpnGenOperStatusChangeTime) has
also been changed into mvpnGenMvrfStatusChangeTime.


8.6 mvpnGenCmcastRouteProtocol OBJECT-TYPE
   MAX-ACCESS

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07

[Glenn Mansfield Keeni]

Dear Tsuno/Zhang,
 Thanks for the good work. The document readability is
vastly improved.
The following are the comments on
draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt

Glenn

0. The MIBs
L2L3-VPN-MCAST-TC-MIB and
L2L3-VPN-MCAST-MIB
   compile OK. There are level-5 warnings
mibs/L2L3-VPN-MCAST-TC-MIB:64: [5] {type-unref} warning: current  
type `L2L3VpnMcastProviderTunnelType' is not referenced in this module
mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-unref} warning: current  
type `L2L3VpnMcastProviderTunnelId' is not referenced in this module
mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-without-format} warning:  
type `L2L3VpnMcastProviderTunnelId' has no format specification
mibs/L2L3-VPN-MCAST-TC-MIB:169: [5] {type-unref} warning: current  
type `L2L3VpnMcastProviderTunnelPointer' is not referenced in this module
mibs/L2L3-VPN-MCAST-TC-MIB:198: [5] {type-unref} warning: current  
type `L2L3VpnMcastProviderTunnelPointerType' is not referenced in this  
module


These may be ignored.

1. The explanations for the size of the identifiers for each tunneling
   technology in TC L2L3VpnMcastProviderTunnelId
   is nicely done. These are aligned with definitions in rfc6514.
   In
   noTunnelId (0), -- No tunnel information
   is there a specific reason to name it 'noTunnelId' instead of
   'noTunnelInfo'.

2. The TCs
   L2L3VpnMcastProviderTunnelPointerType, and
   L2L3VpnMcastProviderTunnelPointer
   Are probably not required. The value of the RowPointer [rfc2579]
   object is ' the name of the instance of the first
   accessible columnar object in the conceptual row'
   So the pointer will explicitly contain the name of the table.
   An auxilliary type object to indicate the table name is not
   necessary.
  [This is an oversight on my part. I should have noticed this earlier.]


Other Editorials:
P-2. Sec-1.
1.   para-1 makes tedious reading. Could this be improved?

2.   "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)"
 The usage of the '/' here is unclear.

3.   "and L3 VPNs.  Therefore, TCs and MOs defined"
 The context of the 'Therefore' is not clear.

4.   "The are two type"
 Probably s/The/There/ ?






On 2017/05/26 21:25, Hiroshi Tsunoda wrote:

Dear Glenn,

Thank you for your thorough review and waiting for the updated.

I posted a new revision taking into account your latest comments.
In the new revision, all of your comments are addressed.
I also revised the draft to improve the readability.

Please see some notes below.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt
Htmlized(1):
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08
Htmlized(2):
https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-08

2017-05-02 14:44 GMT+02:00 Hiroshi Tsunoda <ts...@m.ieice.org>:

2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni <gl...@cysols.com>:

Dear Tsuno/Zhang
  Thanks for waiting. The review of
  draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows.

Glenn

C1. Abstract:
 The draft now defines 2 MIB modules.  Please revise the abstract
 and probably the title of the document too.


Fixed.


C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK.
 (Three {type-unref} warnings are there, may be ignored.)


I have confirmed that the latest version of MIB modules can also be
compiled successfully.


C3. Page 4:
   s/3.  Summary of MIB Module/
 3.  Summary of MIB Modules/


Fixed.


C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION
   s/"Denotes a pointer to the row pertaining to a table entry/
/"This textual convention represents a pointer to a row in
 the table represented by the following object of type
 L2L3VpnMcastProviderTunnelPointerType./


Fixed.


C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION
 The explanation in the last paragraph seems out of place.
 It may be removed.


Fixed.


C6  Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION
 it is unclear when the value 'null(0)' will be used.
 Is this allowed only when the corresponding object of type
 L2L3VpnMcastProviderTunnelPointer has a value that is a
 zero-length string ? If yes, please make that clear.


'null(0)' is the default value and indicates that the corresponding
L2L3VpnMcastProviderTunnelPointer object is not assigned.
In the new revision, this point is described clearly.


C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION
 s/created by a PE router/maintained by a PE router/


Fixed.


C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId
  Do you really want to keep this object in L2L3-VPN-MCAST-MIB.
  It will change every time a new "tunnel type" is added

[bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07

[Glenn Mansfield Keeni]

Dear Tsuno/Zhang
 Thanks for waiting. The review of
 draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows.

Glenn

C1. Abstract:
The draft now defines 2 MIB modules.  Please revise the abstract
and probably the title of the document too.

C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK.
(Three {type-unref} warnings are there, may be ignored.)

C3. Page 4:
  s/3.  Summary of MIB Module/
3.  Summary of MIB Modules/

C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION
  s/"Denotes a pointer to the row pertaining to a table entry/
   /"This textual convention represents a pointer to a row in
the table represented by the following object of type
L2L3VpnMcastProviderTunnelPointerType./

C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION
The explanation in the last paragraph seems out of place.
It may be removed.

C6  Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION
it is unclear when the value 'null(0)' will be used.
Is this allowed only when the corresponding object of type
L2L3VpnMcastProviderTunnelPointer has a value that is a
zero-length string ? If yes, please make that clear.

C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION
s/created by a PE router/maintained by a PE router/

C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId
 Do you really want to keep this object in L2L3-VPN-MCAST-MIB.
 It will change every time a new "tunnel type" is added to
 L2L3VpnMcastProviderTunnelType. That will defeat the purpose
 of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB
 It may be a good idea to define a textual convention like
 L2L3VpnMcastPmsiTunnelAttributeId
 in the L2L3-VPN-MCAST-TC-MIB and use that textual convention
 in the L2L3-VPN-MCAST-MIB

C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION
A.   s/Thus, the size of this object is 16 octets in IPv4/
   Thus, the size of this object is 8 octets in IPv4/
B.   The last 2 paragraphs do not tie up well with the previous
 paragraphs in the DESCRIPTION.
C.   In the last paragraph
 "this object is a pair of source and group IP addresses"
 is unlcear. Please clarify.

C10. Page 15: Security Considerations
 I would think that any field that reveals information about
 a Multicast VPN and/or its members is sensitive.
 Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal
 information about the participating members? If yes, it must
 be marked as sensitive.

C11. Editorial:

A. This does not pertain to the MIBs as such,
   but I am uncomfortable with the  several variations
   of the phrase
   "Layer 2 and Layer 3 Virtual Private Networks (VPN)
that support multicast"
   that appears in the text. I do not have a solution
   on hand but it would be perhaps be more readable to
   define and use a simple name/notation the beast for
   which the MIB is being designed (e.g. "L2L3VPNMCast").

B. Same with the phrase
"Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private
 Network)
it would be probably be easier on the reader if an
abbreviation like L2L3VPNs was used where ever
applicable.

C12. P2:Para4: s/within MIB module specifications//;

C13. General:
A.  The DESCRIPTION clauses could do would some more
packing. (Too much space at the end of lines)
B.  Please check the articles a/an/the once again. Some
usages do not seem right to me.




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni]

auto-discovery (A-D) routes.
> BPG auto-discovery (A-D) routes.
2.  line 102: Typo
< This document defines a textual conventions (TC)
> This document defines a textual convention (TC)
3.  line 134: nit
< A PE uses to send
> A PE uses it to send


Fixed. Thank you very much for pointing these out.

Thanks.

-- tsuno

2017-03-05 16:13 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>:

Dear Tsunoda,

I think that I have addressed all of Glenn's comments in
this revision.

Thanks for addressing the comments. The MIB compiles OK and
is looking good. It is shaping up well.
A new set of comments is attached. Please check and do the

needful.
Glenn
On 2017/02/21 16:50, Hiroshi Tsunoda wrote:


Dear Glenn and BESS WG,

I posted a new revision as follows.
I think that I have addressed all of Glenn's comments in this revision.

In this revision, I have tried to add more detailed explanation
throughout the document.
Please review and let me know if there are any misunderstanding from
technical view points.

URL:

https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-06.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-06
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-06

Please see some notes below.


1.  Introduction

1.1
   Would be very nice if a short explanations of MVPN and
   L2 VPN Multicast were given. With emphasis on the operational
   aspects.



I have updated Introduction. I hope this update fulfills your
requirements.


1.4  there are 2 types of PMSIs ..


  o I-PMSI: Inclusive PMSI - to all PEs in the same VPN.
  o S-PMSI: Selective PMSI - to some of the PEs in the same VPN.



   please make these explanations more gentle(complete) to the reader.
   Also, give the references where these terms are defined.



More gentle explanation and references were added in Terminology
section (Sec.1.1).


3.2 some more text like the following will be good.
L2L3-VPN-MCAST-MIB contains
o a Textual Convention L2L3VpnMcastProviderTunnelType that provides
  an enumeration of the  provider tunnel types and,
o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is
  composed of multiple attributes that depend on the tunnel type and
  uniquely identify a tunnel. This table will be used to ... monitor
  the tunnels supported by the system at a given point of time (?)
  It may also be used in conjunction with -mib to obtain the
  other details of a tunnel by following the row pointer of the
  corresponding tunnel's row in this table.
[ Please treat the above as a template and modify the text as
  appropriate ..]



Fixed in this revision. Please look at  Sec. 3  Summary of MIB Module.


3.3 Since this will become a standard document, please take care of
definitions and notations used in the document.
The notation I/S-PMSI is not defined. If you must use a new
term/notation,  define it before use.



The notation I/S-PMSI is defined in Sec.1.1 now.


4.8


l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE
   SYNTAXSEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry
   MAX-ACCESSnot-accessible
   STATUScurrent
   DESCRIPTION
   "This table is for PMSI Tunnel Attributes (PTAs)
advertised/received in I/S-PSMI Auto-Discovery routes.
The entries may be referred to by I-PMSI or S-PMSI table
entries defined in other MIBs, e.g. mvpnMIB in
[I-D.ietf-bess-mvpn-mib]."



  It would seem that each row in this table is an index for a PTA
  and may contain pointers to rows in tables of other MIB modules
  which may contain more details for the PTA. Is that correct?
  Please reword the DESCRIPTION acordingly.
  Also see comments in 4.15



I have changed DESCRIPTION as follows.

   "An entry of this table corresponds with a
PMSI Tunnel attribute and is created by a PE router
that advertises and receives the attribute.
The entry in the table will be referred by other MIB modules
which are designed for monitoring and/or configuring
both L2 and L3 VPN that support multicast."



4.10-3
  the phrase UDP-based S-PMSI appears here for the first time.
  Somewhere earlier it should be made clear that UDP too may be used
  in signaling.



In Introduction, I have explained that BGP and UDP are used in signaling.


4.13
  l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE


   DESCRIPTION
   "As defined for L2L3VpnMcastProviderTunnelType.
For UDP-based S-PMSI signaling for PIM-MVPN,
this is pim-asm (3), pim-ssm (4), or pim-bidir (5).
For BGP-based I/S-PMSI signaling, this is the Tunnel Type
field in PMSI Tunnel Attribute of the corresponding
I/S-PMSI A-D or Leaf A-D route."


  o Does this description cover all the types? If not, then cover all the

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni]

Pv4  IPv6  (tunneling technology)
--
0 0 noTunnelId (No tunnel information present)
   1224   rsvpP2mp   (RSVP-TE P2MP LSP)
   1729   ldpP2mp(mLDP P2MP LSP)
832   pimSsm (PIM-SSM Tree)


  8/32   pimAsm
  8/32   pimSsm
  8/32   pimBidir
  4/16   ingressReplication



For UDP-based S-PMSI signaling for PIM-MVPN, the first
8 or 32 octets of this attribute are filled with
the provider tunnel (source, group) IPv4/IPv6 addresses.
For BGP-based I/S-PMSI signaling, this is the Tunnel
Identifier field in PMSI Tunnel Attribute of the
corresponding I/S-PMSI A-D route."


  A more generous description of the AttributeID would be good. All the
  cases must be covered. Section 5 of RFC 6514 does it nicely. A simple
  summary would be very nice.


Fixed. I have summarized Section 5 of RFC 6514 here.


4.15
  l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE

   SYNTAXRowPointer
   DESCRIPTION
   "If the tunnel exists in some MIB table, e.g. mplsTunnelTable
[RFC3812], this is the row pointer to it. Otherwise, the
pointer is null."

  I am having problems understanding this. Will help if you can give
  a use case of how this will be used. As of now the intent is unclear.
  A RowPointer cannot be pointing to "some MIB table". It must be
  pointer to a specific row in a specific table. If this is a pointer to
  a row in the mplsTunnelTable spell it out clearly and unambiguously.


I have changed DESCRIPTION as follows.

 "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId
  may be represented as an entry in other table, e.g,
  mplsTunnelTable [RFC3812]. If there is such entry,
  this object will point to the row pertaining to the entry.
  Otherwise, the pointer is null."


5.0

5.  Security Considerations

   TBD


I have rewritten this part according to the guideline described in
RFC4181 Sec.3.4.


6.0

6.  IANA Considerations



 IANA is requested to root MIB objects in the MIB module contained in
 this document under the mib-2 subtree.


   Please Note:
   To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to
   put the definitions in a separate MIB module. That would mean a
   separate  branch in the mib-2 subtree. Then the maintenance of the
   TC can be carried out by some entity ( IANA or, some WG or, whoever is
   responsible for maintaining the TC) independent of other MIB objects.
   If that is the intent you will need to define 2 mib modules and you will
   need to request 2 branches in the mib-2 subtree- one for the module
   containing the L2L3VpnMcastProviderTunnelType TC and another for the
   module containing the l2L3VpnMcastPmsiTunnelAttributeTable.


Now, this document defines following two MIB modules:
   -  the module containing the L2L3VpnMcastProviderTunnelType TC
   -  the module containing the l2L3VpnMcastPmsiTunnelAttributeTable.

-- tsuno

2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>:

Dear Tsunoda,

I will submit the next version within three days.
The next versionbwill address all of remained your
comments.

Great! Looking forward to the revised draft.

Glenn

On 2017/02/18 16:30, Hiroshi Tsunoda wrote:


Dear Glenn,

I am sorry I kept you waiting so long for the revised version, I have
been side tracked by other things.
I will submit the next version within three days. The next version
will address all of remained your comments.
The summary of remained TODOs is shown below.   Please wait a little more
time.
-
1. Add general explanation about MVPN, multicast in VPLS
   Define and explain some technical terms, such as PIM-MVPN,
UDP-based S-PMSI etc.

2. Revise summary of the MIB module

3. Revise MIB definition
   a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable
   b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to
cover all cases.
   c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId
   d. Fix the description of l2L3VpnMcastPmsiTunnelPointer

4. Split the MIB module into two separate modules.

5. Revise security considertations
-

P.S. Update of mvpn-mib-02 will be submitted by the end of this month.

Best regards,

-- tsuno

2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>:


Hi Tsunoda,


I have started to volunteer to help to move this document forward.


Great!


I posted a new revision and addressed all editorial things in
that revision.


   Got this. Looks good.


Please give me some more time for revising other parts,


No problems. Will be looking forward to the revised document.

Glenn


On 2016/12/02 12:12, Hiroshi Tsunoda wrote:



Dear Glenn,

Thanks for your careful review and detailed comments/suggestions.
I have started to volunteer to help to move this document f

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni]

Dear Tsunoda,
> I will submit the next version within three days.
> The next versionbwill address all of remained your
> comments.
Great! Looking forward to the revised draft.

Glenn
On 2017/02/18 16:30, Hiroshi Tsunoda wrote:

Dear Glenn,

I am sorry I kept you waiting so long for the revised version, I have
been side tracked by other things.
I will submit the next version within three days. The next version
will address all of remained your comments.
The summary of remained TODOs is shown below.   Please wait a little more time.
-
1. Add general explanation about MVPN, multicast in VPLS
   Define and explain some technical terms, such as PIM-MVPN,
UDP-based S-PMSI etc.

2. Revise summary of the MIB module

3. Revise MIB definition
   a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable
   b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to
cover all cases.
   c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId
   d. Fix the description of l2L3VpnMcastPmsiTunnelPointer

4. Split the MIB module into two separate modules.

5. Revise security considertations
-

P.S. Update of mvpn-mib-02 will be submitted by the end of this month.

Best regards,

-- tsuno

2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni <gl...@cysols.com>:

Hi Tsunoda,

I have started to volunteer to help to move this document forward.

Great!

I posted a new revision and addressed all editorial things in
that revision.

   Got this. Looks good.

Please give me some more time for revising other parts,

No problems. Will be looking forward to the revised document.

Glenn


On 2016/12/02 12:12, Hiroshi Tsunoda wrote:


Dear Glenn,

Thanks for your careful review and detailed comments/suggestions.
I have started to volunteer to help to move this document forward.
I posted a new revision and addressed all editorial things in that
revision.
Please give me some more time for revising other parts,
in order to be familiar with the context of the original and related
documents.

URL:
https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-05
Diff:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt

Please see some notes below.


0. Abstract.
0.1.


 it describes common managed objects used to configure


   and/or monitor both L2 and L3 VPN Multicast.

There are no writable MOs in this MIB. So it does not look
as though this MIB will be used for configuration directly.
The use case scenario for monitoring is not clear, either.
It appears that the MIB module(s) in this document will be
used by other modules which are designed for monitoring and/
or configuring L2 and L3 VPN Multicast. Please re-examine the
wording.



Fixed.


1.  Introduction

1.1
   Would be very nice if a short explanations of MVPN and
   L2 VPN Multicast were given. With emphasis on the operational
   aspects.



TBD. Please give me some more time to revise.


1.2
   s/referred to MVPN and L2 VPN Multicast respectively/
 referred to as MVPN and L2 VPN Multicast,respectively/



Fixed.


1.3
   s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/.



Fixed.


1.4  there are 2 types of PMSIs ..


  o I-PMSI: Inclusive PMSI - to all PEs in the same VPN.
  o S-PMSI: Selective PMSI - to some of the PEs in the same VPN.



   please make these explanations more gentle(complete) to the reader.
   Also, give the references where these terms are defined.



TBD. Please give me some more time to revise.


3.  Summary of MIB Module
3.1


  Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery


Typo: I/S-PMSI,  (see 3.3 below).



Fixed.


3.2 some more text like the following will be good.
L2L3-VPN-MCAST-MIB contains
o a Textual Convention L2L3VpnMcastProviderTunnelType that provides
  an enumeration of the  provider tunnel types and,
o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is
  composed of multiple attributes that depend on the tunnel type and
  uniquely identify a tunnel. This table will be used to ... monitor
  the tunnels supported by the system at a given point of time (?)
  It may also be used in conjunction with -mib to obtain the
  other details of a tunnel by following the row pointer of the
  corresponding tunnel's row in this table.
[ Please treat the above as a template and modify the text as
  appropriate ..]



TBD. Please give me some more time to revise this point.


3.3 Since this will become a standard document, please take care of
definitions and notations used in the document.
The notation I/S-PMSI is not defined. If you must use a new
term/notation,  define it before use.



TBD. Please give me some more time to revise this point.


4.  Definitions


 IMPORTS
   MODULE-IDENTITY, OBJECT-TYPE, experimen

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni]

Hi,
  Any update on the MIB drafts?
Glenn

On 2016/07/17 23:44, Glenn Mansfield Keeni wrote:

Jeffrey and team,
 Any progress on the MIB matters
(draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt,
 draft-ietf-bess-mvpn-mib-03.txt )?

Glenn
On 2016/06/07 18:39, Glenn Mansfield Keeni wrote:

Hi Jeffrey,
   Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib
document. It took me some time to do this review. But now here it
is. A (near complete) review of
draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps.
   I understand that the Security Considerations section is TBD.

   Glenn

On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote:

Hi Glenn,


-Original Message-
From: Glenn Mansfield Keeni [mailto:gl...@cysols.com]
Sent: Sunday, May 08, 2016 11:02 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Benoit Claise
<bcla...@cisco.com>; EXT - thomas.mo...@orange.com
<thomas.mo...@orange.com>
Cc: Mach Chen <mach.c...@huawei.com>; ops-...@ietf.org; Martin
Vigoureux
<martin.vigour...@nokia.com>; bess@ietf.org; mib-doct...@ietf.org
Subject: Re: [bess] MIBDoc review of
draft-ietf-bess-l2l3-vpn-mcast-mib-
02.txt

Jeffrey,
 > Thanks for your comments. I've addressed most of your comments
 > in the new revision:
Thanks for your cooperation. I will need at least one more revision
with the following comments/recommendations addressed before I will
be able to complete the detailed review. In the following the numbers
refer to the issue numbers in the initial review. The issues that are
addressed and closed are not listed. For brevity, the issue
descriptions have been trimmed. In case of doubts please look at the
response mail appended below.
Hope this helps.


Thanks for your detailed comments/suggestions. I posted a new revision
with the following issues addressed.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt


Status:
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04

Please see some notes below.



Glenn

---

Comments:

1.1
 >  I had thought this would be standard/obvious for all MIB objects -
We will comeback to this time and again, whereever possible make
matters explicit and clear. That will help.
 >  Is it enough to say something similar? For example:
 >  In particular, it describes common managed objects used
 >  to configure and/or monitor both L2 and L3 VPN Multicast.
That is better.


I take it that this is already closed in -03 revision.



2.2
 >  Having said that, I'll explain PMSI a bit further.
PMSI explanation is good.
Please use the same style/format for I-PMSI and S-PMSI.


I think -03 revision already use the same style/format for I-PMSI and
S-PMSI?



2.3
 >  No difference. I was using "Layer 3" or "L3" but it was pointed out
 > that the layer 3 VPN is often referred to IP VPN in other RFCs and I
 > was advised to change it accordingly. Looks like I did not change
all
 > the cases.
 >  On the other hand, I noticed that RFC 4382 does use "Layer 3
VPN" so
 > I'll change it back.
No problems. just make sure that the same expression/notation is used
uniformly.


I take it that this is also addressed in -03 already.


3.
 >  > > 3.  Summary of MIB Module.
 >  > > An overview of the L2L3-VPN-MCAST-MIB will be good- the
 >  > > structure of the MIB, short descriptions of the table(s)
 >  > > including usage of the table(s) for management and/or by
 >  > > other MIB(s).
 >
 >  I had that, but have added one sentence about the only table.
A sentence or two about the textual convention will be good.


Added in -04.


 >  > > 4. MIB syntax checking:
 >  > >smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB
2>L2L3-VPN-MCAST-MIB.txt
 >
 >  I used simpleweb's validation tool but looks like I did not use the
 > strictest level of validation. I've now fixed the following issues
and
 > verified.
Good.
5.
 >  > >
 >  > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally.
 >  > >Wherever possible, provide references for objects used in
 >  > >the MIB. The references will point to specific sections/
 >  > >sub-sections of the RFCs defining the protocol for which the
 >  > >MIB is being designed. It will greatly improve the
readability
 >  > >of the document.
 >
 >  Added.
I would recommend using the REFERENCE clause as in rfs4382 and
improve on it.
Specifically, instead of keeping the reference in the DESCRIPTION
clause move it to a separate REFERENCE clause. The addition of the
section number is an impro

[bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt

[Glenn Mansfield Keeni]

Hi Jeffrey,
   Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib
document. It took me some time to do this review. But now here it
is. A (near complete) review of  
draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps.

   I understand that the Security Considerations section is TBD.

   Glenn

On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote:

Hi Glenn,


-Original Message-
From: Glenn Mansfield Keeni [mailto:gl...@cysols.com]
Sent: Sunday, May 08, 2016 11:02 AM
To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Benoit Claise
<bcla...@cisco.com>; EXT - thomas.mo...@orange.com
<thomas.mo...@orange.com>
Cc: Mach Chen <mach.c...@huawei.com>; ops-...@ietf.org; Martin Vigoureux
<martin.vigour...@nokia.com>; bess@ietf.org; mib-doct...@ietf.org
Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-
02.txt

Jeffrey,
 > Thanks for your comments. I've addressed most of your comments
 > in the new revision:
Thanks for your cooperation. I will need at least one more revision
with the following comments/recommendations addressed before I will
be able to complete the detailed review. In the following the numbers
refer to the issue numbers in the initial review. The issues that are
addressed and closed are not listed. For brevity, the issue
descriptions have been trimmed. In case of doubts please look at the
response mail appended below.
Hope this helps.


Thanks for your detailed comments/suggestions. I posted a new revision with the 
following issues addressed.

URL:
https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/
Htmlized:   
https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-04

Please see some notes below.



Glenn

---

Comments:

1.1
 >  I had thought this would be standard/obvious for all MIB objects -
We will comeback to this time and again, whereever possible make
matters explicit and clear. That will help.
 >  Is it enough to say something similar? For example:
 >  In particular, it describes common managed objects used
 >  to configure and/or monitor both L2 and L3 VPN Multicast.
That is better.


I take it that this is already closed in -03 revision.



2.2
 >  Having said that, I'll explain PMSI a bit further.
PMSI explanation is good.
Please use the same style/format for I-PMSI and S-PMSI.


I think -03 revision already use the same style/format for I-PMSI and S-PMSI?



2.3
 >  No difference. I was using "Layer 3" or "L3" but it was pointed out
 > that the layer 3 VPN is often referred to IP VPN in other RFCs and I
 > was advised to change it accordingly. Looks like I did not change all
 > the cases.
 >  On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so
 > I'll change it back.
No problems. just make sure that the same expression/notation is used
uniformly.


I take it that this is also addressed in -03 already.


3.
 >  > > 3.  Summary of MIB Module.
 >  > > An overview of the L2L3-VPN-MCAST-MIB will be good- the
 >  > > structure of the MIB, short descriptions of the table(s)
 >  > > including usage of the table(s) for management and/or by
 >  > > other MIB(s).
 >
 >  I had that, but have added one sentence about the only table.
A sentence or two about the textual convention will be good.


Added in -04.


 >  > > 4. MIB syntax checking:
 >  > >smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB
2>L2L3-VPN-MCAST-MIB.txt
 >
 >  I used simpleweb's validation tool but looks like I did not use the
 > strictest level of validation. I've now fixed the following issues and
 > verified.
Good.
5.
 >  > >
 >  > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally.
 >  > >Wherever possible, provide references for objects used in
 >  > >the MIB. The references will point to specific sections/
 >  > >sub-sections of the RFCs defining the protocol for which the
 >  > >MIB is being designed. It will greatly improve the readability
 >  > >of the document.
 >
 >  Added.
I would recommend using the REFERENCE clause as in rfs4382 and
improve on it.
Specifically, instead of keeping the reference in the DESCRIPTION
clause move it to a separate REFERENCE clause. The addition of the
section number is an improvement. It is friendlier to the reader.
Note. Same comment for other OBJECTs too.


Oh I missed that. All fixed.


7.1
 >  > > 7.1 CONTACT-INFO
 >  > > Following the conventions (including indentation style) will
 >  &

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt

[Glenn Mansfield Keeni]

Hi Jeffrey,
> By "continuously" do you mean every possible value between 0 and 50?
> With currently defined types, it's not like that; for tunnel types
> potentially defined in the future, they may take any value (who
> knows). It may even go beyond 50.
Yes. The doc will be read as a specification by implementors.
The specifications must be as precise as possible. It it varies
continuously between 0 and 50 then the current description is
correct. RFC 6514 sec 5.  PMSI Tunnel Attribute enumerates the
different cases. It appears that the attribute takes a set of
discrete values. I would recommend that the set of discrete values
must be specified and also explained in the description. This will
also be supplemented by the reference clause.
The object definition will look like
  l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE
 SYNTAXOCTET STRING ( SIZE (0|L1|L2|L3) )
 MAX-ACCESSnot-accessible
 STATUScurrent
 DESCRIPTION
 "Different tunnel types will have different sizes for
  this object.
  For tunnel type 'unconfigured', this will be a zero-length  
string.

  For tunnel type 'rsvpP2mp', this will be  of length 
  Etc.
 "
 REFERENCE
 "RFC 6514 sec 5.  PMSI Tunnel Attribute"
 ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 4 }

> for tunnel types
> potentially defined in the future, they may take any value (who
> knows). It may even go beyond 50.
The MIB is anchored to RFC 6514. It does not explicitly or implicitly  
provision for future tunnel types. It explicitly provisions for only

8 tunnel types. I would recommend that we stick
 to that line.

Glenn

On 2016/05/14 1:14, Jeffrey (Zhaohui) Zhang wrote:

Hi Glenn,

Before I post a new revision, I want to check with you on the following:


 >  > > 8.3   l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE
 >  Depending on the tunnel type, there could be different sizes.
 > Future tunnel types could have other sizes that not specified
 > today. I was thinking to just give a size
 > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible.
 > Is that ok?
I see that you have changed the size upper limit to 50.
If the size varies continuously from 0 to 50 the above description
is correct.
Please confirm, explain and cite appropriate reference. If the size
may change in the future that must be stated too.


By "continuously" do you mean every possible value between 0 and 50? With 
currently defined types, it's not like that; for tunnel types potentially defined in the 
future, they may take any value (who knows). It may even go beyond 50.

Given this, what's the best way to proceed?

Thanks.
Jeffrey



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt

[Glenn Mansfield Keeni]

Hi Mach,
   I have sent the review on  2016/05/09.

On 2016/05/09 0:01, Glenn Mansfield Keeni wrote:
> Jeffrey,
>> Thanks for your comments. I've addressed most of your comments
>> in the new revision:
> Thanks for your cooperation. I will need at least one more revision
> with the following comments/recommendations addressed before I will
> be able to complete the detailed review. In the following the numbers
> refer to the issue numbers in the initial review. The issues that are
> addressed and closed are not listed. For brevity, the issue
> descriptions have been trimmed. In case of doubts please look at the
> response mail appended below.
> Hope this helps.

Glenn

On 2016/05/13 17:22, Mach Chen wrote:

Hi Glenn,

Based on your below response, we assume that you will do a detailed review on 
the mibs, can you estimate when the review will be finished.

Thanks,
Mach


-Original Message-
From: Glenn Mansfield Keeni [mailto:gl...@cysols.com]
Sent: Tuesday, April 19, 2016 6:24 AM
To: Jeffrey (Zhaohui) Zhang; Benoit Claise; EXT - thomas.mo...@orange.com
Cc: Mach Chen; ops-...@ietf.org; Martin Vigoureux; bess@ietf.org
Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt

Jeffrey,
　　Thanks for the update.
Will get back to you after a detailed review is done.

Glenn
On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote:

Glenn,

Thanks for your comments. I've addressed most of your comments in the new

revision:


URL:

https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-03.txt

Status:

https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/

Htmlized:

https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-03

Diff:

https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-03


Please see below.


1.  Abstract:
1.1 A sentence on how the managed objects will be used by
 applications for operations, monitoring and management
 would be good.


I had thought this would be standard/obvious for all MIB objects - the

read-write ones are used to control how a device works, and the read-only ones
are used for monitoring. Do I really need to say it explicitly?


I see RFC 4382 has the following:

This memo defines a portion of the Management Information Base

(MIB)

for use with network management protocols in the Internet community.
In particular, it describes managed objects to configure and/or
monitor Multiprotocol Label Switching Layer-3 Virtual Private
Networks on a Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) supporting this feature.

Is it enough to say something similar? For example:

 In particular, it describes common managed objects used to

configure

 and/or monitor both L2 and L3 VPN Multicast.



2.  Introduction
2.1 Please give the full expansion of the abbreviations
 appearing for the first time.  (PE, VPLS,..)


Fixed.



2.2 The terminology section is a bit terse. Explaining the
 terms that are used, nicely with reference to the protocol
 documents will improve readability.
 e.g.
  - PMSI, I-PMSI, S-PMSI, provider tunnels


As the paragraph alluded to, this MIB needs to be understood in the general

context of L2/L3 multicast VPN and providing good explanation of the terms is
not attempted. The references for the terms are the the RFCs for the relevant
technologies.


Having said that, I'll explain PMSI a bit further.


2.3 Is there a difference between
"multicast in Layer 2 and Layer 3 VPNs , defined by
 RFC 7117 and RFC 6513/6514"
 used in the DESCRIPTION in the MODULE-IDENTITY
 and
"multicast in BGP/MPLS L2 or IP VPN"
 used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ?
 If these are the same, it will be helpful to stick to the
 same expression. If these are not the same, the dictinction
 should be clarified.


No difference. I was using "Layer 3" or "L3" but it was pointed out that the

layer 3 VPN is often referred to IP VPN in other RFCs and I was advised to
change it accordingly. Looks like I did not change all the cases.


On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" so I'll

change it back.





3.  Summary of MIB Module.
 An overview of the L2L3-VPN-MCAST-MIB will be good- the
 structure of the MIB, short descriptions of the table(s)
 including usage of the table(s) for management and/or by
 other MIB(s).


I had that, but have added one sentence about the only table.



MIB definitions:
4. MIB syntax checking:
smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB
2>L2L3-VPN-MCAST-MIB.txt


I used simpleweb's validation tool but looks like I did not use the strictest

level of validation. I've now fixed the following issues and verified.




mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: named

number `rsvp-p2mp' must not inc

Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt

[Glenn Mansfield Keeni]

able, this is the
>>   row pointer to it."
>>  o "some MIB table" : specify which MIB table.
> 
> I can give an example, like mplsTunnelTable [RFC 3812]. It could be whatever 
> table that a tunnel may be put into.
> 
>>  o In what case will the tunnel exist and in what case will it not?
> 
> If a device supports mplsTunnelTable and the tunnel is represented there, 
> then it exists.
> 
>>  o What will be the behaviour if the above condition is not satisfied?
> 
> A null pointer should be given.
> 
>>
>> 8.4  l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE
>>  SYNTAXRowPointer
>>  MAX-ACCESSread-only
>>  STATUScurrent
>>  DESCRIPTION
>>  "If the tunnel has a corresponding interface, this is the
>>   row pointer to the ifName table."
>>   o DESCRIPTION looks incorrect. Please fix it. Do you want to say
>> this object points to the corresponding row in the ifTable?
> 
> Yes. Fixed.
> 
>>   o In what case does the TunnelIf exist and in what case will it not?
> 
> Some tunnels may not have a corresponding interface.
> 
>>   o What will be expected if the tunnel does not have a corresponding
>> interface?
> 
> Null row pointer.
> 
>>
>> 9. The Security Considerations section does not follow the Security
>> Guidelines for IETF MIB Modules
>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security.
>> Please fix.
> 
> I was really hoping that it would not have to be that tedious. SNMP/MIB 
> security should be no different from the CLI security - once you secure the 
> infrastructure then what's more to do?
> 
> I'll need more time to work on this. Let me try to address the issues in the 
> other mib first and come back to this.
> 
>> 
>>
>> 10.ID-nits
>> 10.1 Checking nits according to http://www.ietf.org/id-info/checklist :
>>   
>> ---
>> 
>>   ** There are 4 instances of too long lines in the document, the 
>> longest one
>>  being 3 characters in excess of 72.
> 
> I fixed some but there still three too long lines:
> 
>   l2L3VpnMcastPmsiTunnelAttributeType  L2L3VpnMcastProviderTunnelType,
> 
>l2L3VpnMcastGroups  OBJECT IDENTIFIER ::= {l2L3VpnMcastConformance 1}
>l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= {l2L3VpnMcastConformance 2}
> 
> Should I break them into different lines or just keep them as is? Any example 
> of expected indentation if I break the lines?
> 
>> 
>> 10.2 Checking references for intended status: Proposed Standard
>>   
>> ---
>> 
>>   == Missing Reference: 'RFC 7117' is mentioned on line 76, but not
>>  defined
>>  'described in [RFC6513, RFC6514, RFC 7117] and other documents 
>> tha...'
> 
> I hope I understood and fixed it (removing the space in "RFC 7117").
> 
>>
>> 11.  There is another WIP MVPN-MIB in draft-ietf-bess-mvpn-mib-02.txt
>>   MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB.
>>   Is there a good reason for not merging the 2 documents? I have not seen
>>   any discussion or explanation on this. I may have missed it. Please
>>   clarify or, give some pointers.
> 
> As mentioned in the introduction:
> 
> this memo describes managed objects common to both VPLS
> Multicast [RFC7117] and MVPN [RFC6513, RFC6514].
> 
> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the work and 
> both would reference common objects defined in this MIB.
> 
> Thanks!
> Jeffrey
> 
>> -Original Message-
>> From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Glenn Mansfield
>> Keeni
>> Sent: Tuesday, April 12, 2016 2:28 AM
>> To: Benoit Claise <bcla...@cisco.com>; EXT - thomas.mo...@orange.com
>> <thomas.mo...@orange.com>
>> Cc: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; ops-...@ietf.org; Martin
>> Vigoureux <martin.vigour...@nokia.com>; bess@ietf.org; Mach Chen
>> <mach.c...@huawei.com>
>> Subject: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt
>>
>> Hi,
>> I have been asked to do a MIB Doctors review of
>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt.
>> My knowledge of L2L3VPN Multicast is limited to the reading
>> of this document and browsing through the documents referred
>> to in the draft and bess-wg mailing list archives.( read "shallow").
>> So some of the doubts and questions may sound trivial or
>> strange. Please bear with me and help me help you make
>> this into a better document :-)
>>
>> The comments are attached.
>>
>> Glenn
>>
> 
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
> 

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] MIBDoc review of draft-ietf-bess-mvpn-mib-02.txt

[Glenn Mansfield Keeni]

Hi,
I have been asked to do a MIB Doctors review of
draft-ietf-bess-mvpn-mib-02.txt.

The comments are attached.
You will note that this is preliminary review. There
are some generic comments which apply to all the
scalars and tables. Please take care of those and then
we will get onto the next phase.

Hope this helps.


Glenn

Comments on draft-ietf-bess-mvpn-mib-02.txt
-

This is a preliminary review. Once the following points are 
taken care of, we can get down to a detailed in-depth review. 

1.  Abstract:
1.1 Please give the full expansion of MPLS/BGP
1.2 "In particular, it describes managed objects to configure and/or
 monitor Multicast in MPLS/BGP IP VPNs (MVPN) on a router."
Is this for any router or, a "Provider Edge" router ? 
Please fix accordingly.

2.  Introduction
2.1 PE - appears first time. Please give the full expansion.
2.2 Is the protocol for "exchanging VPN multicast" or 
"exchanging VPN multicast states"? Please fix appropriately.
2.3 The expression "standard MIB" in the following is confusing: 
"This document defines a standard MIB for MVPN-specific 
objects that are generic to both PIM-MVPN and BGP-MVPN."
Is there any special significance in the "standard" above? 
If no, then please drop the word. 
Are the objects "generic" to PIM-MVPN and BGP-MVPN or "common" 
to  PIM-MVPN and BGP-MVPN ? Please change accordingly.
2.4 Please give the full expansion of the abbreviations occuring 
for the first time in the document. (MPLS, L3VPN). 
2.5 The terminology section is a bit terse. Explaining the terms 
that are used, with reference to the protocol documents will 
improve readability.
e.g. 
 - MVPN, PE, PMSI/tunnels, 
 - C-multicast routing exchange protocol (PIM or BGP), 
   C-multicast states
 - I-PMSI, S-PMSI, provider tunnels
  
3.  MVPN MIB.
This gives the overview of the MVPN MIB.
The MIB module aims to provide "configuring and/or monitoring"  
 
3.1 In
"This MIB enables configuring and/or monitoring of MVPNs on PE
devices: the whole multicast VPN machinery."
"the whole multicast VPN machinery" is very difficult to define. 
Please use precisely defined terms. 

3.2 In "To represent them,"
"them" seems ambiguous, please clarify. 


3.3 The diagram needs some explanation.
What do the boxes represent? Tables ? The labels are meant to be
table names ? The table names do not match the labels.
What do the arrows signify? Please explain. 

3.4 The short explanation of the tables could be augmented with some
information on what they represent and an idea of how they will  
be used. ( RFC 4382 provides a good example).
 

MIB definitions:
4. MIB syntax checking:
   smilint -s -e -l 5 mibs/MCAST-VPN-MIB 2>MCAST-VPN-MIB.txt

   mibs/MCAST-VPN-MIB:289: [4] {hyphen-in-label} warning: named number 
`highest-pe-address' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:290: [4] {hyphen-in-label} warning: named number 
`c-root-group-hashing' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:291: [4] {hyphen-in-label} warning: named number 
`ucast-umh-route' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:306: [4] {hyphen-in-label} warning: named number 
`sender-receiver' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:307: [4] {hyphen-in-label} warning: named number 
`receiver-only' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:308: [4] {hyphen-in-label} warning: named number 
`sender-only' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:369: [4] {hyphen-in-label} warning: named number 
`rpt-spt' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:370: [4] {hyphen-in-label} warning: named number 
`spt-only' must not include a hyphen in SMIv2
   mibs/MCAST-VPN-MIB:412: [5] {index-exceeds-too-large} warning: index of row 
`mvpnPmsiConfigEntry' can exceed OID size limit by 398 subidentifier(s)
   mibs/MCAST-VPN-MIB:534: [5] {index-exceeds-too-large} warning: index of row 
`mvpnSpmsiConfigEntry' can exceed OID size limit by 430 subidentifier(s)
   mibs/MCAST-VPN-MIB:649: [5] {index-exceeds-too-large} warning: index of row 
`mvpnIpmsiEntry' can exceed OID size limit by 430 subidentifier(s)
   mibs/MCAST-VPN-MIB:741: [5] {index-exceeds-too-large} warning: index of row 
`mvpnInterAsIpmsiEntry' can exceed OID size limit by 174 subidentifier(s)
   mibs/MCAST-VPN-MIB:810: [5] {index-exceeds-too-large} warning: index of row 
`mvpnSpmsiEntry' can exceed OID size limit by 687 subidentifier(s)
   mibs/MCAST-VPN-MIB:1016: [4] {group-membership} warning: notification 
`mvpnMvrfChange' must be contained in at least one conformance group
   mibs/MCAST-VPN-MIB:1127: [5] {group-unref} warning: current group 
`mvpnPmsiConfigGroup' is not referenced in this module
   mibs/MCAST-VPN-MIB:1211: [5] {group-unref} warning: current group 
`mvpnOptionalGroup' is not referenced in this