MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base
draft-ietf-l3vpn-mpls-vpn-mib-07

[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.

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].

[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.

[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].

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?

[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

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
>>
>

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

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
>
>
>

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>