[netlmm] AD review of draft-ietf-netlmm-pmipv6-mib

Jari Arkko <jari.arkko@piuha.net> Mon, 31 May 2010 13:47 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09AB23A6869 for <netlmm@core3.amsl.com>; Mon, 31 May 2010 06:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.334
X-Spam-Level:
X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_47=0.6, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kj5j0lmEmNZ for <netlmm@core3.amsl.com>; Mon, 31 May 2010 06:47:27 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 7A6A83A697A for <netlmm@ietf.org>; Mon, 31 May 2010 06:47:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8E9852CED4; Mon, 31 May 2010 16:47:14 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCAWctqwcr20; Mon, 31 May 2010 16:47:13 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9F8132CCA5; Mon, 31 May 2010 16:47:13 +0300 (EEST)
Message-ID: <4C03BDE1.1010508@piuha.net>
Date: Mon, 31 May 2010 16:47:13 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "netlmm@ietf.org" <netlmm@ietf.org>, draft-ietf-netlmm-pmipv6-mib@tools.ietf.org
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [netlmm] AD review of draft-ietf-netlmm-pmipv6-mib
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2010 13:47:29 -0000

I have reviewed this draft. Overall, I think it is in good shape, but I did see a number of issues. Please issue a new draft that corrects them and/or adds more clarifying text. The main issues were:

- at times the document was unclear about where a particular piece of MIB information is held (at the MAG vs. LMA)
- in several places the document needs to be more explicit
- some IP address issues
- not sure I understood the OID limit issue

- pmip6MagProxyCOATable          : models the Proxy Care-of
                                   Addresses configured on the
                                   egress interfaces of the
                                   mobile access gateway.
  
>From this description it is unclear where this table is. Is this a MAG or a LMA table?

- pmip6MagHomeNetworkPrefixTable : contains the Home Network
                                   Prefixes assigned to the
                                   mobile node's connected
                                   interfaces.
  

Is this "the mobile node"? or all mobile nodes currently attached to this mag? Same issue in pmip6LmaHomeNetworkPrefixTable.

       - pmip6LmaLMAATable              : contains the LMA Addresses
                                          that are configured on the
                                          local mobility anchor. Each
                                          LMA Address acts as a
                                          transport endpoint of the
                                          tunnel between the local
                                          mobility anchor and the mobile
                                          access gateway.
  
