Re: [mpls] MIB Dr. Review of draft-ietf-mpls-mldp-mib-04

[Kishore Tiruveedhula <[e-mail]>]

+ mpls wg

I responded to Joan’s comments in the below email and addressed in draft-ietf-mpls-mldp-mib-05.

https://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-mib-05.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dmpls-2Dmldp-2Dmib-2D05.txt&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=ZPmqYIo4rVSr7_Vh6JV2_WbXMnN_nPZJR4FbL_fgWzw&m=HK9HVwZkbtCi5WAylYb3c726dom_uS1SyQ-wlxO08Pc&s=9pmo3jEvMkTRIJwYZMk6jur4cTdciQ9r64tHhyhof9Q&e=>

Thanks,
Kishore

From: Kishore Tiruveedhula <[e-mail]>
Date: Wednesday, June 26, 2019 at 5:17 PM
To: Joan Cucchiara <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: Loa Andersson <[e-mail]>
Subject: Re: MIB Dr. Review of draft-ietf-mpls-mldp-mib-04


Hi Joan,

      Sorry, I didn't get back for the below comments for long time.

I would like to post new version for IETF 105. Before posting new draft, I would like to resolve everything. Please see below inline [Kishore].

Please reply. Thanks a lot for your support.



I attached new version doc. Please let me know if this looks fine ? Appreciate if you can reply asap before IETF 105 submission date  ( July 8th).



Thanks,

Kishore





On 8/6/18, 11:15 AM, "Joan Cucchiara" <[e-mail]> wrote:



    Kishore and authors,





    Thank you for the update.   The draft is in good shape.   The use of

    AUGMENTS helped immensely in understanding the relationship between tables.





    Below are my comments.  Please let me know if you have any

    questions/comments.





    Thanks,



    -Joan







    Comments for mpls-mldp-mib-04.txt



    --------------------------------------------------







    1.  Please fix these compiler warnings.







    W: f(MPLS-MLDP-STD-MIB.my), (1133,9) Duplicate item "mplsMldpP2mpCapable"

    in object-group "mplsMldpScalarsGroup" OBJECTS list



    W: f(MPLS-MLDP-STD-MIB.my), (1142,9) Duplicate item "mplsMldProtLsrCapable"

    in object-group "mplsMldpScalarsGroup" OBJECTS list



    W: f(MPLS-MLDP-STD-MIB.my), (1157,11) Duplicate item

    "mplsMldpSessionStatsNumFecsSent" in object-group "mplsMldpObjectsGroup"

    OBJECTS list



[Kishore] I am using the smilint and getting only below errors where I need code replace YYY with the code given by IANA.

But I am not getting above warnings that you pointed out. Please let me know which MIB compiler are you trying this ? I will do samething.



>smilint  -m -s -l 6 -i namelength-32 ./MPLS-MLDP-STD-MIB

./MPLS-MLDP-STD-MIB:84: [2] {bad-identifier-case} `YYY' should start with a lower case letter

./MPLS-MLDP-STD-MIB:84: [2] {object-identifier-not-prefix} Object identifier element `YYY' name only allowed as first element

./MPLS-MLDP-STD-MIB:31: [2] {module-identity-registration} illegal module identity registration

~/sandbox/mLDP:contrail-ubm-kishoret>



    2) Please use the suggested OID layout in RFC4181, Appendix D.  These

    guidelines specify the following OID Layout for MIBs:







             xxxMIB



             |



             +-- xxxNotifications(0)



             +-- xxxObjects(1)



             +-- xxxConformance(2)



                 |



                 +-- xxxCompliances(1)



                 +-- xxxGroups(2)







    Below is the OID layout for this draft:







       -- notifications







       mplsMldpNotifications OBJECT IDENTIFIER ::= { mplsMldpStdMIB 0 }



       -- tables, scalars



       mplsMldpScalars       OBJECT IDENTIFIER ::= { mplsMldpStdMIB 1 }



       mplsMldpObjects       OBJECT IDENTIFIER ::= { mplsMldpStdMIB 2 }











    mplsMldpConformance   OBJECT IDENTIFIER ::= { mplsMldpStdMIB 3 }



    mplsMldpGroups        OBJECT IDENTIFIER ::= { mplsMldpConformance 1 }



    mplsMldpCompliances   OBJECT IDENTIFIER ::= { mplsMldpConformance 2 }







