From bertietf@bwijnen.net Wed Aug 8 03:26:06 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1964821F85A5 for ; Wed, 8 Aug 2012 03:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.986 X-Spam-Level: X-Spam-Status: No, score=-98.986 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzoyD5y0npSC for ; Wed, 8 Aug 2012 03:26:05 -0700 (PDT) Received: from relay59.tele2.vuurwerk.nl (relay59.tele2.vuurwerk.nl [62.250.3.59]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1121F8548 for ; Wed, 8 Aug 2012 03:26:02 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1Sz3Sf-0007Sf-0Y; Wed, 08 Aug 2012 12:25:57 +0200 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Donald Eastlake" References: In-Reply-To: Date: Wed, 8 Aug 2012 12:26:03 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: "MIB Doctors \(E-mail\)" , Susan Hares , Anil Rijhsinghani Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 10:26:06 -0000 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 d3e3e3@gmail.com From jcucchiara@mindspring.com Thu Aug 9 05:56:05 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A93621F865E for ; Thu, 9 Aug 2012 05:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glosx41uy0k6 for ; Thu, 9 Aug 2012 05:56:04 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 75FD421F84B5 for ; Thu, 9 Aug 2012 05:56:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LyNbtWMxEx4Gn5NxFaUgjfIPnmg80Q0p+oj3dgQK119Gdej13JAC3JuJxu2tf+jd; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SzSHN-0005mV-IW; Thu, 09 Aug 2012 08:55:57 -0400 Message-ID: <022d01cd762e$515d3ad0$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Bert Wijnen \(IETF\)" , "Donald Eastlake" References: Date: Thu, 9 Aug 2012 08:55:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ffbb417215dfb4796f6ce375e108c9b1cb31c92fc090f552350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: "MIB Doctors \(E-mail\)" , Susan Hares , Anil Rijhsinghani Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:56:05 -0000 I think Bert's suggestion is a good way to go. Thanks, -Joan ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "Donald Eastlake" Cc: "MIB Doctors (E-mail)" ; "Susan Hares" ; "Anil Rijhsinghani" Sent: Wednesday, August 08, 2012 6:26 AM Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver > 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 > d3e3e3@gmail.com > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From bertietf@bwijnen.net Fri Aug 10 01:28:30 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1EC21F862A for ; Fri, 10 Aug 2012 01:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTyLkpeR12YH for ; Fri, 10 Aug 2012 01:28:30 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2841021F85D9 for ; Fri, 10 Aug 2012 01:28:30 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Szka0-00031u-VK; Fri, 10 Aug 2012 10:28:25 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SzkZz-00014h-SQ; Fri, 10 Aug 2012 10:28:24 +0200 Message-ID: <5024C627.8070607@bwijnen.net> Date: Fri, 10 Aug 2012 10:28:23 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Anil R References: <06CCCEE4-EBB9-4DA9-BA24-4EC6D06F7F9A@charter.net> In-Reply-To: <06CCCEE4-EBB9-4DA9-BA24-4EC6D06F7F9A@charter.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120810 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4753227d781e56d6d50f090a6b6543527 Cc: Donald Eastlake , "mib-doctors >> MIB Doctors" , Susan Hares Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 08:28:31 -0000 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 - 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 By the way, I do not see that object in RFC4444. I think you mean: isisSysLevelType ??? 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. 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 bertietf@bwijnen.net Fri Aug 10 01:54:13 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4749A21F8618 for ; Fri, 10 Aug 2012 01:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, TRACKER_ID=2.003, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sNS5FExJcjL for ; Fri, 10 Aug 2012 01:54:12 -0700 (PDT) Received: from relay59.tele2.vuurwerk.nl (relay59.tele2.vuurwerk.nl [62.250.3.59]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB9C21F861A for ; Fri, 10 Aug 2012 01:54:12 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1Szkyw-0004Tq-Cq for mib-doctors@ietf.org; Fri, 10 Aug 2012 10:54:10 +0200 Message-ID: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "MIB Doctors \(E-mail\)" Date: Fri, 10 Aug 2012 10:54:02 +0200 Organization: Consultant MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09B3_01CD76E6.741A78E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Subject: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 08:54:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_09B3_01CD76E6.741A78E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=20 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 -----=20 From: Anil R=20 To: Donald Eastlake ; Bert Wijnen=20 Cc: Susan Hares=20 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 ------=_NextPart_000_09B3_01CD76E6.741A78E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So I have had below question during the IETF84=20 meetings.
 
I am not sure what the best advise is. I could = imagine=20 something aka
putting this in the rbridge=20 MODULE-COMPLIANCE:

          MODULE=20 ISIS-MIB
          &= nbsp;  =20 MANDATORY-GROUPS=20 {
           &n= bsp;       =20 isisSystemGroup
         =     =20 }
           &n= bsp; =20 OBJECT=20 isisSysLevelType
         = ;    =20 SYNTAX IsisLevel { level1(1)=20 }
           &n= bsp; =20 DESCRIPTION
         &nbs= p;       =20 "For TRILL, this object only supports level 1"
           &n= bsp; =20 OBJECT isisManAreaAddrExistState
           &n= bsp;  MIN-ACCESS =20 not-accessible
           &n= bsp; =20 DESCRIPTION
           &n= bsp;     =20 "For TRILL, the isisManAreaAddrTable is not mandatory;
           &n= bsp;       so=20 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 -----=20
From: Anil R =
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=20 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=20 achieve for RBridges.

Things like "isisLevelType must read 1" are not necessary to spell = out -=20 the only level in RBridges is level 1, hence a reading of the MIB will = clearly=20 lead you to report only that level. It's redundant to say don't report = other=20 levels, because those levels are simply not there in RBridges.

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

Regards,
Anil

------=_NextPart_000_09B3_01CD76E6.741A78E0-- From anil@charter.net Fri Aug 10 07:04:16 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE28221F8627 for ; Fri, 10 Aug 2012 07:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnXCo8LKA1lC for ; Fri, 10 Aug 2012 07:04:16 -0700 (PDT) Received: from mta21.charter.net (mta21.charter.net [216.33.127.81]) by ietfa.amsl.com (Postfix) with ESMTP id BDAAF21F8620 for ; Fri, 10 Aug 2012 07:04:15 -0700 (PDT) Received: from imp11 ([10.20.200.11]) by mta21.charter.net (InterMail vM.8.01.05.02 201-2260-151-103-20110920) with ESMTP id <20120810140414.ICFG12025.mta21.charter.net@imp11>; Fri, 10 Aug 2012 10:04:14 -0400 Received: from [192.168.1.106] ([71.10.228.40]) by imp11 with smtp.charter.net id l24E1j00B0sw4rK0524EEV; Fri, 10 Aug 2012 10:04:14 -0400 X-Authority-Analysis: v=1.1 cv=8n69asTuZbMnXn9oCQM8qmqRc2QTO8vVbX5gOB99VVA= c=1 sm=1 a=mYufBPp1sAAA:10 a=yUnIBFQkZM0A:10 a=uxqmlfvtJbLpRWMvzcSYSQ==:17 a=zjU-yFxYeAdoPRyt6aoA:9 a=wPNLvfGTeEIA:10 a=FUHJPXC56rQFvycU4HwA:9 a=_W_S_7VecoQA:10 a=uxqmlfvtJbLpRWMvzcSYSQ==:117 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_653C134C-7D91-497E-9556-76A569AF3567" From: Anil R In-Reply-To: <5024C627.8070607@bwijnen.net> Date: Fri, 10 Aug 2012 10:04:18 -0400 Message-Id: References: <06CCCEE4-EBB9-4DA9-BA24-4EC6D06F7F9A@charter.net> <5024C627.8070607@bwijnen.net> To: Bert Wijnen (IETF) X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Fri, 10 Aug 2012 07:30:40 -0700 Cc: Donald Eastlake , "mib-doctors >> MIB Doctors" , Susan Hares Subject: Re: [MIB-DOCTORS] TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:04:17 -0000 --Apple-Mail=_653C134C-7D91-497E-9556-76A569AF3567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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. On Aug 10, 2012, at 4:28 AM, Bert Wijnen (IETF) wrote: > 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. >=20 > So in section 6.7 I read things like: >=20 > isisSystem - >=20 > 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: >=20 > isisLevelType MUST read level 1 >=20 > By the way, I do not see that object in RFC4444. > I think you mean: isisSysLevelType ??? Right, this is what was meant. >=20 > The TRILL IS-IS implementation does not include Level 2. >=20 > 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." ::=3D { 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. > Note also that isisSysLevelType is a read-write object. > 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 --Apple-Mail=_653C134C-7D91-497E-9556-76A569AF3567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
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 -

=         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

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

Right, this is what was = meant.


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

=         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."
    ::=3D { 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.

Note also = that  isisSysLevelType is a read-write object.
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

= --Apple-Mail=_653C134C-7D91-497E-9556-76A569AF3567-- From bertietf@bwijnen.net Mon Aug 13 07:24:00 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DE721F8752 for ; Mon, 13 Aug 2012 07:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRGxdzNOHa+T for ; Mon, 13 Aug 2012 07:23:59 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E521F8759 for ; Mon, 13 Aug 2012 07:23:59 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T0vYj-00088X-He for mib-doctors@ietf.org; Mon, 13 Aug 2012 16:23:58 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest102.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T0vYj-0008I4-1n for mib-doctors@ietf.org; Mon, 13 Aug 2012 16:23:57 +0200 Message-ID: <50290DFC.5050303@bwijnen.net> Date: Mon, 13 Aug 2012 16:23:56 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "MIB Doctors (E-mail)" References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> In-Reply-To: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120813 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43846a9852e5d2aa500c967bf7183819d Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:24:00 -0000 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: > 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 > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From andy@yumaworks.com Mon Aug 13 08:26:40 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3321F86FC for ; Mon, 13 Aug 2012 08:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZM8VCcMVCVD for ; Mon, 13 Aug 2012 08:26:40 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0709A21F8564 for ; Mon, 13 Aug 2012 08:26:39 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3452334ghb.31 for ; Mon, 13 Aug 2012 08:26:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=d3Oay5NUhaW125OUy/lwv4gosFjg7RqfNscfAz7Ka00=; b=ZXlxJLWv7W6BLYjgD8awWzGFysRkicok8oJymgoyetitK096yndTQGK0wuMG7mlTQD DNoZr9VylxbB8/LUkw7Wy0D5NiM7NHdKOYrrU11k1FOcgc+Gyj7ybKyOsNOchED8IXQh 1G8D/IcyeH+UxAE8ikEL3hZVV/9UdHEwO4EUygXC2L//xSFByqUYu0hCHTJbUHURM5gs JJqdO89YAvrzFdSthmKgagkn8WAjJWRKegrKGArHQ2e/U+FqXq657dlGqOQg6ASdFii4 QrZXqk7JZICMxqfcRbZFt4/lrccpnps2BrsHOIH9XPGVwL+T3/trfai57/frgJgRz0Ai jjSw== MIME-Version: 1.0 Received: by 10.50.95.200 with SMTP id dm8mr5954358igb.60.1344871599259; Mon, 13 Aug 2012 08:26:39 -0700 (PDT) Received: by 10.50.23.2 with HTTP; Mon, 13 Aug 2012 08:26:39 -0700 (PDT) In-Reply-To: <50290DFC.5050303@bwijnen.net> References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> Date: Mon, 13 Aug 2012 08:26:39 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlT6i6FXXWSyHU/vb/pbj5o0cOvno5nrcZUUI3XCazo2TYYjiUopRN0W40Fo+TCgm90s6ys Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 15:26:40 -0000 On Mon, Aug 13, 2012 at 7:23 AM, Bert Wijnen (IETF) wrote: > 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: >> >> 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" This sort of thing is OK >> OBJECT isisManAreaAddrExistState >> MIN-ACCESS not-accessible >> DESCRIPTION >> "For TRILL, the isisManAreaAddrTable is not mandatory; >> 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. >> 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 Andy >> ----- 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 >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From randy_presuhn@mindspring.com Mon Aug 13 10:17:12 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88FB21F86FF for ; Mon, 13 Aug 2012 10:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.491 X-Spam-Level: X-Spam-Status: No, score=-96.491 tagged_above=-999 required=5 tests=[AWL=-4.249, BAYES_00=-2.599, FB_REM_PART=10.357, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb3Ird9jy9wj for ; Mon, 13 Aug 2012 10:17:12 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 318C721F85F3 for ; Mon, 13 Aug 2012 10:17:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MOk1UxtJj/oGF0Bqm1wTVszfpfowH46rpxjr+oK9M3EkxycRoNX3yYJhxlyemn/w; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.239.42] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1T0yGN-0000OC-Pk for mib-doctors@ietf.org; Mon, 13 Aug 2012 13:17:12 -0400 Message-ID: <002401cd7978$4a623940$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> Date: Mon, 13 Aug 2012 10:22:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1cb0da86c4ab6ed09d31c42a80e7e66e7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.239.42 Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:17:13 -0000 Hi - > From: "Bert Wijnen (IETF)" > To: "MIB Doctors (E-mail)" > Sent: Monday, August 13, 2012 7:23 AM > Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver > > Maybe I am too impatient. > But does no-one have an opinion on this? I have problems with both of the DESCRIPTIONs. .... > > DESCRIPTION > > "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.) > > OBJECT isisManAreaAddrExistState > > MIN-ACCESS not-accessible > > DESCRIPTION > > "For TRILL, the isisManAreaAddrTable is not mandatory; > > 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 > within a group can go missing in a mandatory group compliance definition. 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 bertietf@bwijnen.net Tue Aug 14 02:10:49 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD521F859B for ; Tue, 14 Aug 2012 02:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.404 X-Spam-Level: X-Spam-Status: No, score=-97.404 tagged_above=-999 required=5 tests=[AWL=-5.162, BAYES_00=-2.599, FB_REM_PART=10.357, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEuv7YXh0c-r for ; Tue, 14 Aug 2012 02:10:48 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2921F8593 for ; Tue, 14 Aug 2012 02:10:48 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T1D9A-000617-Nx; Tue, 14 Aug 2012 11:10:46 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T1D9A-00008L-H7; Tue, 14 Aug 2012 11:10:44 +0200 Message-ID: <502A1613.1090102@bwijnen.net> Date: Tue, 14 Aug 2012 11:10:43 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Presuhn References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> <002401cd7978$4a623940$6b01a8c0@oemcomputer> In-Reply-To: <002401cd7978$4a623940$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120814 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4fa09603722be916debffb343ceb3e5f4 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:10:49 -0000 Inline On 8/13/12 7:22 PM, Randy Presuhn wrote: > Hi - > >> From: "Bert Wijnen (IETF)" >> To: "MIB Doctors (E-mail)" >> Sent: Monday, August 13, 2012 7:23 AM >> Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver >> > >> Maybe I am too impatient. >> But does no-one have an opinion on this? > > I have problems with both of the DESCRIPTIONs. > > .... >>> DESCRIPTION >>> "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.) > I believe the intend is B. So I can accept that my DESCRIPTION text may not be clear enough. I'll take your text. >>> OBJECT isisManAreaAddrExistState >>> MIN-ACCESS not-accessible >>> DESCRIPTION >>> "For TRILL, the isisManAreaAddrTable is not mandatory; >>> 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 >> within a group can go missing in a mandatory group compliance definition. > > 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). > 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 > Randy > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From bertietf@bwijnen.net Tue Aug 14 02:11:46 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3092E21F86A4 for ; Tue, 14 Aug 2012 02:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePqWoZSpxrEC for ; Tue, 14 Aug 2012 02:11:45 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42B21F8594 for ; Tue, 14 Aug 2012 02:11:45 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T1DA7-00062P-H5; Tue, 14 Aug 2012 11:11:44 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T1DA7-0000CB-CK; Tue, 14 Aug 2012 11:11:43 +0200 Message-ID: <502A164F.9060705@bwijnen.net> Date: Tue, 14 Aug 2012 11:11:43 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andy Bierman References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120814 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd440c0b2e25a9394ba58e106ba9025cad7 Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:11:46 -0000 Right. And my question is How can we most easily do that in the RBRIDGE-MIB module. See also my response to Randy. Bert On 8/13/12 5:26 PM, Andy Bierman wrote: > >>> >>OBJECT isisManAreaAddrExistState >>> >> MIN-ACCESS not-accessible >>> >>DESCRIPTION >>> >>"For TRILL, the isisManAreaAddrTable is not mandatory; >>> >> 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. > > From randy_presuhn@mindspring.com Tue Aug 14 13:16:54 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EDB21E8087 for ; Tue, 14 Aug 2012 13:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.545 X-Spam-Level: X-Spam-Status: No, score=-99.545 tagged_above=-999 required=5 tests=[AWL=3.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW1Q68nWvAYQ for ; Tue, 14 Aug 2012 13:16:53 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id CC32721E8063 for ; Tue, 14 Aug 2012 13:16:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hs8TjpDThEAh1ooXeQi1EYlBHsXiuII7wf3qH1AtK0pYWsLX9hcsWmPcVOgJkUag; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.239.42] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1T1NXo-0000yC-DR for mib-doctors@ietf.org; Tue, 14 Aug 2012 16:16:52 -0400 Message-ID: <002e01cd7a5a$8f325c20$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> <002401cd7978$4a623940$6b01a8c0@oemcomputer> <502A1613.1090102@bwijnen.net> Date: Tue, 14 Aug 2012 13:22:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f11ef28424babc359ccf75e19e5e50888f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.239.42 Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 20:16:54 -0000 Hi - > From: "Bert Wijnen (IETF)" > To: "Randy Presuhn" > Cc: "MIB Doctors (E-mail)" > Sent: Tuesday, August 14, 2012 2:10 AM > Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver ... > > 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.) > > > > I believe the intend is B. So I can accept that my DESCRIPTION text > 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. ... > 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 ? 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 bertietf@bwijnen.net Wed Aug 15 00:37:25 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72821F85C7 for ; Wed, 15 Aug 2012 00:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVVFR6jFVGPj for ; Wed, 15 Aug 2012 00:37:24 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0982A21F84E7 for ; Wed, 15 Aug 2012 00:37:21 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T1YAH-0005Di-Qt; Wed, 15 Aug 2012 09:37:19 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T1YAH-00053O-Lo; Wed, 15 Aug 2012 09:37:17 +0200 Message-ID: <502B51AD.7090908@bwijnen.net> Date: Wed, 15 Aug 2012 09:37:17 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Randy Presuhn References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> <002401cd7978$4a623940$6b01a8c0@oemcomputer> <502A1613.1090102@bwijnen.net> <002e01cd7a5a$8f325c20$6b01a8c0@oemcomputer> In-Reply-To: <002e01cd7a5a$8f325c20$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120815 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd492d2cecc22dd49835f564b0e5b3a86ea Cc: "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 07:37:25 -0000 Inline On 8/14/12 10:22 PM, Randy Presuhn wrote: > Hi - > >> From: "Bert Wijnen (IETF)" >> To: "Randy Presuhn" >> Cc: "MIB Doctors (E-mail)" >> Sent: Tuesday, August 14, 2012 2:10 AM >> Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver > ... >>> 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.) >>> >> >> I believe the intend is B. So I can accept that my DESCRIPTION text >> 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. > 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. > ... >> 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 ? > > 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? > 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 > Randy > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From randy_presuhn@mindspring.com Wed Aug 15 10:31:29 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255C621F84C5 for ; Wed, 15 Aug 2012 10:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVHurvvdkQ-9 for ; Wed, 15 Aug 2012 10:31:28 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id F2DE611E80BA for ; Wed, 15 Aug 2012 10:31:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fyiK0oYCEfzKJj0MCuBLDRuGw6q+LOG60zgYef21boBKUtZbGyK8HFDI++Ez0GL/; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.224.166] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1T1hR2-000390-L0 for mib-doctors@ietf.org; Wed, 15 Aug 2012 13:31:13 -0400 Message-ID: <000601cd7b0c$984b2d20$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "MIB Doctors \(E-mail\)" References: <8E39A9B27F394096A0B7C541450B8CC7@BertLaptop> <50290DFC.5050303@bwijnen.net> <002401cd7978$4a623940$6b01a8c0@oemcomputer> <502A1613.1090102@bwijnen.net> <002e01cd7a5a$8f325c20$6b01a8c0@oemcomputer> <502B51AD.7090908@bwijnen.net> Date: Wed, 15 Aug 2012 10:37:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f15c112ae55c493095829f5c2d2d37437f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.224.166 Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:31:29 -0000 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 ----- > From: "Bert Wijnen (IETF)" > To: "Randy Presuhn" > Cc: "MIB Doctors (E-mail)" > Sent: Wednesday, August 15, 2012 12:37 AM > Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver > > Inline > > On 8/14/12 10:22 PM, Randy Presuhn wrote: > > Hi - > > > >> From: "Bert Wijnen (IETF)" > >> To: "Randy Presuhn" > >> Cc: "MIB Doctors (E-mail)" > >> Sent: Tuesday, August 14, 2012 2:10 AM > >> Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver > > ... > >>> 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.) > >>> > >> > >> I believe the intend is B. So I can accept that my DESCRIPTION text > >> 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. > > > > 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. > > > ... > >> 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 ? > > > > 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? > > > > 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 > > > > Randy > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > From bertietf@bwijnen.net Thu Aug 16 00:12:02 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D937421F8618 for ; Thu, 16 Aug 2012 00:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoPx2po1nIr5 for ; Thu, 16 Aug 2012 00:12:02 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7A21F8568 for ; Thu, 16 Aug 2012 00:11:56 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T1uF9-00066E-0S; Thu, 16 Aug 2012 09:11:49 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest102.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T1uF8-0003p5-NS; Thu, 16 Aug 2012 09:11:46 +0200 Message-ID: <502C9D37.1070206@bwijnen.net> Date: Thu, 16 Aug 2012 09:11:51 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Anil Rijhsinghani , Donald Eastlake , Susan Hares References: <000601cd7b0c$984b2d20$6b01a8c0@oemcomputer> In-Reply-To: <000601cd7b0c$984b2d20$6b01a8c0@oemcomputer> X-Forwarded-Message-Id: <000601cd7b0c$984b2d20$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120816 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b3c8b416493e49c14ddb8903ecdc0a4e Cc: MIB Doctors Subject: [MIB-DOCTORS] Fwd: Re: Fw: TRILL RBridge MIB question from Vancouver X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:12:03 -0000 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 To: MIB Doctors (E-mail) 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 ----- > From: "Bert Wijnen (IETF)" > To: "Randy Presuhn" > Cc: "MIB Doctors (E-mail)" > Sent: Wednesday, August 15, 2012 12:37 AM > Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver > > Inline > > On 8/14/12 10:22 PM, Randy Presuhn wrote: > > Hi - > > > >> From: "Bert Wijnen (IETF)" > >> To: "Randy Presuhn" > >> Cc: "MIB Doctors (E-mail)" > >> Sent: Tuesday, August 14, 2012 2:10 AM > >> Subject: Re: [MIB-DOCTORS] Fw: TRILL RBridge MIB question from Vancouver > > ... > >>> 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.) > >>> > >> > >> I believe the intend is B. So I can accept that my DESCRIPTION text > >> 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. > > > > 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. > > > ... > >> 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 ? > > > > 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? > > > > 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 > > > > Randy > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > _______________________________________________ MIB-DOCTORS mailing list MIB-DOCTORS@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors From venkat.mahalingams@gmail.com Fri Aug 17 13:51:22 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8C11E80DC; Fri, 17 Aug 2012 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBNdTYBV-1ib; Fri, 17 Aug 2012 13:51:21 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7095F11E80E1; Fri, 17 Aug 2012 13:51:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4299956vbb.31 for ; Fri, 17 Aug 2012 13:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fim84srpMfh5Kx7lguCGngBGwNLy92i/Ly2ngS2eR2I=; b=PMNdBEspG8K+muvHJLIN2HmxmOv6U0G3as2IfKsF+x5uDud7G4Lfk1MpKnQkOWOOTW kxGDolWHHTdyaKxoUr88zVke+Frry/XDIPGAZ4CSL+QONiKwhgvliKfgX6Y2oRCkCO0q qm5WNAu8puSx+Kmqzw8tgWDNkvQAxUwIwqC7/AO/cfHoCOYtJDf3+4S12qMRz9KnL3lo DReLgHnwXP31PIWUmyEc6ZMTp/zo+ZIngiIjkIhXUJJvWVEq1/TUOiGfUb+p1vw2o1s/ x2nu8jzjRh2t3bo4YOk3I+F49TEwfm9P6suL+66h/yLFhacMROnTZ0cZAJnbWOYGXCc8 ag1w== MIME-Version: 1.0 Received: by 10.52.98.101 with SMTP id eh5mr3032154vdb.8.1345236679820; Fri, 17 Aug 2012 13:51:19 -0700 (PDT) Received: by 10.220.166.210 with HTTP; Fri, 17 Aug 2012 13:51:19 -0700 (PDT) In-Reply-To: <02c601cd7cb8$06037910$6801a8c0@JoanPC> References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> Date: Fri, 17 Aug 2012 13:51:19 -0700 Message-ID: From: Venkatesan Mahalingam To: Joan Cucchiara , mpls@ietf.org, "MIB Doctors (E-mail)" , mpls-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Nadeau , Kannan KV Sampath , Sam Aldrin Subject: Re: [MIB-DOCTORS] draft-ietf-mpls-tp-te-mib-04.txt review request X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:51:23 -0000 ++ MPLS WG & MIB Drs. Thanks, Venkat. On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara wrote: > Venkat, > > The SMIv2 specifies that once a TC is defined, then the definition cannot > change in the way being > proposed by the draft-ietf-mpls-tp-te-mib-04. > > From RFC2579: > 3.3. Mapping of the DESCRIPTION clause > The DESCRIPTION clause, which must be present, contains a textual > definition of the textual convention, which provides all semantic > definitions necessary for implementation, and should embody any > information which would otherwise be communicated in any ASN.1 > commentary annotations associated with the object. > > > My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this > draft is changing that original definition. > If RFC3811 does not contain "all semantic definitions necessary for > implementation" then the problem is to update RFC3811 > and maybe other associated RFCs as needed, not to propose additional > semantics in draft-ietf-mpls-tp-te-mib. > > The draft is proposing to bifurcate the values and also not use zero for the > MplsExtendedTunnelId, that is not the original > definition of MplsExtendedTunnelId, so why is this draft using > MplsExtendedTunnelId? > > Please include the MIB Dr's on your email because this is a MIB concern and > one which I've had since > before this draft was adopted as a WG document. > > The options are (as I see them): > 1) create a specific MPLS TP table for TP Tunnels (which was originally > proposed by Adrian Farrel) > 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other RFCs > which utilize this TC. > 3) ?? > > Thanks, > -Joan > > > ----- Original Message ----- From: "Venkatesan Mahalingam" > > To: "Joan Cucchiara" > Cc: "Thomas Nadeau" ; "Sam Aldrin" > ; "Kannan KV Sampath" > Sent: Friday, August 17, 2012 2:39 PM > > Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request > > >> Joan, >> >> Thanks for your response. Appreciate your time for reviewing this >> draft. Please find below my response tagged [VM]. >> >> However, I looked over the doc and wanted to let you know that I still >> have >>> >>> the same issue wrt to both SYNTAX and semantic >>> redefinition as before. You cannot narrow the range of values in a >>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId >>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>> you >>> have it as part of allowable values in the SYNTAX. >> >> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >> see any issue to allow zero as the valid value for MplsNodeId. >> >>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>> Unsigned32 and says "may represent an IPv4 address". If (for whatever >>> reason) an >>> operator has configured something in the 1..16777216 (i.e. Local Id) >>> range, >>> for a regular TE Tunnel, that is perfectly legal, right? >> >> [VM] I don't see any implementation which allows non-IP TE tunnel >> source/destination in the range 1..16777216 in MPLS domain, >> if you are not still convinced, we can poll in MPLS WG list to get the >> operators' opinion on this. >> >>> If the answer is Yes, then how would you add TP Tunnels using your draft >>> if >>> an operator has a regular MPLS TE Tunnel configured >>> in the range 1..16777216 without having to ensure that any and all legacy >>> equipment be queried first? >> >> [VM] It is expected to configure MPLS TE tunnels in IP address range >> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >> mode of configuration, then it is expected to clarify in the document >> that how to use MPLS-TE & MPLS-TP tunnel configurations. >> What you are saying is correct only if the legacy equipments use the >> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >> this with the MPLS WG list. >> >> HTH >> >> Thanks, >> Venkat. >> >> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >> wrote: >>> >>> Tom and all, >>> >>> Unfortunately, my linux box is giving me grief this week (and I don't >>> have >>> access to my MIB tools). I'm getting some assistance >>> with it but won't be resolved until (hopefully) during the weekend. >>> >>> However, I looked over the doc and wanted to let you know that I still >>> have >>> the same issue wrt to both SYNTAX and semantic >>> redefinition as before. You cannot narrow the range of values in a >>> DESCRIPTION clause which I see happens in mplsTunnelExtNodeConfigLocalId >>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>> you >>> have it as part of allowable values in the SYNTAX. >>> >>> Whatever is specified in the DESCRIPTION clause for values, should be >>> reflected by the SYNTAX, right? >>> >>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>> Unsigned32 and says "may represent an IPv4 address". If (for whatever >>> reason) an >>> operator has configured something in the 1..16777216 (i.e. Local Id) >>> range, >>> for a regular TE Tunnel, that is perfectly legal, right? >>> >>> >>> MplsExtendedTunnelId ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "A unique identifier for an MPLS Tunnel. This may >>> represent an IPv4 address of the ingress or egress >>> LSR for the tunnel. This value is derived from the >>> Extended Tunnel Id in RSVP or the Ingress Router ID >>> for CR-LDP." >>> REFERENCE >>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>> [RFC3209]. >>> >>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>> SYNTAX Unsigned32(0..4294967295) >>> >>> If the answer is Yes, then how would you add TP Tunnels using your draft >>> if >>> an operator has a regular MPLS TE Tunnel configured >>> in the range 1..16777216 without having to ensure that any and all legacy >>> equipment be queried first? >>> >>> Thanks, >>> -Joan >>> >>> >>> >>> ----- Original Message ----- >>> From: Thomas Nadeau >>> To: Joan Cucchiara >>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>> Sent: Thursday, August 09, 2012 8:58 AM >>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> hi Joan >>> >>> hope you had a great vacation! ;) >>> >>> can you please follow up on the note below when you have a chance? >>> >>> Tom >>> >>> >>> >>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>> wrote: >>> >>> Sam, >>> >>> We are away this week returning on 7/23. Sorry, I can't review the doc >>> until after 7/23 and it will >>> take a few days after that as I'll just be returning from vacation. >>> >>> I glanced at it and see that there are read-write objects in a row (which >>> is >>> read-create) so that's >>> an error which I mentioned before. >>> >>> Have you compiled this with smilint? >>> >>> Thanks, >>> -Joan >>> >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: Sam Aldrin >>> To: Joan Cucchiara >>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>> Sent: Friday, July 13, 2012 9:11 PM >>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>> >>> Hi Joan, >>> >>> Please find the updated MIB document. Apologize for the delay. We plan to >>> publish the doc on Monday as it is the deadline before IETF. Diff file is >>> attached as well. >>> >>> This version addresses all your comments. Highlighting couple of them to >>> make sure you are OK with them >>> >>> 1. W.r.t mplsLocalID as index type, we have removed that using >>> MplsExtendedTunnelId itself. As the value range for this object could >>> have >>> value of non-IP address, we are using it. This will make the indices for >>> the >>> same as TunnelTable. >>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, we >>> added description to use value of non-IP address, which is local ID. >>> >>> I do hope this satisfies the need and not necessitate for a new table >>> altogether for TP. >>> >>> 2. In regards to adding references to TC conventions. We believe, those >>> were >>> added in the reference section. IF we have missed any TC references, >>> could >>> you kindly let us know. >>> >>> Appreciate if you can get back by Monday noon time PST. I know it is a >>> very >>> short time, but appreciate if you could do that. >>> >>> thanks >>> -sam >>> >>> ________________________________ >>> >>> > From aldrin.ietf@gmail.com Fri Aug 17 14:06:49 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A5B11E80E3; Fri, 17 Aug 2012 14:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5gPBX8LCZGG; Fri, 17 Aug 2012 14:06:48 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7472111E80D1; Fri, 17 Aug 2012 14:06:48 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3994824pbb.31 for ; Fri, 17 Aug 2012 14:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cxZ9cgM7g0ZhYBr8pYQERfhhTPSOfxiEJ9e1gjIxyIo=; b=yyjvlE+tEzc1PRT5lp7O7Orxbu2wtlW7Gq5zZEQWrvl40Ic/GMZRkfZzfVw/R4QAXi 9++30xMFoB1ajsqNiGtT8IVIidHfmHEwNz/dEldNc4o9L+fqSs4Vorpvdk8xfky38k/w vavW0BFehLPzKR/OartYqMyWvQuLFbJj0iTJ71Ssvygv2BLjnUUICGS+SA16Llj/o3mj HiXvtdDMY86RXpIl+7m/4XRdIcwPBKhikMrAfBLbxyMWK3R8byRLIAEQehWNTs2WXuqq lSrrwV+jHg0GyYH2+lfBrpfcNWG2gzlim8mb+shLsOHICqL7K+Ml0Q30I6MQmeNYyVMs dw4Q== Received: by 10.68.116.48 with SMTP id jt16mr14481600pbb.101.1345237607405; Fri, 17 Aug 2012 14:06:47 -0700 (PDT) Received: from [192.168.1.9] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id nk3sm5607351pbc.27.2012.08.17.14.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 14:06:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Sam Aldrin In-Reply-To: Date: Fri, 17 Aug 2012 14:06:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> To: Venkatesan Mahalingam X-Mailer: Apple Mail (2.1485) Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:06:49 -0000 Hi Joan, The issue boils down to the range value specified in the DESCRIPTION. If that is removed, does that resolve the concern you raised? Do not think we are restricting not to use '0' in anyway or redefining = the semantics. As the value is local and the intention is to help implementor of the = MIB to choose right value, without conflicting with TE tunnel index, we = added that range. If implementor chooses to use different value = altogether, it is perfectly OK as long as it is in the range of = mplsExtendedTunnelId definition. W.r.t legacy implementation, it is unto the implementor to assign the = right index value to TP tunnel, if it conflicts with TE tunnel index. The example provided could give guidance on what value to use, but will = not MANDATE the usage. In regards to implementing a new table, we have deliberated extensively = among authors and also with implementors. Adding new MIB or table is not = really efficient. Infact, there are already implementations which were = able to support the legacy model as well as new TP tunnels. Unless there = is a compelling reason that MPLS TP tunnel table should have its own = table, which essentially duplicated all of the objects, I am not for = that model. If others in WG feels the need, they can speak up. -sam On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam = wrote: > ++ MPLS WG & MIB Drs. >=20 > Thanks, > Venkat. >=20 > On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara > wrote: >> Venkat, >>=20 >> The SMIv2 specifies that once a TC is defined, then the definition = cannot >> change in the way being >> proposed by the draft-ietf-mpls-tp-te-mib-04. >>=20 >> =46rom RFC2579: >> 3.3. Mapping of the DESCRIPTION clause >> The DESCRIPTION clause, which must be present, contains a textual >> definition of the textual convention, which provides all semantic >> definitions necessary for implementation, and should embody any >> information which would otherwise be communicated in any ASN.1 >> commentary annotations associated with the object. >>=20 >>=20 >> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and = this >> draft is changing that original definition. >> If RFC3811 does not contain "all semantic definitions necessary for >> implementation" then the problem is to update RFC3811 >> and maybe other associated RFCs as needed, not to propose additional >> semantics in draft-ietf-mpls-tp-te-mib. >>=20 >> The draft is proposing to bifurcate the values and also not use zero = for the >> MplsExtendedTunnelId, that is not the original >> definition of MplsExtendedTunnelId, so why is this draft using >> MplsExtendedTunnelId? >>=20 >> Please include the MIB Dr's on your email because this is a MIB = concern and >> one which I've had since >> before this draft was adopted as a WG document. >>=20 >> The options are (as I see them): >> 1) create a specific MPLS TP table for TP Tunnels (which was = originally >> proposed by Adrian Farrel) >> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and = other RFCs >> which utilize this TC. >> 3) ?? >>=20 >> Thanks, >> -Joan >>=20 >>=20 >> ----- Original Message ----- From: "Venkatesan Mahalingam" >> >> To: "Joan Cucchiara" >> Cc: "Thomas Nadeau" ; "Sam Aldrin" >> ; "Kannan KV Sampath" = >> Sent: Friday, August 17, 2012 2:39 PM >>=20 >> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>=20 >>=20 >>> Joan, >>>=20 >>> Thanks for your response. Appreciate your time for reviewing this >>> draft. Please find below my response tagged [VM]. >>>=20 >>> However, I looked over the doc and wanted to let you know that I = still >>> have >>>>=20 >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in = a >>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>=20 >>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>> see any issue to allow zero as the valid value for MplsNodeId. >>>=20 >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>=20 >>> [VM] I don't see any implementation which allows non-IP TE tunnel >>> source/destination in the range 1..16777216 in MPLS domain, >>> if you are not still convinced, we can poll in MPLS WG list to get = the >>> operators' opinion on this. >>>=20 >>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>> equipment be queried first? >>>=20 >>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>> mode of configuration, then it is expected to clarify in the = document >>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>> What you are saying is correct only if the legacy equipments use the >>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>> this with the MPLS WG list. >>>=20 >>> HTH >>>=20 >>> Thanks, >>> Venkat. >>>=20 >>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>> wrote: >>>>=20 >>>> Tom and all, >>>>=20 >>>> Unfortunately, my linux box is giving me grief this week (and I = don't >>>> have >>>> access to my MIB tools). I'm getting some assistance >>>> with it but won't be resolved until (hopefully) during the weekend. >>>>=20 >>>> However, I looked over the doc and wanted to let you know that I = still >>>> have >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in = a >>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>>=20 >>>> Whatever is specified in the DESCRIPTION clause for values, should = be >>>> reflected by the SYNTAX, right? >>>>=20 >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>=20 >>>>=20 >>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A unique identifier for an MPLS Tunnel. This may >>>> represent an IPv4 address of the ingress or egress >>>> LSR for the tunnel. This value is derived from the >>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>> for CR-LDP." >>>> REFERENCE >>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>> [RFC3209]. >>>>=20 >>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>> SYNTAX Unsigned32(0..4294967295) >>>>=20 >>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>> equipment be queried first? >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: Thomas Nadeau >>>> To: Joan Cucchiara >>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>> Sent: Thursday, August 09, 2012 8:58 AM >>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>=20 >>>> hi Joan >>>>=20 >>>> hope you had a great vacation! ;) >>>>=20 >>>> can you please follow up on the note below when you have a chance? >>>>=20 >>>> Tom >>>>=20 >>>>=20 >>>>=20 >>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" = >>>> wrote: >>>>=20 >>>> Sam, >>>>=20 >>>> We are away this week returning on 7/23. Sorry, I can't review = the doc >>>> until after 7/23 and it will >>>> take a few days after that as I'll just be returning from vacation. >>>>=20 >>>> I glanced at it and see that there are read-write objects in a row = (which >>>> is >>>> read-create) so that's >>>> an error which I mentioned before. >>>>=20 >>>> Have you compiled this with smilint? >>>>=20 >>>> Thanks, >>>> -Joan >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ----- >>>> From: Sam Aldrin >>>> To: Joan Cucchiara >>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>> Sent: Friday, July 13, 2012 9:11 PM >>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>=20 >>>> Hi Joan, >>>>=20 >>>> Please find the updated MIB document. Apologize for the delay. We = plan to >>>> publish the doc on Monday as it is the deadline before IETF. Diff = file is >>>> attached as well. >>>>=20 >>>> This version addresses all your comments. Highlighting couple of = them to >>>> make sure you are OK with them >>>>=20 >>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>> MplsExtendedTunnelId itself. As the value range for this object = could >>>> have >>>> value of non-IP address, we are using it. This will make the = indices for >>>> the >>>> same as TunnelTable. >>>> In the definition of IngressLSRId and and EgressLSRId, for TP = entries, we >>>> added description to use value of non-IP address, which is local = ID. >>>>=20 >>>> I do hope this satisfies the need and not necessitate for a new = table >>>> altogether for TP. >>>>=20 >>>> 2. In regards to adding references to TC conventions. We believe, = those >>>> were >>>> added in the reference section. IF we have missed any TC = references, >>>> could >>>> you kindly let us know. >>>>=20 >>>> Appreciate if you can get back by Monday noon time PST. I know it = is a >>>> very >>>> short time, but appreciate if you could do that. >>>>=20 >>>> thanks >>>> -sam >>>>=20 >>>> ________________________________ >>>>=20 >>>>=20 >>=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jcucchiara@mindspring.com Sun Aug 19 06:42:52 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3910721F8459; Sun, 19 Aug 2012 06:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXcQRCEFeNxv; Sun, 19 Aug 2012 06:42:51 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id CA42B21F8458; Sun, 19 Aug 2012 06:42:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cDXM7cc3YYfbflwXcipJWlGxWrVoPoANhv0A8CywCuIcLDraq0l1VNjhr8oAEOdP; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1T35mD-0002ma-JC; Sun, 19 Aug 2012 09:42:49 -0400 Message-ID: <04c801cd7e10$3c45b430$6801a8c0@JoanPC> From: "Joan Cucchiara" To: "Sam Aldrin" , "Venkatesan Mahalingam" References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> Date: Sun, 19 Aug 2012 09:40:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26545b6e7e11005fc7b4ace4b1fb2318649910ec827ca34601a1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 13:42:52 -0000 > Hi Joan, > > The issue boils down to the range value specified in the DESCRIPTION. > If that is removed, does that resolve the concern you raised? Sam, I think that depends on how the new DESCRIPTION clause is worded. This DESCRIPTION was brought up as a MAJOR concern and the authors agreed to reword it for 04, but that was not done. Please see inline below. > Do not think we are restricting not to use '0' in anyway or redefining the > semantics. > > As the value is local and the intention is to help implementor of the MIB > to > choose right value, without conflicting with TE tunnel index, we added > that > range. If implementor chooses to use different value altogether, it is > perfectly OK as long as it is in the range of mplsExtendedTunnelId > definition. So why was the above (extremely helpful) information not included as part of the DESCRIPTION clause? The object is: mplsTunnelExtNodeConfigLocalId OBJECT-TYPE SYNTAX MplsExtendedTunnelId MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object is used in accommodating the bigger size Global_Node_ID and/or ICC with lower size LSR identifier in order to index the mplsTunnelTable. The Local Identifier is configured between 1 and 16777215, as valid IP address range starts from 16777216(01.00.00.00). This range is chosen to identify the mplsTunnelTable's Ingress/Egress LSR-id is IP address or Local identifier, if the configured range is not IP address, administrator is expected to retrieve the complete information (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. This way, existing mplsTunnelTable is reused for bidirectional tunnel extensions for MPLS based transport networks. This Local Identifier allows the administrator to assign a unique identifier to map Global_Node_ID and/or ICC." ::= { mplsTunnelExtNodeConfigEntry 1 } No where in the DESCRIPTION does it say this is a "hint" to the operator (you say implementor, but think you mean the operator, i.e. the person that configures this MIB table.) > W.r.t legacy implementation, it is unto the implementor to assign the > right > index value to TP tunnel, if it conflicts with TE tunnel index. Yes, but the draft says in Section 9. "Do note that a MPLS-TP tunnel could be setup statically as well as signaled via control plane." so if the tunnel is signaled, then what happens? Are there entries created in these tables by the local management subsystem (e.g. agent) when the MPLS TP tunnel is signaled successfully OR are entries entirely dependent on an operator for configuration? As far as I can tell, the MIB does not support signaled TP tunnels, is this correct? If so, that needs to be clearly stated, particularly in the Abstract. If I am wrong and it does support signaled TP Tunnels then, how does that work with mapping tables? While there is an example for statically configured tunnels, I don't see one for Signaled TP Tunnels. > The example provided could give guidance on what value to use, but will > not > MANDATE the usage. > > In regards to implementing a new table, we have deliberated extensively > among authors and also with implementors. Adding new MIB or table is not > really efficient. Infact, there are already implementations which were > able > to support the legacy model as well as new TP tunnels. Unless there is a > compelling reason that MPLS TP tunnel table should have its own table, > which > essentially duplicated all of the objects, I am not for that model. If > others in WG feels the need, they can speak up. I'd like to see the new DESCRIPTION clause and understand about MPLS TP signaled tunnels wrt to this draft, prior to delving into the above (and other issues). Thanks, -Joan On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam wrote: > ++ MPLS WG & MIB Drs. > > Thanks, > Venkat. > > On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara > wrote: >> Venkat, >> >> The SMIv2 specifies that once a TC is defined, then the definition cannot >> change in the way being >> proposed by the draft-ietf-mpls-tp-te-mib-04. >> >> From RFC2579: >> 3.3. Mapping of the DESCRIPTION clause >> The DESCRIPTION clause, which must be present, contains a textual >> definition of the textual convention, which provides all semantic >> definitions necessary for implementation, and should embody any >> information which would otherwise be communicated in any ASN.1 >> commentary annotations associated with the object. >> >> >> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and this >> draft is changing that original definition. >> If RFC3811 does not contain "all semantic definitions necessary for >> implementation" then the problem is to update RFC3811 >> and maybe other associated RFCs as needed, not to propose additional >> semantics in draft-ietf-mpls-tp-te-mib. >> >> The draft is proposing to bifurcate the values and also not use zero for >> the >> MplsExtendedTunnelId, that is not the original >> definition of MplsExtendedTunnelId, so why is this draft using >> MplsExtendedTunnelId? >> >> Please include the MIB Dr's on your email because this is a MIB concern >> and >> one which I've had since >> before this draft was adopted as a WG document. >> >> The options are (as I see them): >> 1) create a specific MPLS TP table for TP Tunnels (which was originally >> proposed by Adrian Farrel) >> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and other >> RFCs >> which utilize this TC. >> 3) ?? >> >> Thanks, >> -Joan >> >> >> ----- Original Message ----- From: "Venkatesan Mahalingam" >> >> To: "Joan Cucchiara" >> Cc: "Thomas Nadeau" ; "Sam Aldrin" >> ; "Kannan KV Sampath" >> Sent: Friday, August 17, 2012 2:39 PM >> >> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >> >> >>> Joan, >>> >>> Thanks for your response. Appreciate your time for reviewing this >>> draft. Please find below my response tagged [VM]. >>> >>> However, I looked over the doc and wanted to let you know that I still >>> have >>>> >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in >>>> mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>> >>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I don't >>> see any issue to allow zero as the valid value for MplsNodeId. >>> >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for >>>> whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>> >>> [VM] I don't see any implementation which allows non-IP TE tunnel >>> source/destination in the range 1..16777216 in MPLS domain, >>> if you are not still convinced, we can poll in MPLS WG list to get the >>> operators' opinion on this. >>> >>>> If the answer is Yes, then how would you add TP Tunnels using your >>>> draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all >>>> legacy >>>> equipment be queried first? >>> >>> [VM] It is expected to configure MPLS TE tunnels in IP address range >>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>> mode of configuration, then it is expected to clarify in the document >>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>> What you are saying is correct only if the legacy equipments use the >>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's close >>> this with the MPLS WG list. >>> >>> HTH >>> >>> Thanks, >>> Venkat. >>> >>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>> wrote: >>>> >>>> Tom and all, >>>> >>>> Unfortunately, my linux box is giving me grief this week (and I don't >>>> have >>>> access to my MIB tools). I'm getting some assistance >>>> with it but won't be resolved until (hopefully) during the weekend. >>>> >>>> However, I looked over the doc and wanted to let you know that I still >>>> have >>>> the same issue wrt to both SYNTAX and semantic >>>> redefinition as before. You cannot narrow the range of values in a >>>> DESCRIPTION clause which I see happens in >>>> mplsTunnelExtNodeConfigLocalId >>>> and maybe in MplsNodeId TC as it says zero must not be used, but then >>>> you >>>> have it as part of allowable values in the SYNTAX. >>>> >>>> Whatever is specified in the DESCRIPTION clause for values, should be >>>> reflected by the SYNTAX, right? >>>> >>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>> Unsigned32 and says "may represent an IPv4 address". If (for >>>> whatever >>>> reason) an >>>> operator has configured something in the 1..16777216 (i.e. Local Id) >>>> range, >>>> for a regular TE Tunnel, that is perfectly legal, right? >>>> >>>> >>>> MplsExtendedTunnelId ::= TEXTUAL-CONVENTION >>>> STATUS current >>>> DESCRIPTION >>>> "A unique identifier for an MPLS Tunnel. This may >>>> represent an IPv4 address of the ingress or egress >>>> LSR for the tunnel. This value is derived from the >>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>> for CR-LDP." >>>> REFERENCE >>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>> [RFC3209]. >>>> >>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>> SYNTAX Unsigned32(0..4294967295) >>>> >>>> If the answer is Yes, then how would you add TP Tunnels using your >>>> draft >>>> if >>>> an operator has a regular MPLS TE Tunnel configured >>>> in the range 1..16777216 without having to ensure that any and all >>>> legacy >>>> equipment be queried first? >>>> >>>> Thanks, >>>> -Joan >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Thomas Nadeau >>>> To: Joan Cucchiara >>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>> Sent: Thursday, August 09, 2012 8:58 AM >>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>> >>>> hi Joan >>>> >>>> hope you had a great vacation! ;) >>>> >>>> can you please follow up on the note below when you have a chance? >>>> >>>> Tom >>>> >>>> >>>> >>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" >>>> >>>> wrote: >>>> >>>> Sam, >>>> >>>> We are away this week returning on 7/23. Sorry, I can't review the >>>> doc >>>> until after 7/23 and it will >>>> take a few days after that as I'll just be returning from vacation. >>>> >>>> I glanced at it and see that there are read-write objects in a row >>>> (which >>>> is >>>> read-create) so that's >>>> an error which I mentioned before. >>>> >>>> Have you compiled this with smilint? >>>> >>>> Thanks, >>>> -Joan >>>> >>>> >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> From: Sam Aldrin >>>> To: Joan Cucchiara >>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>> Sent: Friday, July 13, 2012 9:11 PM >>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>> >>>> Hi Joan, >>>> >>>> Please find the updated MIB document. Apologize for the delay. We plan >>>> to >>>> publish the doc on Monday as it is the deadline before IETF. Diff file >>>> is >>>> attached as well. >>>> >>>> This version addresses all your comments. Highlighting couple of them >>>> to >>>> make sure you are OK with them >>>> >>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>> MplsExtendedTunnelId itself. As the value range for this object could >>>> have >>>> value of non-IP address, we are using it. This will make the indices >>>> for >>>> the >>>> same as TunnelTable. >>>> In the definition of IngressLSRId and and EgressLSRId, for TP entries, >>>> we >>>> added description to use value of non-IP address, which is local ID. >>>> >>>> I do hope this satisfies the need and not necessitate for a new table >>>> altogether for TP. >>>> >>>> 2. In regards to adding references to TC conventions. We believe, those >>>> were >>>> added in the reference section. IF we have missed any TC references, >>>> could >>>> you kindly let us know. >>>> >>>> Appreciate if you can get back by Monday noon time PST. I know it is a >>>> very >>>> short time, but appreciate if you could do that. >>>> >>>> thanks >>>> -sam >>>> >>>> ________________________________ >>>> >>>> >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From aldrin.ietf@gmail.com Tue Aug 21 12:10:32 2012 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0021F8760; Tue, 21 Aug 2012 12:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D53Ka2i8h+L; Tue, 21 Aug 2012 12:10:31 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E22F621F86C8; Tue, 21 Aug 2012 12:10:30 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so331743pbb.31 for ; Tue, 21 Aug 2012 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=RUbxyd2BicBG8ZrfF9/TD9kxGcB5jcq9nsL9JND/+2U=; b=FCZoHPavZszsG16E8g+yGlmBGqxvXPRmq1eyZG6jOSBVyeR31VwY6resHqKEaHPxRx TzNYCTVlKT2IxA2qY/bgilD/HbAi+1Fd5k75hqoDbR36r+Y8JKuhR/76FoPCAS2mYlzl vYlMfUDKpHTTQ95sH9hiGemGunrb4+vNLsNNrb+DQTgOx88kb0pmsliSoFBjWfTV74AO RoAhSLsbwwubGGV3GW2VKCDSS77uCU9ClIvo6Bk06xtg8axFxoldXNbT3PRIo9tqpy8a IouWgcs1IzMy9CgK//KWhxR2YJQsPEJ2eCnanKvUvm/o/3iGMQnePH5IYROaqTvAnP3F DM8A== Received: by 10.68.235.68 with SMTP id uk4mr46195895pbc.52.1345576230395; Tue, 21 Aug 2012 12:10:30 -0700 (PDT) Received: from [192.168.255.58] ([12.207.18.42]) by mx.google.com with ESMTPS id vd4sm1980425pbc.41.2012.08.21.12.10.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 12:10:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <04c801cd7e10$3c45b430$6801a8c0@JoanPC> Date: Tue, 21 Aug 2012 12:10:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <822F81DC-E52A-4C33-BA4E-52A213E70A02@gmail.com> References: <056101cd6354$c9deb1b0$6801a8c0@JoanPC> <5257BD19-4A53-4767-9BAB-6C2AB2032846@lucidvision.com> <026f01cd7c9c$b7224030$6801a8c0@JoanPC> <02c601cd7cb8$06037910$6801a8c0@JoanPC> <2E7490DB-3DE7-42C8-8E43-7378A76C2B4C@gmail.com> <04c801cd7e10$3c45b430$6801a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1485) Cc: Venkatesan Mahalingam , mpls@ietf.org, mpls-chairs@tools.ietf.org, Sam Aldrin , "MIB Doctors \(E-mail\)" Subject: Re: [MIB-DOCTORS] [mpls] draft-ietf-mpls-tp-te-mib-04.txt review request X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 19:10:32 -0000 Hi Joan, Thanks for the email. Sorry for the delayed email. Was on PTO. Please find my comments inline. thanks -sam On Aug 19, 2012, at 6:40 AM, Joan Cucchiara = wrote: >> Hi Joan, >>=20 >> The issue boils down to the range value specified in the DESCRIPTION. >> If that is removed, does that resolve the concern you raised? >=20 > Sam, >=20 > I think that depends on how the new DESCRIPTION clause is worded. > This DESCRIPTION was brought up as a MAJOR concern and > the authors agreed to reword it for 04, but that was not done. >=20 > Please see inline below. >=20 >> Do not think we are restricting not to use '0' in anyway or = redefining the >> semantics. >>=20 >> As the value is local and the intention is to help implementor of the = MIB to >> choose right value, without conflicting with TE tunnel index, we = added that >> range. If implementor chooses to use different value altogether, it = is >> perfectly OK as long as it is in the range of mplsExtendedTunnelId >> definition. >=20 > So why was the above (extremely helpful) information not included as = part of the > DESCRIPTION clause? Yes, it should have been. We will send a new text for the description = for review, which will reflect what we were discussing. Hopefully, that = will remove the confusion. >=20 > The object is: > mplsTunnelExtNodeConfigLocalId OBJECT-TYPE > SYNTAX MplsExtendedTunnelId > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This object is used in accommodating the bigger > size Global_Node_ID and/or ICC with lower size LSR > identifier in order to index the mplsTunnelTable. >=20 > The Local Identifier is configured between 1 and 16777215, > as valid IP address range starts from 16777216(01.00.00.00). > This range is chosen to identify the mplsTunnelTable's > Ingress/Egress LSR-id is IP address or Local identifier, > if the configured range is not IP address, administrator is > expected to retrieve the complete information > (Global_Node_ID or ICC) from mplsTunnelExtNodeConfigTable. > This way, existing mplsTunnelTable is reused for > bidirectional > tunnel extensions for MPLS based transport networks. >=20 > This Local Identifier allows the administrator to assign > a unique identifier to map Global_Node_ID and/or ICC." > ::=3D { mplsTunnelExtNodeConfigEntry 1 } >=20 >=20 > No where in the DESCRIPTION does it say this is a "hint" to the = operator (you say > implementor, but think you mean the operator, i.e. the person that = configures this MIB table.) Agree.=20 When I say implementor, I was implying in the case of signaled, where = the localID to be derived. Operator is also right term when the tunnel = is configured statically. New description will provide right details in = the case of static and control plane signaled TP tunnels. >=20 >=20 >> W.r.t legacy implementation, it is unto the implementor to assign the = right >> index value to TP tunnel, if it conflicts with TE tunnel index. >=20 >=20 > Yes, but the draft says in Section 9. "Do note that a MPLS-TP tunnel = could be setup statically as well as > signaled via control plane." so if the tunnel is signaled, then what = happens? Are there entries > created in these tables by the local management subsystem (e.g. agent) = when the MPLS TP tunnel is signaled > successfully OR are entries entirely dependent on an operator for = configuration? When signaled, the local agent will create those entries. It needs to = derive the localID, which is unique only on the local system as it is = locally significant. In order not to conflict with legacy TE = implementation, we 'suggest' to use the value which is below valid IP = address value.=20 >=20 > As far as I can tell, the MIB does not support signaled TP tunnels, = is this correct? > If so, that needs to be clearly stated, particularly in the Abstract. That is not correct. It does support. We never restricted the MIB to = static TP tunnels only. We will add explicit statement in the abstract = to remove the confusion. >=20 > If I am wrong and it does support signaled TP Tunnels then, how does = that work with mapping tables? > While there is an example for statically configured tunnels, I don't = see one for Signaled TP Tunnels. As I mentioned above, the local ID is derived as in the given example. = If needed, we can add more text or details in the example section, w.r.t = signaled vs static. >=20 >=20 >> The example provided could give guidance on what value to use, but = will not >> MANDATE the usage. >>=20 >> In regards to implementing a new table, we have deliberated = extensively >> among authors and also with implementors. Adding new MIB or table is = not >> really efficient. Infact, there are already implementations which = were able >> to support the legacy model as well as new TP tunnels. Unless there = is a >> compelling reason that MPLS TP tunnel table should have its own = table, which >> essentially duplicated all of the objects, I am not for that model. = If >> others in WG feels the need, they can speak up. >=20 >=20 > I'd like to see the new DESCRIPTION clause and understand about MPLS = TP signaled > tunnels wrt to this draft, prior to delving into the above (and other = issues). Will send the new text for review, soon. If you have other issues, = please do let us know. -sam >=20 > Thanks, > -Joan >=20 > On Aug 17, 2012, at 1:51 PM, Venkatesan Mahalingam = wrote: >=20 >> ++ MPLS WG & MIB Drs. >>=20 >> Thanks, >> Venkat. >>=20 >> On Fri, Aug 17, 2012 at 1:36 PM, Joan Cucchiara >> wrote: >>> Venkat, >>>=20 >>> The SMIv2 specifies that once a TC is defined, then the definition = cannot >>> change in the way being >>> proposed by the draft-ietf-mpls-tp-te-mib-04. >>>=20 >>> =46rom RFC2579: >>> 3.3. Mapping of the DESCRIPTION clause >>> The DESCRIPTION clause, which must be present, contains a textual >>> definition of the textual convention, which provides all semantic >>> definitions necessary for implementation, and should embody any >>> information which would otherwise be communicated in any ASN.1 >>> commentary annotations associated with the object. >>>=20 >>>=20 >>> My concern is that MPLS-TC-STD-MIB defines MplsExtendedTunnelId and = this >>> draft is changing that original definition. >>> If RFC3811 does not contain "all semantic definitions necessary for >>> implementation" then the problem is to update RFC3811 >>> and maybe other associated RFCs as needed, not to propose additional >>> semantics in draft-ietf-mpls-tp-te-mib. >>>=20 >>> The draft is proposing to bifurcate the values and also not use zero = for the >>> MplsExtendedTunnelId, that is not the original >>> definition of MplsExtendedTunnelId, so why is this draft using >>> MplsExtendedTunnelId? >>>=20 >>> Please include the MIB Dr's on your email because this is a MIB = concern and >>> one which I've had since >>> before this draft was adopted as a WG document. >>>=20 >>> The options are (as I see them): >>> 1) create a specific MPLS TP table for TP Tunnels (which was = originally >>> proposed by Adrian Farrel) >>> 2) update RFC3811 to accurately reflect MplsExtendedTunnelId and = other RFCs >>> which utilize this TC. >>> 3) ?? >>>=20 >>> Thanks, >>> -Joan >>>=20 >>>=20 >>> ----- Original Message ----- From: "Venkatesan Mahalingam" >>> >>> To: "Joan Cucchiara" >>> Cc: "Thomas Nadeau" ; "Sam Aldrin" >>> ; "Kannan KV Sampath" = >>> Sent: Friday, August 17, 2012 2:39 PM >>>=20 >>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>=20 >>>=20 >>>> Joan, >>>>=20 >>>> Thanks for your response. Appreciate your time for reviewing this >>>> draft. Please find below my response tagged [VM]. >>>>=20 >>>> However, I looked over the doc and wanted to let you know that I = still >>>> have >>>>>=20 >>>>> the same issue wrt to both SYNTAX and semantic >>>>> redefinition as before. You cannot narrow the range of values in = a >>>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>>> you >>>>> have it as part of allowable values in the SYNTAX. >>>>=20 >>>> [VM] If MplsExtendedTunnelId allows zero as the valid value, I = don't >>>> see any issue to allow zero as the valid value for MplsNodeId. >>>>=20 >>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>>> reason) an >>>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>>> range, >>>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>=20 >>>> [VM] I don't see any implementation which allows non-IP TE tunnel >>>> source/destination in the range 1..16777216 in MPLS domain, >>>> if you are not still convinced, we can poll in MPLS WG list to get = the >>>> operators' opinion on this. >>>>=20 >>>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>>> if >>>>> an operator has a regular MPLS TE Tunnel configured >>>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>>> equipment be queried first? >>>>=20 >>>> [VM] It is expected to configure MPLS TE tunnels in IP address = range >>>> and MPLS-TP tunnel in NON-IP range, if the implementors have mixed >>>> mode of configuration, then it is expected to clarify in the = document >>>> that how to use MPLS-TE & MPLS-TP tunnel configurations. >>>> What you are saying is correct only if the legacy equipments use = the >>>> NON-IP range for MPLS TE tunnels, so, as I stated above, let's = close >>>> this with the MPLS WG list. >>>>=20 >>>> HTH >>>>=20 >>>> Thanks, >>>> Venkat. >>>>=20 >>>> On Fri, Aug 17, 2012 at 10:21 AM, Joan Cucchiara >>>> wrote: >>>>>=20 >>>>> Tom and all, >>>>>=20 >>>>> Unfortunately, my linux box is giving me grief this week (and I = don't >>>>> have >>>>> access to my MIB tools). I'm getting some assistance >>>>> with it but won't be resolved until (hopefully) during the = weekend. >>>>>=20 >>>>> However, I looked over the doc and wanted to let you know that I = still >>>>> have >>>>> the same issue wrt to both SYNTAX and semantic >>>>> redefinition as before. You cannot narrow the range of values in = a >>>>> DESCRIPTION clause which I see happens in = mplsTunnelExtNodeConfigLocalId >>>>> and maybe in MplsNodeId TC as it says zero must not be used, but = then >>>>> you >>>>> have it as part of allowable values in the SYNTAX. >>>>>=20 >>>>> Whatever is specified in the DESCRIPTION clause for values, should = be >>>>> reflected by the SYNTAX, right? >>>>>=20 >>>>> Additionally, the SYNTAX below for MplsExtendedTunnelId allows any >>>>> Unsigned32 and says "may represent an IPv4 address". If (for = whatever >>>>> reason) an >>>>> operator has configured something in the 1..16777216 (i.e. Local = Id) >>>>> range, >>>>> for a regular TE Tunnel, that is perfectly legal, right? >>>>>=20 >>>>>=20 >>>>> MplsExtendedTunnelId ::=3D TEXTUAL-CONVENTION >>>>> STATUS current >>>>> DESCRIPTION >>>>> "A unique identifier for an MPLS Tunnel. This may >>>>> represent an IPv4 address of the ingress or egress >>>>> LSR for the tunnel. This value is derived from the >>>>> Extended Tunnel Id in RSVP or the Ingress Router ID >>>>> for CR-LDP." >>>>> REFERENCE >>>>> "RSVP-TE: Extensions to RSVP for LSP Tunnels, >>>>> [RFC3209]. >>>>>=20 >>>>> Constraint-Based LSP Setup using LDP, [RFC3212]." >>>>> SYNTAX Unsigned32(0..4294967295) >>>>>=20 >>>>> If the answer is Yes, then how would you add TP Tunnels using your = draft >>>>> if >>>>> an operator has a regular MPLS TE Tunnel configured >>>>> in the range 1..16777216 without having to ensure that any and all = legacy >>>>> equipment be queried first? >>>>>=20 >>>>> Thanks, >>>>> -Joan >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- >>>>> From: Thomas Nadeau >>>>> To: Joan Cucchiara >>>>> Cc: Sam Aldrin ; Venkatesan Mahalingam ; Kannan KV Sampath >>>>> Sent: Thursday, August 09, 2012 8:58 AM >>>>> Subject: Re: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>>=20 >>>>> hi Joan >>>>>=20 >>>>> hope you had a great vacation! ;) >>>>>=20 >>>>> can you please follow up on the note below when you have a chance? >>>>>=20 >>>>> Tom >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jul 16, 2012, at 9:13 AM, "Joan Cucchiara" = >>>>> wrote: >>>>>=20 >>>>> Sam, >>>>>=20 >>>>> We are away this week returning on 7/23. Sorry, I can't review = the doc >>>>> until after 7/23 and it will >>>>> take a few days after that as I'll just be returning from = vacation. >>>>>=20 >>>>> I glanced at it and see that there are read-write objects in a row = (which >>>>> is >>>>> read-create) so that's >>>>> an error which I mentioned before. >>>>>=20 >>>>> Have you compiled this with smilint? >>>>>=20 >>>>> Thanks, >>>>> -Joan >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ----- Original Message ----- >>>>> From: Sam Aldrin >>>>> To: Joan Cucchiara >>>>> Cc: Venkatesan Mahalingam ; Thomas Nadeau ; Kannan KV Sampath >>>>> Sent: Friday, July 13, 2012 9:11 PM >>>>> Subject: Fwd: draft-ietf-mpls-tp-te-mib-04.txt review request >>>>>=20 >>>>> Hi Joan, >>>>>=20 >>>>> Please find the updated MIB document. Apologize for the delay. We = plan to >>>>> publish the doc on Monday as it is the deadline before IETF. Diff = file is >>>>> attached as well. >>>>>=20 >>>>> This version addresses all your comments. Highlighting couple of = them to >>>>> make sure you are OK with them >>>>>=20 >>>>> 1. W.r.t mplsLocalID as index type, we have removed that using >>>>> MplsExtendedTunnelId itself. As the value range for this object = could >>>>> have >>>>> value of non-IP address, we are using it. This will make the = indices for >>>>> the >>>>> same as TunnelTable. >>>>> In the definition of IngressLSRId and and EgressLSRId, for TP = entries, we >>>>> added description to use value of non-IP address, which is local = ID. >>>>>=20 >>>>> I do hope this satisfies the need and not necessitate for a new = table >>>>> altogether for TP. >>>>>=20 >>>>> 2. In regards to adding references to TC conventions. We believe, = those >>>>> were >>>>> added in the reference section. IF we have missed any TC = references, >>>>> could >>>>> you kindly let us know. >>>>>=20 >>>>> Appreciate if you can get back by Monday noon time PST. I know it = is a >>>>> very >>>>> short time, but appreciate if you could do that. >>>>>=20 >>>>> thanks >>>>> -sam >>>>>=20 >>>>> ________________________________ >>>>>=20 >>>>>=20 >>>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20