>From this desccription it is unclear from whose point of view this information is presented. Does this table exist at the MAGs or the LMAs?

   Pmip6MNIdentifier  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The identity of a mobile node in the Proxy Mobile IPv6
            domain. This is the stable identifier of a mobile node
            that the mobility entities in a Proxy Mobile IPv6 domain
            can always acquire and use it for predictably identifying
            a mobile node. This is typically an identifier such as
            Network Access Identifier (NAI) [http://tools.ietf.org/html/rfc4282" title='"./rfc4282"' rel="nofollow">RFC4282] or other
            identifier such as a Media Access Control (MAC) address.
           "
       REFERENCE
           "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2" rel="nofollow">Section 2.2"
       SYNTAX  OCTET STRING (SIZE (0..255))

  
This description should be more accurate about the encoding of the identifier. Do you mean that its the same encoding as in RFC 4283? Are there other alternatives than NAIs? Please be more precise. Section 2.2 is not a very good reference in this sense, because it too lacks specificity.

   Pmip6MNLlIdentifier ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "An identifier that identifies the attached interface of a
            mobile node.  For those interfaces that have a link-layer
            identifier, this identifier can be based on that.  The
            link-layer identifier in some cases is generated by the
            mobile node and conveyed to the mobile access gateway.  This
            identifier of the attached interface must be stable as seen
            by any of the mobile access gateways in a given Proxy Mobile
            IPv6 domain.  In some other cases, there might not be any
            link-layer identifier associated with the mobile node's
            interface. An identifier value of ALL_ZERO is not considered
            a valid identifier and cannot be used as an interface
            identifier.
           "
       REFERENCE
           "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2" rel="nofollow">Section 2.2"
       SYNTAX  OCTET STRING (SIZE (0..255))
  
As above, what is the encoding? Should the reference be Section 8.6 instead?

   Pmip6MNIndex ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS       current
       DESCRIPTION
           "A unique integer value, greater than zero, assigned to each
            mobile node in a PMIPv6-Domain by the management system.
            It is recommended that values are assigned contiguously
            starting from 1.  The value for each mobile node must remain
            constant at least from one re-initialization of the entity's
            network management system to the next re-initialization.
           "
       SYNTAX       Integer32 (1..2147483647)

  


Due to roaming, there is an infinite number of potential visited mobile nodes. Are these indexes for the *current* mobile nodes, i.e., those currently attached to the domain? Or something else? Please specify.

   Pmip6PBUAccessTechnologyType ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This specifies the access technology which connects the
            mobile node to the access link on the mobile access gateway.
           "
       REFERENCE
           "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-8.5" rel="nofollow">Section 8.5"
       SYNTAX INTEGER
       {
                 reserved               (0),
                 logicalNetworkInterface(1),
                 pointToPointInterface  (2),
                 ethernet               (3),
                 wirelessLan            (4),
                 wimax                  (5)
       }
  

Perhaps you should explicitly state that the namespace from RFC 5213 should be used:

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt" rel="nofollow">http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt

note the 3GPP etc items that do not appear in your list above...

       pmip6FixedMagLinkLocalAddressOnAllAccessLinksType OBJECT-TYPE
           SYNTAX      InetAddressType
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION
               "The InetAddressType of the
                pmip6FixedMagLinkLocalAddressOnAllAccessLinks
                that follows.
               "
              ::= { pmip6Conf 2 }
       pmip6FixedMagLinkLocalAddressOnAllAccessLinks OBJECT-TYPE
           SYNTAX      InetAddress
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION
               "This variable indicates the link-local address value
                that all the mobile access gateways should use on
                any of the access links shared with any of the
                mobile nodes in that Proxy Mobile IPv6 domain.  If
                this variable is initialized to ALL_ZERO value, it
                implies the use of fixed link-local address mode is
                not enabled for that Proxy Mobile IPv6 domain."
           REFERENCE
               "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2" rel="nofollow">Section 2.2, 6.8, 6.9.1.1, 6.9.3, 9.3"
              ::= { pmip6Conf 3 }
  

I'm not sure I understand this. There's an IPv6 link local address, but is there an IPv4 one? If not, why do we need the -Type object? And where is the IPv4 default router and DHCP server address stored in? Here there is room for just one address, not two as would expect to require in a dual stack environment... but maybe I'm missing something.

(Same issue in pmip6Binding table)

       pmip6MagProxyCOAState  OBJECT-TYPE
           SYNTAX      INTEGER {
                                  unknown(1),
                                  activated(2),
                                  tunneled(3)
                          }
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
               "This object indicates the state of the Proxy-CoA:
                   unknown     -- The state of the Proxy-CoA
                                  cannot be determined.
                   activated   -- The Proxy-CoA is ready to establish
                                  tunnel
                   tunneled    -- The Proxy-CoA is used to set up the
                                  bi-directional tunnel.
               "
           ::= { pmip6MagProxyCOAEntry 3 }
  

Do we use activated or tunneled, if the system is otherwise up but the MAG has no mobile nodes, and has not had to send a Proxy Binding Update yet?

       pmip6MagHomeNetworkPrefixTable   OBJECT-TYPE
            SYNTAX      SEQUENCE OF PMip6MagHomeNetworkPrefixEntry
            MAX-ACCESS  not-accessible
            STATUS      current
            DESCRIPTION
                "A table representing the Home Network Prefixes
                 assigned to the mobile node's connected interfaces.
                 This table shows the prefixes registered in the
                 binding update list entry.
                "
            REFERENCE
                "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2" rel="nofollow">Section 2, 6.1, 6.2"
            ::= { pmip6MagConf 2 }
  

The description has been written as if there was just one mobile node and one BUL entry. Please update the specification, I presume that you meant that this table contains ALL prefixes of ALL mobile nodes for which there exists ANY BUL in this MAG?

       pmip6MagHomeNetworkPrefixEntry OBJECT-TYPE
            SYNTAX      PMip6MagHomeNetworkPrefixEntry
            MAX-ACCESS  not-accessible
            STATUS      current
            DESCRIPTION
                "An entry in the Home Network Prefixes table.

                 Implementers need to be aware that if the total
                 number of octets in pmip6MagHomeNetworkPrefix
                 exceeds 114 then OIDs of column
                 instances in this row will have more than 128
                 sub-identifiers and cannot be accessed using
                 SNMPv1, SNMPv2c, or SNMPv3.
  

I do not understand this. The pmip6MagHomeNetworkPrefix is of type InetAddress, so in this case its length would always be 16, no?

(Same issue in pmip6LmaLMAAEntry and pmip6LmaHomeNetworkPrefixEntry)

       pmip6MagHomeNetworkPrefixLifeTime   OBJECT-TYPE
            SYNTAX      Gauge32
            UNITS       "seconds"
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
                "The lifetime (in seconds) granted to the mobile
                 node for this registration.
                "
            REFERENCE
                "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-6.2" rel="nofollow">Section 6.2, 6.7"
            ::= { pmip6MagHomeNetworkPrefixEntry 4 }


  
The lifetime in the PBA? The lifetime in the last RA sent out to the mobile node? The remaining lifetime? Please specify...

       pmip6MagBLTable OBJECT-TYPE
           SYNTAX      SEQUENCE OF Pmip6MagBLEntry
           MAX-ACCESS  not-accessible
           STATUS      current
           DESCRIPTION
               "This table corresponds to the Binding Update List(BL)
  
Is there a particular reason to drop the U from the abbreviation?

        pmip6MagBLTimeRecentlyAccepted OBJECT-TYPE
           SYNTAX      DateAndTime
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
               "The 64-bit timestamp value of the most recently
                accepted Proxy Binding Update message sent for this
                mobile node.  This is the time-of-day on the mobile
                access gateway, when the proxy binding acknowledgement
                message with the Status field set to 0
                was received.  If the Timestamp option is not present
                in the Proxy Binding Update message (i.e., when the
                sequence number based scheme is in use), the value MUST
                be set to ALL_ZERO.
               "
           REFERENCE
               "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-5.1" rel="nofollow">Section 5.1, 8.1"
           ::= { pmip6MagBLEntry 9 }
  

I'm curious why the last timestamp is in this table, but the last sequence number is not. Sequence numbers and timestamps are equal alternatives in RFC 5213.

(Same issue in pmip6Binding table)

       pmip6BindingPBUFlag OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
               "true(1) if the local mobility anchor accepted the
                binding update with Proxy Registration Flag from a
                mobile access gateway.
                false(0) implies that the binding cache is from a
                mobile node.
               "
           REFERENCE
               "http://tools.ietf.org/html/rfc5213" rel="nofollow">RFC 5213: http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-5.1" rel="nofollow">Section 5.1, 8.1"
           ::= { pmip6BindingCacheEntry 1 }
  

Please specify what is expected to happen for Flag=0 entries otherwise. Do they even show up in this table, and if they do, how do the values in the entries get filled? Or would a client Mobile IP host simply lead to the creation of another entry in a Mobile IPv6 MIB table, not here?

   sensitivity/vulnerability:
      nemoStatus: The value of this object is used to enable or disable
         the PMIPv6 functionality on a PMIPv6 entity. Access to this MO
         may be abused to disrupt the communication that depends on
  

This is the first time that nemoStatus appears in the document.

When using http://www.ibr.cs.tu-bs.de/bin/smitools.cgi" rel="nofollow">http://www.ibr.cs.tu-bs.de/bin/smitools.cgi I got these errors:

mibs/PMIPV6-MIB:88: [2] {bad-identifier-case} `YYY' should start with a lower case letter
mibs/PMIPV6-MIB:88: [2] {object-identifier-not-prefix} Object identifier element `YYY' name only allowed as first element
mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 136 subidentifier(s)
mibs/PMIPV6-MIB:537: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s)
mibs/PMIPV6-MIB:1462: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 136 subidentifier(s)
mibs/PMIPV6-MIB:1640: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s)
mibs/PMIPV6-MIB:145: [5] {type-without-format} warning: type `Pmip6MNIdentifier' has no format specification
mibs/PMIPV6-MIB:160: [5] {type-without-format} warning: type `Pmip6MNLlIdentifier' has no format specification
  

At least some of these seem real problems. Please fix.

Jari