Comments on IDPR MIB

[Danny Lee <[e-mail]>]

Greetings,

We are currently implementing a MIB for the GATED implementation of IDPR,
and we have come across several comments and issues which would like to
discuss.  Hopefully, these comments and issues are of interest to the
IDPR community.  The comments are organized according to the object group
to which it applies.

    o VGP Group

	-- The desirability of overloading the idprPGFlags object to
	   hold disparate types of information is not immediately
	   obvious.

	   As currently defined, idprPGFlags holds status and identity
	   type information in different bit positions.  Defining an
	   object-specific encoding scheme like idprPGFlags implies
	   that a management station needs to know how to handle an
	   application syntax that is encoded within the description
	   field.  My impression is that objects such as idprPGFlags would
	   be difficult for management station to map into a human readable
	   strings in a pre-defined and consistent way, unless all possible
	   states of the bit vector are defined.  We certainly do not
	   want the user to interpret octal or hexadecimal numbers.

	   The above comment also applies to the idprVGFlags object, although
	   at the current time the object holds only status information.

	   I would like to suggest that idprPGStatus and idprPGType be
	   defined in place of idprPGFlags, and for idprVGFlags to be
	   renamed to idprVGStatus.  The idprPGStatus and idprVGStatus
	   objects should, of course, have an enumerated integer syntax.

	-- For completeness, it seems that an additional object should
	   be defined for the VGP group.

               idprvgpUpDownInErrs    OBJECT-TYPE
                    SYNTAX    Counter
                    ACCESS    read-only
                    STATUS    mandatory
                    DESCRIPTION
                         "The number of invalid up/down messages received.
                          Up/down messages improperly addressed are tabulated
                          by this object, along with other generic errors."
                    ::= { idprvgp x }

	-- The idprPGMap table does not allow many-to-many type associations.
	   The index definition does not provide a unique key for identifying
	   a specific row in the table.  This problem will occur when
	   a PG belongs to multiple VGs, not all which terminate at the
	   same adjacent domain or VG.

	   One possible solution is to extend the index field to include
	   idprPGMapAdj and idprPGMapVG when referring to a specific
	   object instance.

	   If the intention was never to support many-to-many associations,
	   then the idprPGMap table should be folded into idprvgpPGTab.
	   There is no immediate benefit for having two tables that
	   use the same set of indices and refer to similar types of data.

    o  Routing Information Distribution Group

	-- idprridPer and idprridLif should be split up to cover
	   the case when each parameter differs for configuration
	   and dynamic messages.

	-- On the basis of the MIB description field, the idprPathFlows
	   object appears to be redundant to idprPathMsgs.  If the
	   idprPathFlows object is not redundant, what type of flow
	   specification is being referred to: average and/or peak
	   bandwidth, delay, etc.?  In any case, a single object is
	   probably insufficent with respect to encoding flow spec data,
	   even if it can be argued that a flow spec is desireable at
	   this part of IDPR.

	-- idprridReqInt and idprridReqRet should probably be grouped
	   together with the idprridReqIns, idprridReqOuts, and idprridRStab
	   entries.  This will make it clearer to the reader what
	   idprridReqInt and idprridReqRet refer to.

	-- It seems that idprridReq* and idprridRStab objects
	   should either have a group of their own or be moved into
	   the RTREQ group.  Route requesters and route servers are
	   cooperating aspects of the same functional role.  The objects
	   in question do not appear to fit well within the RID group.

	-- It may be desirable in the future to redefine idpraddrSrc
	   and idpraddrDst to have generic address structures.  As
	   presently defined, the address structure is specific to IP.
	   The syntax of the ipaddrSrc and ipaddrDst should be generalized
	   to support other address formats.  By the same logic, perhaps
	   the port fields should be renamed SAPs.  Alternatively, it may
	   be perhaps better to simply rename idpraddrTab to idprIpAddrTab
	   to reflect the orientation of the table, since objects such as
	   idpraddrSrcMask and idpraddrDstMask are IP specific.

    o Source Policy Table

	-- I think it may be useful to have a status field associated
	   with each source policy; e.g., 

               idprSrcPlcyStatus     OBJECT-TYPE
                    SYNTAX    INTEGER {
                                active(1),
                                inactive(2)
                              }
                    ACCESS    read-write
                    STATUS    mandatory
                    DESCRIPTION
                          "Status of source policy.  Writing the value
                          inactive(2) for a defined source policy causes
                          the policy to be ignored.  Changing the state
                          to active(1) re-enables the source policy."
                    ::= { idprScrPlcyEntry 2 }

	   When a source policy entry is declared inactive, the route
	   preference attributes in the source policy definition should not
	   be used to bias or constrain route selection.  Similarly, the
	   mapping to requested services should be defeated when a source
	   policy is in the inactive state

	-- The source policy table objects should have read-write access
	   attributes.  As part of our work, we hope to be able to
	   instantiate source policies dynamically via SNMP channels.
	   (Yes, we're ignoring security issues :-)

	-- Consensus regarding the encoding of the idprSrcPlcyInfo object
	   needs to be reached.  We would like to initially propose that
	   the ASCII syntax suggested in the IDPR configuration guide be
	   followed.

	   Our initial thought is to adopt the ASCII syntax, since we can
	   tie in the existing GATED LEX/YACC parser for this function.
	   (Yes, we realize specs should place all implementations on neutral
	   ground.  However, since there is really only one implementation
	   of IDPR, this may be a moot issue :-)

	   Whichever approach taken should be consistent with the
	   idprTrnPlcyInfo object.

    o Transit Policy Table

	--  As with source policies, we think it will be useful to have
	    a status object for transit policy table entries.

              idprTrnPlcyStatus     OBJECT-TYPE
                    SYNTAX    INTEGER {
                                active(1),
                                inactive(2)
                              }
                    ACCESS    read-write
                    STATUS    mandatory
                    DESCRIPTION
                         "Status of transit policy.  Sending the value
                          inactive(2) to a defined transit policy puts
                          the policy into a state where it is no longer
                          advertised.  Note that changing the status to
                          inactive(2) does not necessarily remove the
                          entry from the transit policy table.  Changing
                          the state to active(1) re-enables the transit policy."
                    ::= { idprTrnPlcyEntry 4 }

	-- The transit policy table objects should have read-write access
	   attributes.  As with source policies, we hope to be able to
	   instantiate transit policies dynamically via SNMP channels.

	-- There are at least two possible encodings for transit policy
	   information.  The first option is to follow the syntax specified
	   in the IDPR configuration guide.  The second option is to adopt
	   the packet format used for configuration messages.  As mentioned
	   above, the approach chosen should be consistent with the encoding
	   for the idprSrcPlcyInfo object.

I have a revised version of the IDPR MIB which takes into account
the comments mentioned above, along with some other minor changes.
Before sending out this revised version to the IDPR MIB working group
for review, feedback on any of the above comments would be warmly welcomed.

Thanks in advance,

Danny Lee.