IDPR MIB

[Robert Woody Woodburn <[e-mail]>]

Hi Danny, sorry I didn't get back to you sooner, but I've been spread
on a few too many things lately...


    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.

Well, I pretty much agree.  I guess I had used bit maps because I saw
similar examples elsewhere.  It seemed to go well with at philosophy of
reducing the number of objects.  I'm not sure which way to go on this, 
and would feel better if we got some comments from some real MIB folks.

	   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.

Seems like a reasonable change based on your philosophy.  One problem
is that adding objects for each field is not very extensible.  If we have
need for more flags later on, the existing objects could be maintained.

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

Hmm, actually I a bit confused.  The spec I have only has three error message
counter, and two are protocol message counters, not error condition counters.
I'm suprised because I thought I had a generic CMTP error in counter.  I
would favor a idprcmtpInErrs counter, rather than sub-protocol specific
counters to reduce the overall number of objects.

Taking a second look, I believe that the idprcmtpNak messages should take care
of this partially, however, I suppose there could be a situation where the
other side could not generate a Nak for a protocol error, or the message so
mangled that it couldn't be parsed.

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

Hmm.  Agreed.  Although, another solution would be a reverse table, but that
violates the redundancy avoidance principle.  If you feel extending the 
index to include all four fields is helpful, then I'd support that.  It 
will still be a pain to get the reverse information (VG -> PG mappings).  
Do you have a feel for which mapping will be used more.  I believe that at
the time I felt that the PG->VG map was more useful, but now I can't 
remember the rational.  Perhaps because from the managers point of view,
the manager is talking to PGs, and not VGs.


    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.

Agreed.  I was not up to date with the new spec.


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

Oops, yup, the description field is invalid.  It is supposed to represent
the number of flows associated with a given path (i.e. the number of 
`host entries' for a given path)  After some recent discussion on flows, 
I have two comments.  First, the word flow probably shouldn't be used, since
it now has been overloaded with the concept of resource guarantee in the
Internet community.  Second, I hadn't thought about the capability to 
use masks when I added this object, and a mask allows multiple "flows" to
be associated with a single host entry, (although the current implementation
doesn't install such host entries).

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

Absolutely.  I think I got cut'n'paste happy again.

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

Hmm, good point.  I think I may have intended to move them to the 
RTREQ group in the first place.  However, I'm not as convinced about
the RStab entry, since the information is used for flooding.  Actually,
there probably should be an RStab in RTREQ for servers that are queried,
and another in RID for servers to which we advertise along the lines of
what is in the configuration file (rsadvert, rssend).  There are really
three sets of information:	
	1.  RSs to whom we send updates as part of the flooding protocol
	2.  RSs whom we advertise as being authorities for the AD
	3.  RSs who have been advertised by others as available for
            queries

How this information is organized wasn't well thought out, since it isn't
really implemented anyway.  I rather like the idea of a single RS table and
then using flags (or independent objects as may be the case) to identify 
the function the entry is serving, one flag for each of the above cases.

I believe your comment about bitmaps also applies to the idprRSFlags field.

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

Hmm.  Another good point, especially with all the IP address discussion
going on right now.  I don't know if I like the idea of separate tables for
different types of addresses.  What do you think of something like a 
sockaddr structure where a field represents the address family and the rest
of the string is left to interpretation based upon the family.  But I don't
think you'll like that given your philosophy about bitmap flag fields.

    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

Umm, how will this be reflected in the protocol?  It sounds like when a 
manager would set the field then an update would be generated.  I don't
know if this is the appropriate mechanism.  To me it has the feeling of a
kludge when there really should be a change to the configuration file.

On the other hand, it could be a nice additional hook, and I know that you
folks need sucha hook.  Perhaps it could be an optional or enterprise
specific object.

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

Hmm.  I really violently dislike the thought of making the configuration file
encoding part of an SNMP definition.  I think this could be done, but it
will have to be part of an enterprise specific MIB and not the IDPR MIB.  I
wonder if the best thing to do is just define a source policy number and maybe
your active/inactive flag, but not define the entire policy in the actual
IDPR MIB.

    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.

Umm, I don't like this idea at all.  While I certainly see the advantage of
what you propose from the management station's perspective.  If the 
configuration format was more closely tied to the protocol spec, then there
would be more of a case, but I can't see it given the config spec is just
an implementation example.  I strongly feel that this sort of definition
is too far from the protocol spec.

Thanks for taking a pretty thorough look at the MIB!  It really needed
some more scrutiny and still needs a lot more shaking about.

wood y