MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base
RFC 4382
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-05-16 |
07 | (System) | Changed document authors from "Thomas Nadeau" to "Thomas Nadeau, Harmen van der Linde" |
2015-10-14 |
07 | (System) | Notify list changed from rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, tnadeau@cisco.com, hvdl@att.com to rcallon@juniper.net, rbonica@juniper ... Notify list changed from rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, tnadeau@cisco.com, hvdl@att.com to rcallon@juniper.net, rbonica@juniper.net, rick@rhwilder.net, hvdl@att.com |
2006-02-14 |
07 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2006-02-14 |
07 | Amy Vezza | [Note]: 'RFC 4382' added by Amy Vezza |
2006-02-10 |
07 | (System) | RFC published |
2005-08-16 |
07 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2005-05-16 |
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2005-05-16 |
07 | Amy Vezza | IESG has approved the document |
2005-05-16 |
07 | Amy Vezza | Closed "Approve" ballot |
2005-05-13 |
07 | (System) | Removed from agenda for telechat - 2005-05-12 |
2005-05-12 |
07 | Amy Vezza | State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza |
2005-05-12 |
07 | Mark Townsley | Ballot has been issued by Mark Townsley |
2005-05-12 |
07 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by IESG Secretary |
2005-05-12 |
07 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin |
2005-05-12 |
07 | Bert Wijnen | [Ballot comment] As i reported during my latest MIB doctor review, the below should have been considered as IETF Last Call comments, but they have ... [Ballot comment] As i reported during my latest MIB doctor review, the below should have been considered as IETF Last Call comments, but they have not been addressed. I think they can be fixed with RFC-Editor note or during AUTH48. > In document ... I see: > > 1. MIB OID assignment of: > ::= { mplsStdMIB 9999 } -- assigned by IANA, see section > 18.1 for details > > And Tom knows VERY well that he SHOULD NOT put 9999 in there, but > instead use xxxx or nnnn or some such. > > 2. The MODULE is named: MPLS-L3VPN-STD-MIB > And then in the one MODULE-COMPLIANCE he speaks of "L3 MPLS VPN MIB" > and in the 2nd MODULE-COMPLIANCE he speaks of "L3-MPLS-VPN-STD-MIB" > which is inconsistent and confusing. > Oh well... I don't have the time to go fishing for more of such. > these "inconsistencies in the text" do not break the MIB module. but they make it difficult for readers to understand the document. I have mentioned this many times before and am not planning to continue to bring this up and instead leave it to WG and authors to do proper review for such thing either in WG or during AUTH48. |
2005-05-12 |
07 | Bert Wijnen | [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen |
2005-05-12 |
07 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2005-05-12 |
07 | Michelle Cotton | IANA Follow-up Comments: The author responded to the IANA Last Call comments. His suggestion seems fine. I believe this can be fixed in Author ... IANA Follow-up Comments: The author responded to the IANA Last Call comments. His suggestion seems fine. I believe this can be fixed in Author's 48 hours. Please notify the author if this needs to be fixed through another version of the document. (From: "Thomas D. Nadeau" <tnadeau@cisco.com>) OK, I can modify section 18.1 to change the plural "sections" to "section" as follows: As described in MPLS-TC-STD-MIB [RFC3811], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There is one MPLS-related MIB module contained in this document. The following "IANA Considerations" subsection requests IANA for a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. |
2005-05-11 |
07 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2005-05-11 |
07 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from No Objection by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot comment] I never actually had a discuss on this document. I did have a question, but I figured it out for myself. ... [Ballot comment] I never actually had a discuss on this document. I did have a question, but I figured it out for myself. I must have pushed the discuss button at some point, though, and now it wants to say that my discuss was cleared. |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from No Objection by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from No Objection by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to Discuss from No Objection by Margaret Wasserman |
2005-05-11 |
07 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2005-05-11 |
07 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2005-05-11 |
07 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2005-05-10 |
07 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie |
2005-05-09 |
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley |
2005-05-09 |
07 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-05-06 |
07 | Mark Townsley | [Ballot comment] The IANA Considerations section will be updated based on the IANA review as follows: 18. IANA Considerations As described in MPLS-TC-STD-MIB [RFC3811 ... [Ballot comment] The IANA Considerations section will be updated based on the IANA review as follows: 18. IANA Considerations As described in MPLS-TC-STD-MIB [RFC3811], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There is one MPLS-related MIB module contained in this document. The following "IANA Considerations" subsect requests IANA for a new assignment under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434]. |
2005-05-06 |
07 | Mark Townsley | Placed on agenda for telechat - 2005-05-12 by Mark Townsley |
2005-05-06 |
07 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2005-05-06 |
07 | Mark Townsley | Ballot has been issued by Mark Townsley |
2005-05-06 |
07 | Mark Townsley | Created "Approve" ballot |
2005-05-06 |
07 | Mark Townsley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Mark Townsley |
2005-04-25 |
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2005-04-19 |
07 | Michelle Cotton | Disregard previous IANA Last Call Comments (these were for a different document). Revised Comments: Upon approval of this document the IANA will assign a new ... Disregard previous IANA Last Call Comments (these were for a different document). Revised Comments: Upon approval of this document the IANA will assign a new MIB number for MPLS-L3VPN-STD-MIB in the following subtree: ...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166) Found at the following: <http://www.iana.org/assignments/smi-numbers> The suggested value is 11. The IANA Considerations section seems to imply that there are more than 1 subsection. "Each of the following "IANA Considerations" subsections requests IANA for a new assignment under the mplsStdMIB subtree." Should this language be changed? |
2005-04-19 |
07 | Michelle Cotton | IANA Last Call Comments: Upon approval of this document the IANA will assign a mib-2 number. |
2005-04-11 |
07 | Mark Townsley | [Note]: 'This doc is being advanced together with draft-ietf-l3vpn-tc-mib-06.txt' added by Mark Townsley |
2005-04-11 |
07 | Amy Vezza | Last call sent |
2005-04-11 |
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-04-11 |
07 | Mark Townsley | [Note]: 'This doc is being advanced together with draft-ietf-l3vpn-mpls-vpn-mib.' added by Mark Townsley |
2005-04-11 |
07 | Mark Townsley | Last Call was requested by Mark Townsley |
2005-04-11 |
07 | Mark Townsley | State Changes to Last Call Requested from AD Evaluation::AD Followup by Mark Townsley |
2005-04-11 |
07 | (System) | Ballot writeup text was added |
2005-04-11 |
07 | (System) | Last call text was added |
2005-04-11 |
07 | (System) | Ballot approval text was added |
2005-04-11 |
07 | Mark Townsley | [Note]: 'Approval from L3VPN Chair Ron Bonica that no WG LC is needed (multiple LCs have already passed on this doc). On to IETF LC ... [Note]: 'Approval from L3VPN Chair Ron Bonica that no WG LC is needed (multiple LCs have already passed on this doc). On to IETF LC.' added by Mark Townsley |
2005-04-11 |
07 | Mark Townsley | [Note]: 'Bert still has a few minor issues, but agreed to address them during LC.' added by Mark Townsley |
2005-04-07 |
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-04-07 |
07 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-07.txt |
2005-03-11 |
07 | Mark Townsley | Shepherding AD has been changed to Mark Townsley from Thomas Narten |
2005-02-09 |
07 | Thomas Narten | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Thomas Narten |
2005-02-09 |
07 | Thomas Narten | From: "Thomas D. Nadeau" <tnadeau@cisco.com> To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com> Cc: Rick Wilder <rick@rhwilder.net>, Ronald Bonica <rbonica@juniper.net> ... From: "Thomas D. Nadeau" <tnadeau@cisco.com> To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com> Cc: Rick Wilder <rick@rhwilder.net>, Ronald Bonica <rbonica@juniper.net>, Ross Callon <rcallon@juniper.net>, "David Kessens (E-mail)" <david.kessens@nokia.com>, "Juergen Schoenwaelder (E-mail)" <j.schoenwaelder@iu-bremen.de>, "'Thomas Narten'" <narten@us.ibm.com> Date: Tue, 8 Feb 2005 11:42:07 -0500 Subject: Re: l3vpn mibs - quick check on: draft-ietf-l3vpn-mpls-vpn-mib-06 .txt Bert, Please read the note to the WG. This is just a refresh of the draft that includes partial fixes based on your earlier comments. It is NOT meant to be a final version for review, although I welcome your additional review. --tom > [added David Kessens my co-ad and Juergen (lead MIB doctor during > my absence). Also copied Tom... so he can > see what I am writing. > > > > Issues with citations references: > !! Missing Reference for citation: [RFC3031] > P002 L053: [RFC3031]. > !! Missing Reference for citation: [RFC3411] > P005 L037: FROM SNMP-FRAMEWORK-MIB > -- [RFC3411] > !! Missing citation for Normative reference: > P038 L045: [RTPROTO] IANA, "IP Route Protocol MIB", > !! Missing citation for Normative reference: > P038 L021: [RFC2096] Baker, F., "IP Forwarding Table MIB", > RFC2096, > !! Missing Reference for citation: [MPLSTCMIB] > P042 L021: [MPLSTCMIB], MPLS related standards track MIB modules > should be > and more issues with references I think. But I do not want to > go spit out the details. > > I am kind of surprised to find in: > > mplsL3VpnModuleReadOnlyComplianc > > things like: > > OBJECT mplsL3VpnIfConfRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) > } > DESCRIPTION "Support for createAndWait and notReady is not > required." > > i.e. a READ-ONLY compliance to find that WRITE access is required > to create rows in a table. Not that usch is absolutely impossible, > but it sounds weird. I would expect some clarifying text if it is > indeed intended. I would expect rather something aka: > > OBJECT mplsL3VpnIfConfRowStatus > SYNTAX RowStatus { active(1) } > MIN-ACCESS read-only > DESCRIPTION "read-create support is not required." > > Oh well... > > When I read: > > GROUP mplsL3VpnPerfRouteGroup > DESCRIPTION "This group is only mandatory for LSRs that wish to > support tracking the number of routes attempted to > be added to VRFs." > > Then I wonder about "mandatory". This group seems optional to me, > becuase it seems it is only used if the LSR "wishes" to support..." > I know this may feel like nitpicking. But pls try to understand what > the statement is trying to say to a novice implementer? > > Take a look at: > mplsL3VpnVrfRteInetCidrDest > > the DESCRIPTION clause contains: > When > the value of mplsL3VpnVrfRteInetCidrDest is x, then > the bitwise logical-AND of x with the value of the mask > formed from the corresponding index object > mplsL3VpnVrfRteInetCidrPfxLen MUST be > equal to x. > > It may be just me, but I have trouble understanding the use of this > concept. > In fact I cannot quickly figure out how the mplsL3VpnVrfRteTable works > at all > > Nits... but important for people who are not day-to-day in this > material. > - what is VRF ?? > - what is a VPR ?? > In other words, lots of acronyms without any exapansion when first used > and without a terminology section. > > Now, take this for example: > > 6.1 mplsL3VpnVrfTable > > This table represents the MPLS L3VPNs that are configured. > A Network Management System (NMS) or SNMP agent creates an > entry in this table for every MPLS L3VPN configured on > the LSR being examined. The VPR that is configured at > a particular device represents an instance of some VPN, but > not the entire VPN (unless it is the only VRF, of course). > The collective set of VRF instances comprises the actual > VPN. This information is typically only known in its entirety > at the NMS. That is, specific devices generally only know > of their local VRF information, but not that of other LSRs' > VRFs. > > try to read and understand. I need to think long to try and figure > out what is meant. The 2nd sentence for example. I would think that > by creating an entry, that that way you configure a route. But the > sentence seems to say that the route already has been configured. > So what is meant? > The 3rd sentence starts with "The VPR..." What is a VPR? > VRF is ?? > Anyway, it does not help me much understanding what this table > contains and how to create it. When I go to the table definitions > itself, I do not get much wiser. > > Now look at > MplsL3VpnName TEXTUAL-CONVENTION > > It seems that the easiest for operators would be to have it as > a Human readable string, no? At the least the example using "RED" > seems to indicate so. In that case it better be a UTF-8 based TC. > > In mplsL3VpnVrfRteEntry DESCRIPTIONM clause we see: > > Implementors need to be aware that if the value of > the mplsL3VpnVrfName (an OID) has more > that 111 sub-identifiers, then OIDs of column > > So it states that mplsL3VpnVrfName is an OID, but if you go to > mplsL3VpnVrfName definition: > mplsL3VpnVrfName OBJECT-TYPE > SYNTAX MplsL3VpnName > then it truns out is is a TC of MplsL3VpnName > which turns out be be an underlying OCTET STRING of size (0..31) > so it can never have a size of 111 subidentifiers. In other words > the text here is confusing and conflicting with otehr text in the > document. > > Oh well... as you can see, there is no such thing as a quick review of > this MIB document. But I am sure that there is lots of stuff that the > WG chairs )or anyone else who takes a few days to review and carefully > check everything) can find. You would prefer that that is done before > this doc is handed to a MIB doctor > > Bert >> -----Original Message----- >> From: Thomas Narten [mailto:narten@us.ibm.com] >> Sent: Monday, February 07, 2005 16:21 >> To: Ross Callon >> Cc: Bert Wijnen; Rick Wilder; Ronald Bonica >> Subject: Re: l3vpn mibs >> >> >>> I just talked to Tom Nadeau about this. He says that there are >>> still some details that he is discussing with Bert prior to updating >>> the draft. >> >> Well, to be blunt, this sounds like nonsense. As Bert reports, there >> hasn't been any discourse for 6 months... >> >> Sigh. >> >> Hopefully, we'll see some action now. >> >> Thomas >> > |
2005-02-09 |
07 | Thomas Narten | [Note]: '2005-02-09: latest version known to not address Bert/MIB Doctor review from September, 2004. ' added by Thomas Narten |
2005-02-07 |
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2005-02-07 |
06 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-06.txt |
2005-02-04 |
07 | Thomas Narten | State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, tnadeau@cisco.com, hvdl@att.com from ... State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, tnadeau@cisco.com, hvdl@att.com from <rick@rhwilder.net>, <rcallon@juniper.net>, <ronald.p.bonica@mci.com>, tnadeau@cisco.com, hvdl@att.com |
2005-02-04 |
07 | Thomas Narten | 2004-09-23: review comments on -05 From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com> To: "'Thomas D. Nadeau'" <tnadeau@cisco.com> Cc: Ross Callon <rcallon@juniper.net> ... 2004-09-23: review comments on -05 From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com> To: "'Thomas D. Nadeau'" <tnadeau@cisco.com> Cc: Ross Callon <rcallon@juniper.net>, Ronald Bonica <ronald.p.bonica@mci.com>, Harmen Van der Linde <hvdl@att.com> Date: Thu, 23 Sep 2004 23:55:01 +0200 Subject: RE: draft-ietf-l3vpn-mpls-vpn-mib-06 Again many many things. And things that are just a repeat of similar comments/issues raised on earlier MIB work that you were involved in. I wish that some day I do not have to review and make same comments over and over again. Oh well... at some time in the future I will no longer be an AD. I have only (sort of quickly, but did spend considereable more time this time than last time) scanned for obvious MIB/SMI/SNMP issues. I have not really checked th content of most of this MIB. I would have to spend much more time on that and am willing to do so, but would liek to see a lot of the basic syntax and SMI issues fixed first - I see: 8.0 MPLS-L3VPN-MIB Module Definition MPLS-L3VPN-STD-MIB DEFINITIONS ::= BEGIN Would be good to sync up the names of the MIB module - MplsL3VpnName would that name be prefereed to be Human readable? Since you speak about an NMS operator setting it! In any event it sounds as if it is an administratively assigned ID, that you RECOMMEND the adminitration to make unique. In fact, when you use the syntax in mplsL3VpnVrfName you state it is Human Readable. So I must ask/suggest that this be a UTF-8 based string (something aka SnmpAdminString) - I see: MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Syntax for a route distinguisher and route target." SYNTAX OCTET STRING(SIZE (0..256)) I cannot say that the DESCRIPTION clause gives me any clue as to what to expect in the OCTET STRING. Is that just me? - I see: mplsL3VpnActiveVrfs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRFs which are active on this node. That is, those VRFs whose corresponding mplsL3VpnVrfOperStatus object value is equal to operational (1)." ::= { mplsL3VpnScalars 2 } It seems to me that this number can go up and down, no? WOuld a Gauge32 be a better SYNTAX? Same question for mplsL3VpnConnectedInterfaces - WHat is the expected persistency behaviour of mplsL3VpnNotificationEnable? - mplsL3VpnIfConfStorageType You expect that I ask: what about a permanent row? which objects should be writable in that case? Same for other StorageType objects in this doc. Tom... you know this is required! - mplsL3VpnVrfVpnId talks about an "empty string" I think you want to be clear/explicit and state "zero-length OCTET STRING" But the funny thing is that the VPNId TC only allows length 7. See my comment on the VPN-TC-STD-MIB where I suggested to add a VPNIdOrZero for possible future use... Oh well the future is here! Same issue for mplsL3VpnVrfVpnId - mplsL3VpnVrfRTEntry DESCRIPTION clause has funny indentation for one line - mplsL3VpnVrfRT OBJECT-TYPE SYNTAX MplsL3VpnRouteDistinguisher MAX-ACCESS read-create STATUS current DESCRIPTION "The route target distribution policy." DEFVAL { "" } Description does not tell me much. And this sounds different from the TC description. Pls be aware that all sorts of people may read this and want to understand what you mean - Is there redundancy in these tables??? I have not studied in detail yet, but reading through it I get that impression. Pls realize that it is BETTER to have fewer objects as opposed to many (redundant) objects. If not, then at least mplsL3VpnVrfRTType OBJECT-TYPE SYNTAX INTEGER { import(1), export(2), both(3) } seems a good candidate for a TC - I see no STorageType column in mplsL3VpnVrfRTTable and neither do I see a writeup on expected persistency behaviour - for the COunter32 objects I am missing text about discontinuities and which discontinuity timer indicates such a discontinuity - mplsL3VpnVrfSecTable has a read-create column. In such a case there MUST be a RowStatus column! And I need persistency behaviour defined! And the DESCRIPTION clause DESCRIPTION "This table specifies per MPLS L3VPN VRF Table security features." seems to be out of sync with the columns in the table. Or am I not understanding this ? - mplsL3VpnVrfPerfRoutesAdded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of routes added to this VPN/VRF since this device has last been reset or the VRF was created, whichever came last." A counter32 CANNOT represent a count "since" any point in time. A ZeroBasedCOunter32 could... but not sure you want to use that either. - This MplsL3VpnVrfRteEntry ::= SEQUENCE { mplsL3VpnVrfRteInetCidrDestType InetAddressType, mplsL3VpnVrfRteInetCidrDest InetAddress, mplsL3VpnVrfRteInetCidrPfxLen InetAddressPrefixLength, mplsL3VpnVrfRteInetCidrPolicy OBJECT IDENTIFIER, mplsL3VpnVrfRteInetCidrNHopType InetAddressType, mplsL3VpnVrfRteInetCidrNextHop InetAddress, mplsL3VpnVrfRteInetCidrIfIndex InterfaceIndexOrZero, mplsL3VpnVrfRteInetCidrType INTEGER, mplsL3VpnVrfRteInetCidrProto IANAipRouteProtocol, mplsL3VpnVrfRteInetCidrAge Gauge32, mplsL3VpnVrfRteInetCidrNextHopAS InetAutonomousSystemNumber, mplsL3VpnVrfRteInetCidrMetric1 Integer32, mplsL3VpnVrfRteInetCidrMetric2 Integer32, mplsL3VpnVrfRteInetCidrMetric3 Integer32, mplsL3VpnVrfRteInetCidrMetric4 Integer32, mplsL3VpnVrfRteInetCidrMetric5 Integer32, mplsL3VpnVrfRteXCPointer MplsIndexType, mplsL3VpnVrfRteInetCidrStatus RowStatus } looks a lot like (RFC2096update): InetCidrRouteEntry ::= SEQUENCE { inetCidrRouteDestType InetAddressType, inetCidrRouteDest InetAddress, inetCidrRoutePfxLen InetAddressPrefixLength, inetCidrRoutePolicy OBJECT IDENTIFIER, inetCidrRouteNextHopType InetAddressType, inetCidrRouteNextHop InetAddress, inetCidrRouteIfIndex InterfaceIndexOrZero, inetCidrRouteType INTEGER, inetCidrRouteProto IANAipRouteProtocol, inetCidrRouteAge Gauge32, inetCidrRouteNextHopAS InetAutonomousSystemNumber, inetCidrRouteMetric1 Integer32, inetCidrRouteMetric2 Integer32, inetCidrRouteMetric3 Integer32, inetCidrRouteMetric4 Integer32, inetCidrRouteMetric5 Integer32, inetCidrRouteStatus RowStatus } Explain to me (again maybe) why this redundancy/duplication is needed? And you migth then at the same time write that down in the DESCRIPTION clause of this table, so that other people can see it as well. - In the module compliance I would expect some subtyping of the InectAddressType/InetAddress objects. Or is a type of dns allowed? If so, then you need to describe when the DNS name is expected to be resolved. - I am missing normative reference [RFC2580] There may be others... I did not check in detail Bert > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, September 23, 2004 22:28 > To: Bert Wijnen > Cc: Ross Callon; Ronald Bonica; Harmen Van der Linde > Subject: draft-ietf-l3vpn-mpls-vpn-mib-06 > > > > Hi Bert, > > Ross forwarded me some comments you had > on the L3VPN MIB that were in addition to > your earlier ones (which you indicated were > addressed). I have made a reasonable attempt > to make what I think are the changes necessary > to address those comments in the attached draft. > I ran the draft through id-nits and smilint, and > it comes out cleanly. Please let me > know if you have additional comments. > > Regards, > > --Tom > > > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com> To: "'Thomas D. Nadeau'" <tnadeau@cisco.com> Cc: Ross Callon <rcallon@juniper.net>, Ronald Bonica <ronald.p.bonica@mci.com>, Harmen Van der Linde <hvdl@att.com> Date: Thu, 23 Sep 2004 23:55:01 +0200 Subject: RE: draft-ietf-l3vpn-mpls-vpn-mib-06 Again many many things. And things that are just a repeat of similar comments/issues raised on earlier MIB work that you were involved in. I wish that some day I do not have to review and make same comments over and over again. Oh well... at some time in the future I will no longer be an AD. I have only (sort of quickly, but did spend considereable more time this time than last time) scanned for obvious MIB/SMI/SNMP issues. I have not really checked th content of most of this MIB. I would have to spend much more time on that and am willing to do so, but would liek to see a lot of the basic syntax and SMI issues fixed first - I see: 8.0 MPLS-L3VPN-MIB Module Definition MPLS-L3VPN-STD-MIB DEFINITIONS ::= BEGIN Would be good to sync up the names of the MIB module - MplsL3VpnName would that name be prefereed to be Human readable? Since you speak about an NMS operator setting it! In any event it sounds as if it is an administratively assigned ID, that you RECOMMEND the adminitration to make unique. In fact, when you use the syntax in mplsL3VpnVrfName you state it is Human Readable. So I must ask/suggest that this be a UTF-8 based string (something aka SnmpAdminString) - I see: MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Syntax for a route distinguisher and route target." SYNTAX OCTET STRING(SIZE (0..256)) I cannot say that the DESCRIPTION clause gives me any clue as to what to expect in the OCTET STRING. Is that just me? - I see: mplsL3VpnActiveVrfs OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of VRFs which are active on this node. That is, those VRFs whose corresponding mplsL3VpnVrfOperStatus object value is equal to operational (1)." ::= { mplsL3VpnScalars 2 } It seems to me that this number can go up and down, no? WOuld a Gauge32 be a better SYNTAX? Same question for mplsL3VpnConnectedInterfaces - WHat is the expected persistency behaviour of mplsL3VpnNotificationEnable? - mplsL3VpnIfConfStorageType You expect that I ask: what about a permanent row? which objects should be writable in that case? Same for other StorageType objects in this doc. Tom... you know this is required! - mplsL3VpnVrfVpnId talks about an "empty string" I think you want to be clear/explicit and state "zero-length OCTET STRING" But the funny thing is that the VPNId TC only allows length 7. See my comment on the VPN-TC-STD-MIB where I suggested to add a VPNIdOrZero for possible future use... Oh well the future is here! Same issue for mplsL3VpnVrfVpnId - mplsL3VpnVrfRTEntry DESCRIPTION clause has funny indentation for one line - mplsL3VpnVrfRT OBJECT-TYPE SYNTAX MplsL3VpnRouteDistinguisher MAX-ACCESS read-create STATUS current DESCRIPTION "The route target distribution policy." DEFVAL { "" } Description does not tell me much. And this sounds different from the TC description. Pls be aware that all sorts of people may read this and want to understand what you mean - Is there redundancy in these tables??? I have not studied in detail yet, but reading through it I get that impression. Pls realize that it is BETTER to have fewer objects as opposed to many (redundant) objects. If not, then at least mplsL3VpnVrfRTType OBJECT-TYPE SYNTAX INTEGER { import(1), export(2), both(3) } seems a good candidate for a TC - I see no STorageType column in mplsL3VpnVrfRTTable and neither do I see a writeup on expected persistency behaviour - for the COunter32 objects I am missing text about discontinuities and which discontinuity timer indicates such a discontinuity - mplsL3VpnVrfSecTable has a read-create column. In such a case there MUST be a RowStatus column! And I need persistency behaviour defined! And the DESCRIPTION clause DESCRIPTION "This table specifies per MPLS L3VPN VRF Table security features." seems to be out of sync with the columns in the table. Or am I not understanding this ? - mplsL3VpnVrfPerfRoutesAdded OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the number of routes added to this VPN/VRF since this device has last been reset or the VRF was created, whichever came last." A counter32 CANNOT represent a count "since" any point in time. A ZeroBasedCOunter32 could... but not sure you want to use that either. - This MplsL3VpnVrfRteEntry ::= SEQUENCE { mplsL3VpnVrfRteInetCidrDestType InetAddressType, mplsL3VpnVrfRteInetCidrDest InetAddress, mplsL3VpnVrfRteInetCidrPfxLen InetAddressPrefixLength, mplsL3VpnVrfRteInetCidrPolicy OBJECT IDENTIFIER, mplsL3VpnVrfRteInetCidrNHopType InetAddressType, mplsL3VpnVrfRteInetCidrNextHop InetAddress, mplsL3VpnVrfRteInetCidrIfIndex InterfaceIndexOrZero, mplsL3VpnVrfRteInetCidrType INTEGER, mplsL3VpnVrfRteInetCidrProto IANAipRouteProtocol, mplsL3VpnVrfRteInetCidrAge Gauge32, mplsL3VpnVrfRteInetCidrNextHopAS InetAutonomousSystemNumber, mplsL3VpnVrfRteInetCidrMetric1 Integer32, mplsL3VpnVrfRteInetCidrMetric2 Integer32, mplsL3VpnVrfRteInetCidrMetric3 Integer32, mplsL3VpnVrfRteInetCidrMetric4 Integer32, mplsL3VpnVrfRteInetCidrMetric5 Integer32, mplsL3VpnVrfRteXCPointer MplsIndexType, mplsL3VpnVrfRteInetCidrStatus RowStatus } looks a lot like (RFC2096update): InetCidrRouteEntry ::= SEQUENCE { inetCidrRouteDestType InetAddressType, inetCidrRouteDest InetAddress, inetCidrRoutePfxLen InetAddressPrefixLength, inetCidrRoutePolicy OBJECT IDENTIFIER, inetCidrRouteNextHopType InetAddressType, inetCidrRouteNextHop InetAddress, inetCidrRouteIfIndex InterfaceIndexOrZero, inetCidrRouteType INTEGER, inetCidrRouteProto IANAipRouteProtocol, inetCidrRouteAge Gauge32, inetCidrRouteNextHopAS InetAutonomousSystemNumber, inetCidrRouteMetric1 Integer32, inetCidrRouteMetric2 Integer32, inetCidrRouteMetric3 Integer32, inetCidrRouteMetric4 Integer32, inetCidrRouteMetric5 Integer32, inetCidrRouteStatus RowStatus } Explain to me (again maybe) why this redundancy/duplication is needed? And you migth then at the same time write that down in the DESCRIPTION clause of this table, so that other people can see it as well. - In the module compliance I would expect some subtyping of the InectAddressType/InetAddress objects. Or is a type of dns allowed? If so, then you need to describe when the DNS name is expected to be resolved. - I am missing normative reference [RFC2580] There may be others... I did not check in detail Bert > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Thursday, September 23, 2004 22:28 > To: Bert Wijnen > Cc: Ross Callon; Ronald Bonica; Harmen Van der Linde > Subject: draft-ietf-l3vpn-mpls-vpn-mib-06 > > > > Hi Bert, > > Ross forwarded me some comments you had > on the L3VPN MIB that were in addition to > your earlier ones (which you indicated were > addressed). I have made a reasonable attempt > to make what I think are the changes necessary > to address those comments in the attached draft. > I ran the draft through id-nits and smilint, and > it comes out cleanly. Please let me > know if you have additional comments. > > Regards, > > --Tom > > > |
2005-02-04 |
07 | Thomas Narten | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Thomas Narten |
2005-02-04 |
07 | Thomas Narten | [Note]: '2004-09-27: Bert Wijnen did an initial review, new ID needed.' added by Thomas Narten |
2005-02-04 |
07 | Thomas Narten | State Changes to AD Evaluation from Publication Requested by Thomas Narten |
2005-02-04 |
07 | Thomas Narten | State Change Notice email list have been change to <rick@rhwilder.net>, <rcallon@juniper.net>, <ronald.p.bonica@mci.com>, tnadeau@cisco.com, hvdl@att ... State Change Notice email list have been change to <rick@rhwilder.net>, <rcallon@juniper.net>, <ronald.p.bonica@mci.com>, tnadeau@cisco.com, hvdl@att.com from <rick@rhwilder.net>, <rcallon@juniper.net>, <ronald.p.bonica@mci.com> |
2004-08-25 |
05 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-05.txt |
2004-08-02 |
07 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching by Dinara Suleymanova |
2004-08-02 |
07 | Dinara Suleymanova | Shepherding AD has been changed to Thomas Narten from Alex Zinin |
2004-08-02 |
07 | Dinara Suleymanova | Intended Status has been changed to Proposed Standard from None |
2004-06-23 |
04 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-04.txt |
2004-05-14 |
03 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-03.txt |
2004-02-09 |
02 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-02.txt |
2004-01-29 |
01 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-01.txt |
2003-07-23 |
00 | (System) | New version available: draft-ietf-l3vpn-mpls-vpn-mib-00.txt |
2003-05-01 |
07 | Alex Zinin | Shepherding AD has been changed to Zinin, Alex from Bradner, Scott |
2002-04-27 |
07 | Scott Bradner | Draft Added by Scott Bradner |