Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1

From: Kevin Lingle <[email-masked]>
Date: Tue, 19 Nov 2002 15:38:35 -0500

hi,

i have some comments on the latest version of this I-D.

Section 6.1 - TRIP-TC module
----------------------------
1) TC TripApplProtocol DESCRIPTION...
   change "document" to "MIB module"

2) TC TripSendReceiveMode...
   can you explain each enumerated value w/in the DESCRIPTION?
   eg,
      "The operational mode of the TRIP applications.
 
       sendReceive(1)   :  <description here>
       sendOnly(2)      :  <description here>
       receiveOnly(3)   :  <description here>"

Section 6.2 - TRIP-MIB module
-----------------------------
1) tripCfgTable...
   Thee table DESCRIPTION says..
   "The objects in this table should be nonVolatile and
    survive reboot."

   - why don't you have a object of type StorageType in
     this table as you do for others?   seems it should
     for consistency since you mention it in the descr
     here.   such an object would only need r/o access.

   - what if a platform cannot provide NV storage of 
     the info in this table across reboots?  is this
     a requirment formalized by TRIP or more "desired" 
     behavior?  ie, is it really SHOULD or MUST?

2) tripCfgProtocolVersion...
   consider moving "RFC3219" to a REFERENCE clause.
   (i made a similar comment before wrt referencing
    I-D for this object)

3) tripOperStatus...
   we discussed this a bit in a previous version of
   the mib.  i asked you to consider another operstatus
   value to reflect when there was a fault in the system.
   you asked whether we really needed that because faults
   will be covered by notifications.  i responded with 
   reasons why that answer wasn't sufficient.  of course
   i left it as your call, so i guess i should just shut up.
   reading the mib again, though, the same thing struck me.
   it wasn't until i reviewed my email archive did i discover
   we'd already been over this issue.  

   exactly how is this handled by notifications?  which
   notification reflects a general fault with the trip LS?

4) tripCfgAddrInetAddrType...
   "tripAddr" -> "tripCfgAddr"
   
5) tripCfgAddr...
   i'd generalize "IP address" to just "address" and
   add words referring back to the InetAddrType object
   as the indicator of what type of address this object is.

6) tripCfgPort...
   why is port configurable (r/w) while address object
   isn't?

7) tripCfgMinItadOriginationInterval...
   "report" -> "reports"

8) tripCfgSendReceiveMode...
   "trip" -> "TRIP"

9) tripRouteTypeProtocolId...
   this object contains the following in the DESCRIPTION:
   "The size value of 116 has been assigned due to the
    sub identifier of object types length limitation as
    defined in SMIv2."

   what does that statement mean wrt this object?
   the SYNTAX TripApplProtocol doesn't shed any light.
   
   i'm confused.  maybe the next comment will make
   this all a moot point... read on.

10) tripRouteTypeTable vs. tripPeerRouteTypeTable
   can't these tables be combined?   add one additional
   object to differentiate "remote" from "local" and
   then you'd no longer need the address family objects
   form both tables to be both read-only AND part of 
   the INDEX clause... it could truely be the more
   "correct" not-accessible ;)

   see the attached file for a stab at what a combined
   table might look like.

11) tripSupportedCommunityTable...
   is "The TRIP Communities attribute" the same as
   the tripSupportedCommunityId object used to index
   this table?  is so, make is clearer that the
   indexing object of this table is that attribute.

12) tripSupportedCommunityEntry...
   need a period at the end of the DESCRIPTION.

13) tripSupportedCommunityStorage...
   is it a TRIP requirement (in a protocol sense) for
   such information to be NV?  will a platform that can't
   meet such requirements be considered non-compliant?
   
14) tripPeerTable...
   presumably entries in this table are remote peers only, right?

15) tripPeerState...
   a) be more clear on local vs. remote references.
      when you say "to the peer" or "from the peer"
      are you referring to the "remote peer"?  if 
      so please be explicit in the description.
   b) how do you have a entry in 'idle' state?   
      what types of "resources" are you referring to
      as not being allocated to the peer?  obviously,
      it wouldn't include resources used to represent
      the mib table entry ;)
   c) how long does 'idle' state usually persist?  is
      is generally so transient as to not be a useful
      state to represent in the mib??
   d) add a space in description of 'established' value.
      "NOTIFICATION,and" -> "NOTIFICATION, and"
  
16) tripPeerAdminStatus...
   a) is there a valid DEFVAL for this object or must
      it be given for row creation to succeed?  if the
      latter is the case, mention that in RowStatus object.
   b) what is the relationship between values of 
      tripPeerAdminStatus and the values of tripPeerState?
      down -> idle??

   ( i believe i asked about this before and david was
     going to look into it. )

17) tripPeerConnectRetryInterval...
   DESCRIPTION says... 
   "Attempt to set this value higher than the max
    retry should not be allowed."
   state more strongly... "will not be allowed".
   