[Kishore]  Looks like I am following same OID layout, first notifications, objects, conformance and compliance objects. I am not clear what need to be corrected. Can you please clarify ?





    3)  Section 10.2   You mention the mplsXCTable in this section but I don’t

    see it in the MIB itself.  Is it being used in the MIB?





    [Kishore]  The mplsXCTable is defined in the MPLS LSR MIB ( RFC 3813). I am just showing the relationship between LSR MIB and this MIB.





    4) Section 10.3  Relationship to the LDP MIB







    Should explain the relationship to the LDP MIB's  PeerTable and

    SessionTable in this Section.



    [Kishore]  Ok. I added the relationship for these two tables PeerTable & SessionTable





    5) mplsLdpPeerCapability







    Why is this a BITS value?   For example, could p2mp(1) and mp2mp(2)

    both be set?





[Kishore] As there are lot of capabilities, I kept bit value. Please let me know if any other suggestion. If the DUT receives  both p2mp and mp2mp capabilities from the peer, then both will be set.





    Under what circumstances would the value of this object be none(0)?  If the

    value is none(0), can other BITS be set?



     Please clarify.



     [Kishore]  I changed none to default as ”none” might be confusing. The default capability is p2p.



    5).  mplsMldpFecTable -- A few concerns about this table:





    * mplsMldpFecRootAddrType --





    IANA's Address Family Numbers registry is specified, so why is this being

    limited to IPv4 and IPv6 only?



        [Kishore]  The root address is always the Ingress router address. Please let me know which one are you referring the address family ?



         mplsMldpFecRootAddrType        InetAddressType,

         mplsMldpFecRootAddr            InetAddress,







    * mplsMldpFecType and mplsMldpFecOpaqueType



    These 2 types are maintained by  IANA.  I believe a separate MIB Module

    containing TEXTUAL-CONVENTIONs for these objects



    should be added in the IANA considerations section .   (For an example,

    please see  the IANA-GMPLS-TC-MIB



    which is contained in RFC4802.)



    [Kishore]. Ok. I added in the IANA consideration section.





    If there are other Managed Objects which are also associated with

    registries being maintained by IANA, then these should also be included.





    (Once done, then the Future Considerations Section will no longer be

    needed.)







    6) mplsMldpFecBranchStatsTable







    This table is confusing wrt the indexing.



    Could this be made a "sparse augments" to the mplsMldpFecTable?



    (An example of sparse augments is the MplsLdpSessionPeerAddrTable in the



    MPLS-LDP-STD-MIB.)



    I think mplsMldpFecIndex could be used directly?  Then another index



    which has the same value as the mplsOutSegmentIndex?   I am wondering



    though if the Outsegment truly needs to be an index.



    [Kishore] The mplsMldpFecBranchStatsTable represents the nexthop for the fec. There could be multiple nexthops for each fec for flooding the mLDP traffic.



    Will there always be a corresponding



    entry in the MplsOutSegmentTable?  (Is it possible that there are multiple

    downstream LDP sessions which map to the same OutSegment?)



    [Kishore]  Yes. MplsOutSegmentTable shows only label information.  This Branch stats table gives the traffic statistics for mLDP multicast traffic.



    Could mplsOutSegmentPerfDiscontinuityTime be used for the counters?



[Kishore] This only gives Time and doesn’t give traffic stats.



    Why would the following object not have a valid value?



    Does this imply also that the counters are not valid if the LDPIdentifier

    is not valid?



    [Kishore] No. This mplsMLdpFecBranchPeerLdpId   gives additional information of peer LDP ID.



       mplsMLdpFecBranchPeerLdpId          OBJECT-TYPE



          SYNTAX        MplsLdpIdentifier







          DESCRIPTION



               "This object identifies an outgoing branch peer LDP ID for this



               mLDP LSP. Its value is unique within the context of the mLDP LSP