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

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

So I have had below question during the IETF84 meetings.

I am not sure what the best advise is. I could imagine something aka
putting this in the rbridge MODULE-COMPLIANCE:

          MODULE ISIS-MIB
              MANDATORY-GROUPS {
                    isisSystemGroup
              }
              OBJECT isisSysLevelType
              SYNTAX IsisLevel { level1(1) }
              DESCRIPTION
                  "For TRILL, this object only supports level 1"
              OBJECT isisManAreaAddrExistState
              MIN-ACCESS  not-accessible 
              DESCRIPTION
                  "For TRILL, the isisManAreaAddrTable is not mandatory;
                   so therefor this object is not-accessible."

And sofort.
But I heard that some MIB doctors may not agree to this.
So checking first before I answer to the WG/authors.

Bert

----- Original Message ----- 
From: Anil R 
To: Donald Eastlake ; Bert Wijnen 
Cc: Susan Hares 
Sent: Thursday, August 09, 2012 4:45 AM
Subject: Re: TRILL RBridge MIB question from Vancouver

Bert,

The main question we have is as follows.

In the RFC4444 (IS-IS) implementation of RBridges, the following tables need not be implemented:

>From group isisSystem:
isisManAreaAddrTable
isisAreaAddrTable
isisSumAddrTable
isisRedistributionAddrTable

>From group isisISAdj:
isisISAdjAreaAddrTable
isisISAdjIPAddrTable
isisISAdjProtSuppTable

Specifying that the above tables are not required is all that we need to achieve for RBridges.

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.

The question is how to specify the above tables as not-mandatory, given that they are parts of mandatory groups isisSystem and isisISAdj. Can we simply remove objects defined in those tables from compliance groups isisSystemGroup and isisISAdjGroup (defined in RFC4444, and to be redefined in the RBridge compliance statement)? Even for RBridges, there are some objects in these two groups that are mandatory. I thought compliance is defined at group level in SNMP, hence didn't think that individual tables or objects within a group can go missing in a mandatory group compliance definition. But maybe that's not true, please let me know your thoughts.

Regards,
Anil

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 13 Aug 2012 16:23:56 +0200

Maybe I am too impatient.
But does no-one have an opinion on this?

Bert

On 8/10/12 10:54 AM, Bert Wijnen (IETF) wrote:
> *From:* Anil R <mailto:[email-masked]>
> *To:* Donald Eastlake <mailto:[email-masked]> ; Bert Wijnen <mailto:[email-masked]>
> *Cc:* Susan Hares <mailto:[email-masked]>
> *Sent:* Thursday, August 09, 2012 4:45 AM
> *Subject:* Re: TRILL RBridge MIB question from Vancouver
>
> Bert,
>
> 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.
>
> The question is how to specify the above tables as not-mandatory, given that they are parts of mandatory groups isisSystem and
> isisISAdj. Can we simply remove objects defined in those tables from compliance groups isisSystemGroup and isisISAdjGroup (defined
> in RFC4444, and to be redefined in the RBridge compliance statement)? Even for RBridges, there are some objects in these two groups
> that are mandatory. I thought compliance is defined at group level in SNMP, hence didn't think that individual tables or objects
> within a group can go missing in a mandatory group compliance definition. But maybe that's not true, please let me know your thoughts.
>
> Regards,
> Anil
>
>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Aug 2012 08:26:39 -0700

>> "For TRILL, this object only supports level 1"

This sort of thing is OK

>>                     so therefor this object is not-accessible."

I think this is not correct.
Just split up the OBJECT-GROUP macro into multiple
groups, and include only the groups that need to be
accessible for each conformance level.

>> So checking first before I answer to the WG/authors.

Andy

>> 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
>> The question is how to specify the above tables as not-mandatory, given
>> that they are parts of mandatory groups isisSystem and
>> isisISAdj. Can we simply remove objects defined in those tables from
>> compliance groups isisSystemGroup and isisISAdjGroup (defined
>> in RFC4444, and to be redefined in the RBridge compliance statement)? Even
>> for RBridges, there are some objects in these two groups
>> that are mandatory. I thought compliance is defined at group level in
>> SNMP, hence didn't think that individual tables or objects
>> within a group can go missing in a mandatory group compliance definition.
>> But maybe that's not true, please let me know your thoughts.
>>
>> Regards,
>> Anil
>>
>>
>>

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 13 Aug 2012 10:22:59 -0700

Hi -

> From: "Bert Wijnen (IETF)" <[email-masked]>
> To: "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Monday, August 13, 2012 7:23 AM
> Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver
>

> But does no-one have an opinion on this?

I have problems with both of the DESCRIPTIONs.

....
> > "For TRILL, this object only supports level 1"

The DESCRIPTION is potentially at odds with the SYNTAX.
What is intended?

  A: In TRILL environments, implementations MUST be able to
       support level 1.  (This is what the SYNTAX says, and leaves
       open at least a theoretical possibility that other values 
       permitted by the original object syntax may be observed.)

  B: In TRILL environments, implementations MUST not support
       levels other than 1.  (This is what the DESCRIPTION text
       seems to imply, but the text can be read other ways.)

> >                     so therefor this object is not-accessible."

The logic in the DESCRIPTION text is faulty.   I *think* what they're
trying to say is "The isisManAreaAddrTable is optional for the
purposes of TRILL.  Consequently, support for the 
isisManAreaAddrExistState is optional when the 
isisManAreaAddrTable is not implemented."

The real question is in the background of your request:

> The question is how to specify the above tables as not-mandatory,
> given that they are parts of mandatory groups isisSystem and
> isisISAdj. Can we simply remove objects defined in those tables
> from compliance groups isisSystemGroup and isisISAdjGroup (defined
> in RFC4444, and to be redefined in the RBridge compliance statement)?
> Even for RBridges, there are some objects in these two groups
> that are mandatory. I thought compliance is defined at group level in SNMP,
> hence didn't think that individual tables or objects

I think the question is made overly complicated in the questioner's mind
by looking at it as "remov[ing] objects" or having objects "go missing".
MODULE-COMPLIANCE statements are not negative.  They do *not*
say what is absent; they state what must be supported for a claim of
conformance.  It's especially important to recognize that for read-only
values, there may be no practical way to get an implementation to
produce all of the "contractually possible" values - "supported" does
not guarantee that something will ever happen.

Here's my understanding of the issue:  There are situations where, to
satisfy some use case or another, one needs objects from another
MIB module, but the constellation of objects of interest does not
match an existing MODULE-COMPLIANCE *and* requiring
support of an existing MODULE-COMPLIANCE is seen as
excessively onerous.

If it is realistic and meaningful to implement / deploy this TRILL
RBridge MIB in environments where it is not realistic to require the
ISIS MIB to be fully conformant, I think it would be tider to create
a new MODULE-COMPLIANCE for the ISIS stuff, and use an
applicability statement to relate that to the TRILL RBridge MIB
MODULE-COMPLIANCE(s).

Randy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 14 Aug 2012 11:10:43 +0200

Inline

>         seems to imply, but the text can be read other ways.)

I believe the intend is B. So I can accept that my DESCRIPTION text
may not be clear enough. I'll take your text.

> applicability statement to relate that to the TRILL RBridge MIB

I guess one way to go is to create new OBJECT-GROUPs for the ISIS-MIB
module that do specify those groups that make sense to TRILL MIB.
I was trying to find out if I can define such new OBJECT-GROUPs
outside the ISIS-MIB Module. FOr example, can I define such
OBJECT-GROUPs in the TRILL RBRIDGE-MIB ??
If so, does that mean I have to IMPORT all the objects that I want to
include in those new OBJECT-GROUPs ?
Would become a very long list of IMPORTs I suspect.

Bert

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 14 Aug 2012 11:11:43 +0200

Right. And my question is
How can we most easily do that in the RBRIDGE-MIB module.
See also my response to Randy.

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 14 Aug 2012 13:22:40 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "MIB Doctors (E-mail)" <[email-masked]>
> Sent: Tuesday, August 14, 2012 2:10 AM
...
> may not be clear enough. I'll take your text.

B may be what is intended (I don't know, that's why I asked) but I'm
uncomfortable with prohibiting a system from doing more than
is required - such prohibitions by definition seem to be over-specification,
and are potentially harmful.   Do the designers really intend to prohibit
the systems in which this is deployed from operating at other levels,
whatever that might mean?  The point of conformance material is to
establish the minimum capabilities that an implementation MUST
support, not to limit what it MAY support.