18) tripPeerDisableTimer...
    should "of the peer" be "of the remote peer"?

19) tripPeerStorage...
   again, the issue of what about platforms that may
   not be able to do nonVolatile?   seems this needs
   to be generally addressed throughout the mib.

20) tripPeerRowStatus...
   the presense of this object would indicate that this
   table can be provisioned.  must it be or can some
   of these entries be learned via the workings of the
   protocol?

21) tripPeerStatsTable...
   a) "stats" -> "statistics"
   b) qualify when "this peer" or "the peer" is
      referring to "remote" peer.  total messages
      counter objects are explicit while the other
      objects in the table aren't.
  
22) tripPeerFsmEstablishedTime...
   say "entered 'established' tripPeerState."

23) tripRouteAddress...
   can you explain to me exactly how the 105 size limit
   was reached?  i presume it has something to do with
   the size of each index component and the overall object
   identifier length for objects in this table.  i
   didn't attempt to do the math, so could you summerize?
   you say "prefix"... it this then some limited form
   of the address - limited due to SMI issues?  

24) tripRouteTRIBMask...
   please expand TRIB acronym on first use.
   any rfc 3219 reference for these type bits?
   what does each type mean - more than just
   "adj-TRIBs-ins".

25) tripRouteLocalPref....
   any REFERENCE for this?

26) tripRouteAdvertisementPath & tripRouteRoutedPath...
   a) any REFERENCE for this?
   b) say "sequence of TripItads" rather than integers.
      that will establish what per itad boundaries are
      w/in the octet string (ie, ever 4 octets).
   c) i presume you mean each itad is in network byte order,
      right?  but what is the ordering of the entire sequence 
      of itads? which end of the overall octet string do you 
      start reading the path from?

27) tripRouteAtomicAggregation...
   not specific to this route table object, but in
   general does the capability represented by this
   object need to be made configurable somewhere?

28) tripRouteWithdrawn...
   how is this removal of a route accomplished?

29) how many route table entries can there be in a system?
   
30) how many communities can be associated with a route?

i probably have other comments on remaining portions of
the mib and draft doc, but i have to stop now.  i'll
email more tomorrow.

kevin

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   --
   --     tripRouteTypeTable
   --
       tripRouteTypeTable OBJECT-TYPE
         SYNTAX      SEQUENCE OF TripPeerRouteTypeEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "The TRIP peer Route Type table contains one entry per
             supported protocol - address family pair.  The objects in 
             this table are volatile and are refreshed after a reboot."
         ::= { tripMIBObjects X }

       tripPeerRouteTypeEntry OBJECT-TYPE
         SYNTAX      TripPeerRouteTypeEntry
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "An entry containing information about the route type that
             a particular TRIP peer (local or remote) supports.
             Each entry represents information about either the local
             or a remote LS peer.  The object tripRouteTypePeer is
             used to distinguish this.  In the case of a local LS,
             the address/port information will reflect the values
             configured in tripCfgTable.  In the case of a remote
             peer, the address/port information will reflect the
             values of an entry in the tripPeerTable."
         INDEX { applIndex,
                 tripRouteTypeAddrInetType,
                 tripRouteTypeAddr,
                 tripRouteTypePort,
                 tripRouteTypeProtocolId,
                 tripRouteTypeAddrFamilyId }
           ::= { tripRouteTypeTable 1 }

       TripRouteTypeEntry ::= SEQUENCE {
           tripRouteTypeAddrInetType       InetAddressType,
           tripRouteTypeAddr               InetAddress,
           tripRouteTypePort               InetPortNumber,
           tripRouteTypeProtocolId         TripAppProtocol,
           tripRouteTypeAddrFamilyId       TripAddressFamily,
           tripRouteTypePeer               INTEGER
       }

      tripRouteTypeAddrInetType OBJECT-TYPE
          SYNTAX      InetAddressType
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
              "The type of Inet Address of the tripRouteTypeAddr."
          REFERENCE
              "RFC 3291, section 3."
          ::= { tripRouteTypeEntry 1 }

      tripRouteTypeAddr OBJECT-TYPE
          SYNTAX      InetAddress
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
              "The IP address of this entry's TRIP peer LS."
          REFERENCE
              "RFC 3291, section 3."
          ::= { tripRouteTypeEntry 2 }

      tripRouteTypePort OBJECT-TYPE
          SYNTAX      InetPortNumber
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
              "The port for the TCP connection between this and
              an associated TRIP peer."
          ::= { tripRouteTypeEntry 3 }

       tripRouteTypeProtocolId OBJECT-TYPE
         SYNTAX      TripAppProtocol
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "The object identifier of a protocol that the associated
             peer is using."
         ::= { tripRouteTypeEntry 4 }

       tripRouteTypeAddrFamilyId OBJECT-TYPE
         SYNTAX      TripAddressFamily
         MAX-ACCESS  not-accessible
         STATUS      current
         DESCRIPTION
             "The object identifier of an address family that the
             associated peer belongs to."
         ::= { tripRouteTypeEntry 5 }

       tripRouteTypePeer OBJECT-TYPE
         SYNTAX      INTEGER { local(1), remote(2) }
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "This object identifies whether this entry is 
             associated with a 'local' or 'remote' LS peer."
         ::= { tripRouteTypeEntry 6 }

