Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Wed, 8 Aug 2012 12:26:03 +0200

Yes Donald, I remember.

I have copied MIB doctors team, cause Joan did the MIB doctor
review, so I want to be sure that she can chime in if she thinks
it should be done different. Also other MIB doctors may have
opinions.

So if I look at your section 6.7 (page 7/8)., then I see:

      isisSystem -

         This table contains information specific to a single instance
         of the IS-IS protocol.  The TRILL IS-IS implementation follows
         the IS-IS MIB module except for the following changes:

            isisLevelType MUST read level 1

            The TRILL IS-IS implementation does not include Level 2.

If I translate that into the MACHINE readable MODULE COMPLIANCE
statement, then that means that in the RBRIDGE MIB module I have
to add one IMPORT statement

       IsisLevel, isisSystemGroup
           FROM ISIS-MIB              -- RFC4444

And then I had to add something to the MODULE-COMPLIANCE.
The new module compliance looks as follows:

   rbridgeCompliance MODULE-COMPLIANCE
          STATUS      current
          DESCRIPTION
              "The compliance statement for support of RBridge
              services."

          MODULE
              MANDATORY-GROUPS {
                  rbridgeBaseGroup,
                  rbridgeBaseNicknameGroup,
                  rbridgeBasePortGroup,
                  rbridgeFdbGroup,
                  rbridgeFibGroup,
                  rbridgeVlanGroup,
                  rbridgeDtreeGroup,
                  rbridgeTrillGroup,
                  rbridgeNotificationGroup
              }

          GROUP   rbridgePortCounterGroup
          DESCRIPTION
              "Implementation of this group is optional."

          GROUP   rbridgeEsadiGroup
          DESCRIPTION
              "Implementation of this group is optional."

          GROUP   rbridgeSnoopingGroup
          DESCRIPTION
              "Implementation of this group is optional."

          MODULE ISIS-MIB
              MANDATORY-GROUPS {
                    isisSystemGroup
              }
              OBJECT isisSysLevelType
              SYNTAX IsisLevel { level1(1) }
              DESCRIPTION
                  "For TRILL, this object only supports level 1
                    and so this object can only have a value of 1."

          ::= { rbridgeCompliances 1 }

For the other descriptions of ISIS MIB topics in section 6.7
you would have to do similar things.

Does that make sense?

Bert

----- Original Message ----- 
From: Donald Eastlake
To: Bert Wijnen
Cc: Anil Rijhsinghani ; Susan Hares
Sent: Wednesday, August 08, 2012 4:31 AM
Subject: TRILL RBridge MIB question from Vancouver

Hi Bert,

As you may remember, I spoke with you about the RBridge MIB at the recent IETF 
meeting in Vancouver. We need some help as the document has been held up for 
some time by Adrian Farrel on the question of a compliance statement for IS-IS 
MIB for TRILL. In particular, as I understand it and we discussed, there are 
groups in the IS-IS MIB that include tables that are not used. Anil 
Rijhstinghani is the principal author at this point and knows more than I do. 
The current posted draft is here:
draft-ietf-trill-rbridge-mib-07

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 9 Aug 2012 08:55:56 -0400

I think Bert's suggestion is a good way to go.

Thanks,
  -Joan

----- Original Message ----- 
From: "Bert Wijnen (IETF)" <[email-masked]>
To: "Donald Eastlake" <[email-masked]>
Cc: "MIB Doctors (E-mail)" <[email-masked]>; "Susan Hares" 
<[email-masked]>; "Anil Rijhsinghani" <[email-masked]>
Sent: Wednesday, August 08, 2012 6:26 AM
Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver

> As you may remember, I spoke with you about the RBridge MIB at the recent 
> IETF meeting in Vancouver. We need some help as the document has been held 
> up for some time by Adrian Farrel on the question of a compliance 
> statement for IS-IS MIB for TRILL. In particular, as I understand it and 
> we discussed, there are groups in the IS-IS MIB that include tables that 
> are not used. Anil Rijhstinghani is the principal author at this point and 
> knows more than I do. The current posted draft is here:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Fri, 10 Aug 2012 10:28:23 +0200

On 8/9/12 4:45 AM, Anil R wrote:
> Things like "isisLevelType must read 1" are not necessary to spell out - the only level in RBridges is level 1, hence a reading of
> the MIB will clearly lead you to report only that level. It's redundant to say don't report other levels, because those levels are
> simply not there in RBridges.

So in section 6.7 I read things like:

       isisSystem -

By the way, I do not see that object in RFC4444.
I think you mean: isisSysLevelType ???

          isisSysProtSupport MUST read zero

             The IP protocols detailed in the IS-IS MIB module are not
             applicable.

          isisSysL2toL2Leaking MUST read FALSE

Specifically the MUST language makes me conclude that this is
mandatory conformance material, and so in my view that DOES require
it to be specified in the MODULE-COMPLIANCE statement(s).

Note also that  isisSysLevelType is a read-write object.
So possibly you ALSO wnat to indocate that it is read-only in your case!!
Have not looked at the other above objects in detail... but apply
similar thoughts.

I will come back on the specification of non mandatory tables in
another email.

Bert

---

From: Anil R <[email-masked]>
Date: Fri, 10 Aug 2012 10:04:18 -0400

Section 6.7 was written by an ex-author who has not been active since the -00 version of the MIB, and that section happens to be the only part of this MIB that I (primary author) did not write. I should have corrected that text section, but I didn't, and someone has correctly pointed out problems in it. That ex-author had little experience with MIBs, or networking in general, so please don't treat that section as normative text. The normative text is in RFC 6325. We need to fix that section and release the long-overdue RBridge MIB. Most of our discussion here is about the IS-IS MIB.

> I think you mean: isisSysLevelType ???

Right, this is what was meant.

>         isisSysProtSupport MUST read zero

This is a perfect example of what I said above about section 6.7. See the definition of isisSysProtSupported from ISIS-MIB below:
    isisSysProtSupported OBJECT-TYPE
        SYNTAX BITS {
                    iso8473 (0),
                    ipv4 (1),
                    ipv6 (2)
                  }
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
            "This attribute contains the set of protocols
             supported by this Intermediate System."
    ::= { isisSysObject 12 }

An RBridge IS-IS instance is not used for IPv4 or IPv6. The object definition does not require these bits to be set. A reading of this object will tell the RBridge MIB implementor that the ipv4 and ipv6 bits should not be set. So, it is unnecessary to mandate that the ipv4 and ipv6 bits MUST NOT be set. The ex-author who wrote the must language lacked the experience to recognize this, and I admittedly should have corrected it. A lot of the other must language is used in similar context.

> So possibly you ALSO wnat to indocate that it is read-only in your case!!

Sure, we can make this read-only, although an implementor with an understanding of TRILL would reject any value other than 1. If I make it read-only then I will not need to mention that it should have a value of 1, as the implementor understands that if they read the TRILL protocol spec.

Regards,
Anil