...
> include in those new OBJECT-GROUPs ?

If your tools support doing this, I'd expect them to require IMPORTing
all the objects, since the symbols would otherwise be out of scope.
It seems a useful thing to be able to do, and I can't think of a
good technical motivation for prohibiting it.

> Would become a very long list of IMPORTs I suspect.

None of this should be necessary unless they're creating a new profile / set
of conformance requirements for ISIS-MIB.  If what they *really* mean
is that a bunch of ISIS-MIB features that would not be exercised
in this environment, but they don't expect folks to implement specially-
constrained versions of ISIS-MIB for TRILL, then I don't see the point of
adding this material.  Bottom line:  do they really expect specialized
implementations of ISIS-MIB to be developed for this, or will "off-the-shelf"
ones simply be plugged into these systems?  And if it's the former,
do they really intend to prohibit the latter?

Randy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 15 Aug 2012 09:37:17 +0200

Inline

> support, not to limit what it MAY support.

OK, So they (TRIL WG) has this in a normal (but in my view
normative, using capitalized MUST) text section (6.7) in
their I-D:

          isisLevelType MUST read level 1

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

          isisSysProtSupport MUST read zero

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

          isisSysL2toL2Leaking MUST read FALSE

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

So it seemed to me that such language is best captured in a machine
readable MODULE-COMPLIANCE.
And my reading is that it is B what they want. You may read something
else. Maybe they just went overboard in this section.

> do they really intend to prohibit the latter?

So, again in sect 6.7 they state:

       isisManAreaAddr -

          This subtree is not implemented in TRILL IS-IS.  TRILL IS-IS
          uses a single fixed area address of zero.

       isisAreaAddr -

          This subtree is not implemented in TRILL IS-IS.  TRILL IS-IS
          uses a single fixed area address of zero.

Both these "subtrees" are tables in the the ISIS-MIB and both tables
are part of a single OBJECT-GROUP, namely isisSystemGroup in the ISIS-MIB.
That grour is MANDATORY in all MODULE-COMPLIANCE statements in the
ISIS-MIB module.

So the question is how do they express that in machine readable form.
One suggestion that has been made is that they do in the RBRIDGE-MIB
MODULE COMPLIANCE:

      MODULE ISIS-MIB
      GROUP isisSystemGroup
      DESCRIPTION "Table isisManAreaAddrTable is not needed for rbrdidge"

I guess that works, but it is not really machine readable.
If it were all read-only objects, then I guess it would be fine, but there
are also read-write adn read-create objects.

details:
     draft-ietf-trill-rbridge-mib-07.txt
     RFC4444.txt for the ISIS-MIB

Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 15 Aug 2012 10:37:06 -0700

Hi -

The texts you quoted do make a case for a new MODULE-COMPLIANCE
for ISIS-MIB, but they also point to an interpretation of "not needed" rather
than "prohibited", so I think "MUST NOT" language should be avoided here,
especially if the systems in which this is deployed ever need to do "full"
ISIS for other reasons, in addition to what they support for TRILL.

But I really do wonder whether they're honestly planning to do new ISIS
implementations, rather than leveraging existing code.  Conceptually and
from an implementation perspective, there's a big difference between
implementing a table which is always happens to be empty in a parrticular
environment, and removing the code and instrumentation that makes the
table possible.  This goes for read-create items as well.  It's one thing
to leave in a button that is operationally a no-op in a particular environment,
it's quite another to remove the code that allows the no-op button to be
pressed.   But that's something the folks who are implementing this would
need to address - from here it's just speculation.

Randy

----- Original Message ----- 
> Sent: Wednesday, August 15, 2012 12:37 AM

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 16 Aug 2012 09:11:51 +0200

ANIL,

Pls take a look at the below discussion on MIB doctors
list. Does that help you make up your mind as to how
to ducument and specify the relationships between
rbridge-mib and isis-mib.

Bert

-------- Original Message --------
Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver
Date: Wed, 15 Aug 2012 10:37:06 -0700
From: Randy Presuhn <[email-masked]>
To: MIB Doctors (E-mail) <[email-masked]>

Hi -

Randy