---

From: "David Zinman" <[email-masked]>
Date: Thu, 21 Nov 2002 10:45:10 -0500

inline.

Kevin,
Great idea to combine tripRouteTypeTable and tripPeerRouteTypeTable.
I wish I had seen that.

DZ

----- Original Message -----
From: "Kevin Lingle" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 19, 2002 3:38 PM
Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1

> Section 6.1 - TRIP-TC module

Done

>        receiveOnly(3)   :  <description here>"

I've added the text to the DESCRIPTION clause, but I'm not sure there
is anything left to add as far as descriptions, they are pretty self-
explanatory.

> Section 6.2 - TRIP-MIB module

done, made this object with r/w access.

>      behavior?  ie, is it really SHOULD or MUST?

The "desired" behavior of this object is stated by the
defval nonVolatile. I think this should be enough.

>    (i made a similar comment before wrt referencing

done

>    notification reflects a general fault with the trip LS?

I think you mean tripCfgOperStatus. I'm not sure what happened here,
this issue may have fallen through the cracks. Sorry. I will add
a 'faulty' state.

>    as the indicator of what type of address this object is.

done

>    why is port configurable (r/w) while address object

I've lost much of my email since these were written, but
I seem to remember talking about this with Dave W. I believe
that the consesus was to allow the user the flexibility to
use whatever port was needed, but allowing a change of
inet addr would impact too much on the TRIP network. Any
TRIP experts to set me straight on this?

>    this all a moot point... read on.

I changed the type of TripApplProtocol to integer.
I missed fixing that comment.

>    see the attached file for a stab at what a combined

That's a great idea. My only concern is that much of the
info for the local entry is redundant, but.... it's better
than a redundant table.

Thanks, I'll make the change.

>    indexing object of this table is that attribute.

Made the description clearer.

>    need a period at the end of the DESCRIPTION.

done

>    meet such requirements be considered non-compliant?

it is not a requirement. Fixed in description.

>    presumably entries in this table are remote peers only, right?

yes

>       so please be explicit in the description.

I think I've made the description clearer now.

>       state to represent in the mib??

True, the idle state should not persist for very long at
all unless the TRIP admin status was set to down. Then
the idle state should be constant.

>       "NOTIFICATION,and" -> "NOTIFICATION, and"

done

>       latter is the case, mention that in RowStatus object.

Gave it a defval of up(1)
>    ( i believe i asked about this before and david was

Fixed in comments. If tripPeerAdminStatus is down, then the state
would be idle(1).

>    state more strongly... "will not be allowed".

done

>     should "of the peer" be "of the remote peer"?

done

>    to be generally addressed throughout the mib.

done. It is not a requirement that this storage be non volatile.

>    of these entries be learned via the workings of the

Some entries can be learned. I will make this clear in the
description.

>       objects in the table aren't.

done

>    say "entered 'established' tripPeerState."

done

>    of the address - limited due to SMI issues?

Here is what the RFC says:

   Address:
   This is an address (prefix) of the family type given by Address
   Family.  The octet length of the address is variable and is
   determined by the length field of the route.

It is limited because of SMI issues. Although I understand
that this limitation might go away soon.

>    what does each type mean - more than just

made the description clearer.

> 25) tripRouteLocalPref....

yes, fixed.

>    a) any REFERENCE for this?

yes

>       start reading the path from?

I believe it a sequence from local to remote.

>    object need to be made configurable somewhere?

This is not a configurable item. It is a boolean based on the 
decision of an LS selection of a route.

>    how is this removal of a route accomplished?

The transmitting LS has determined that a route should
no longer be advertised, and is propagating this information 
to its peers.

> 29) how many route table entries can there be in a system?

I think it virtually unlimited depending on available resources.
Should this be stated somewhere?
 
> 30) how many communities can be associated with a route?

Again I think it is resource dependent.

> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: "David Zinman" <[email-masked]>
Date: Thu, 21 Nov 2002 10:45:10 -0500

inline.

Kevin,

DZ

----- Original Message -----
From: "Kevin Lingle" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, November 19, 2002 3:38 PM
Subject: [Iptel] comments on draft-ietf-iptel-trip-mib-04.txt - Part 1

Done

done

done

done

yes

done

done

done

done

done

   Address:

yes, fixed.

yes

 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel