The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] NHRP MIB - comments
At 12:42 PM 2/4/98 +1000, David Horton wrote:
>
David,
Thanks for your comments.
-Joan
>
>Comments on draft-ietf-ion-nhrp-mib-02.txt
>+-----------------------------------------
>
>
> 1. nhrpNextHopRes table indexing and Uniqueness
>
> Why is internetwork address part of NextHopRes table
> key? It made sense when this was the unique
> identifier, but now there is the ResIndex. It is
> useful for an NMS to have the Internetwork address as
> the index key, but only if it is the first component
> of the INDEX. As it is it, there is no assistance in
> the INDEXing, it makes the OID unnecessarily long, and
> it is a pest to have to extract the address from the
> OIDs.
>
> We need to go one way or the other. The MIB as it
> stands doesn't take a stand properly on indexing. It
> should either
>
> - use a local significance integer only, or
>
> - use a truly identifying index.
The InternetworkAddr was never the unique identifier. It was
a combination of all the indices which made the entry unique,
except, as I pointed out in a previous email, that the PrefixLength
could change between a request and resolution. Thus, the ResIndex
was introduced to replace the PrefixLength.
I will change the the Res Index to be an integer which has local
significance only (as opposed to "unique within the scope of
this agent"). However, I doubt that in practice this will be supported,
I suspect that implementors will still implement this as a unique index, but
regardless, the description will change to:
nhrpNextHopResIndex ...
DESCRIPTION
"An identifier for this entry that has local significance within the
scope of the table."
I agree that there is probably more benefit to have the
order of the these indices change. I propose having:
nhrpNextHopResInternetworkAddrType,
nhrpNextHopResDestInternetworkAddr,
ifIndex,
nhrpNextHopResIndex
The benefit is that NMS can get all address of a specific type and they will
be sorted within that type.
NOTE Also: The nhrpServerNextHopResTable's indices will also change
accordingly.
>
> As well there is no indicator of non-unique
> registrations Suggest Boolean additional attribute in
> nhrpNextHopRes, nhrpNextHopUnique.
In the NHS's nhrpServerNextHopResTable (which extends the nhrpNextHopResTable)
there is a uniqueness indicator: nhrpServerNextHopResUniqueness (TruthValue)
I believe that this meets what you are requesting above.
>
> We have a question on the use of unique registrations.
> ---------- ----------
> | | NHS ( )
> | / \ )
> | NHC X Y A )
> | | ( )
> | | ( )
> ---------- ----------
> NBMA Legacy
> Subnet Subnet
> X is the NHS interface on the NBMA Subnet and
> registers uniquely with the NHS.
>
> NHC requests A with the uniqueness flag set. Can the
> NHS respond with X being the egress point?
>
I am unclear what you are asking here.
>
> 2. completeNeg
>
> Suggest allowing completeNeg to be valid for NHCs as
> well as NHSs. This allows the NHC to keep track of
> resolutions that have failed and thus must be sent on
> the routed path. This state is necessary for the NHC
> to keep so that it does not continuously resend
> resolution requests for a negative address, i.e., the
> client being in a hold down state for that address.
My understanding (and I could be wrong) is that am implementor
may want an NHC to continue trying indefinately under some
circumstances. If not, then the retry should be set to some
low number, and that would satisfy what you are suggesting and would
be a better solution.
If the NHC has tried it's required amount of times and failed
to receive a valid response, then there is no need to have a failed
entry in this table.
>
>
> 3. nhrpNextHopRes missing Preference
>
> The nhrpNextHopRes is missing the Preference value
> associated with a cache entry. Suggest adding this
> field.
>
Preference is something which is more implementation specific.
I don't see what value this adds to a cache entry, particularly if
different vendors are interoperating.
>
> 4. nhrpNextHopRes missing hold time
>
> The nhrpNextHopRes cache is missing the hold time of
> the cached information. Suggest adding the hold time.
If the cache entry was added by an adminstrator then
what would the value be here? I would think that the
entry would not age-out. Furthermore, this would only
have meaning once a positive resolution was received.
The nhrpClientTable does contain an nhrpClientHoldTime.
It may be of value to add to the nhrpServerNextHopResEntry
nhrpServerNextHopResHoldingTime OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds for which the cache entry is considered
to be valid. A value of zero indicates the EntryState is not
completePos(2) or the entry may not be active."
>
>
> 5. Transit state type in nhrpNextHopRes table can also
> be seen by the client if it examines the transit
> extension. Suggest changing the text to allow for the
> transit state to be used by the client.
Can you provide a reference based on the latest draft, 14, where
this behavior is described?
>
>
> 6. nhrpClientNhs missing InternetworkAddr
>
> Suggest adding the InternetworkAddr of the NHS. If
> this is unknown, then it is set to NULL.
Perhaps, another table (nhrpClientNhsInternetworkTable)
which is indexed by
nhrpClientIndex,
nhrpClientNhsIndex,
nhrpClientNhsInternetworkIndex <-- local significance within table
with read-create objects:
nhrpClientNhsInternetworkAddrType
nhrpClientNhsInternetworkAddr
nhrpClientNhsInternetworkRowStatus
Reference is Section 4.
I would think that such a table could be huge...
>
>
> 7. ifIndex/ifType.
>
> What should be valid values for the ifType of the
> interface present in the nhrpNextHopRes table?
>
> atm(37), ipOverAtm(114), or should NHRP have its own?
To clarify: the ifIndex in this table represents the ifIndex
of the subnetwork layer, (most likely atm(37)). Certainly,
more description is need in the front part of the document
to discuss ifIndex usage here.
>
> For IP, what is the mapping from the nhc index to the
> IP Addr table?
I believe the above table (answer to #6 above) provides information
to do this.
>
>
> 8. Missing mapping to the ifIndex There is no mapping of
> the NHC index to ifIndex, nor the NHS index to
> ifIndex. Suggest adding two tables:-
>
I'd like to think about this a little more, perhaps adding
to existing tables would be more beneficial.
>
>
>
> nhrpClientMappingTable OBJECT-TYPE
> SYNTAX SEQUENCE OF NhrpClientMappingEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " Table mapping the nhrp client index to the if index"
> ::= { nhrpClientObjects 4 }
>
> nhrpClientMappingEntry OBJECT-TYPE
> SYNTAX NhrpClientMappingEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " Table mapping the nhrp client index to the if index"
> INDEX {
> ifIndex ,
> nhrpClientIndex
> }
> ::= { nhrpClientMappingTable 1 }
>
> NhrpClientMappingEntry ::=
> SEQUENCE {
> nhrpClientMappingRowStatus
> RowStatus
> }
>
> nhrpClientMappingRowStatus OBJECT-TYPE
> SYNTAX RowStatus
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> " Allows for the creation and deletion of
> mapping entries"
> ::= { nhrpClientMappingEntry 1 }
>
> nhrpServerMappingTable OBJECT-TYPE
> SYNTAX SEQUENCE OF NhrpServerMappingEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " Table mapping the nhrp server index to the if index"
> ::= { nhrpServerObjects 4 }
>
> nhrpServerMappingEntry OBJECT-TYPE
> SYNTAX NhrpServerMappingEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " Table mapping the nhrp server index to the if index"
> INDEX {
> ifIndex ,
> nhrpServerIndex
> }
> ::= { nhrpServerMappingTable 1 }
>
> NhrpServerMappingEntry ::=
> SEQUENCE {
> nhrpServerMappingRowStatus
> RowStatus
> }
>
> nhrpServerMappingRowStatus OBJECT-TYPE
> SYNTAX RowStatus
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> " Allows for the creation and deletion of
> mapping entries"
> ::= { nhrpServerMappingEntry 1 }
>
>
>
> 9. Missing client specific NextHopRes table
>
> There are fields that should be kept in the NextHopRes
> which are specific to the NHC. Suggest adding a table
> similar to the nhrpServerNextHopRes table.
> nhrpClientNextHopResTable would include the following
> :-
>
>
> - nhrpClientNextHopResTimeUntilNextResRequest
>
> The amount of time the MPC must wait before
> issuing the next resolution request.
>
Retry Mechanisms are not discussed in this spec, and so
I believe this would be of little use in this MIB, although
it may be of use in an the enterprise MIB.
>
> - nhrpClientNextHopResLastNhrpCieCode INTEGER
> (0..255)
>
> The last NHRP CIE code received for this entry.
> This value is valid only during the Hold Down
> period of a negative cache entry. This value is
> undefined otherwise.
>
This may be useful for debugging, but is a transient value
and not too meaningful otherwise.
>
> - nhrpClientNextHopResServiceCategory INTEGER
> (0..65535)
>
> The service categories associated with this
> shortcut
>
>
> This was dropped from NHRP, but is in MPOA, so
> this would be in a MPOA-Friendly conformance
> statement. This and the following should have a
> line like:-
The MPOA MIB covers these, there is no good reason to
put these in NHRP also. In fact that would be duplicate
information in an MPOA device since the MPOA MIB specifies
that NHRP is being supported by MPOA.
>
> The following attributes are present for a MPOA
> Friendly device and will be identified as such by
> a conformance statement.
>
>
> - nhrpClientNextHopResMpoaTagValid TruthValue
>
> For MPOA friendly implementations (these 2
> attributes are only in MPOA friendly NHC
> implementation)
>
> If the value of this object is true(1), then a
> valid MPOA Cache Tag is present and the value of
> the MPOA Cache Tag is in
> nhrpClientNextHopResMpoaTag. Otherwise, if this
> value is false(2), then there was no MPOA Cache
> Tag, and the value of nhrpClientNextHopResMpoaTag
> is undefined.
>
>
> - nhrpClientNextHopResMpoaTag Integer32
>
> If a valid MPOA Cache Tag is present, then this
> object contains the value of that tag. To
> determine if this object contains a valid value,
> nhrpClientNextHopResMpoaTagValid should be used.
>
>
>
> 10. Nhrp Serving Domain There is no mention of the domain
> that the NHS serves. Is the subnet defined by
> nhrpServerInternetworkAddr's subnet. e.g. for IP,
> ipAdEntAddr/ipAdEntNetMask where ipAdEntAddr equals
> nhrpServerInternetworkAddr?
>
> Suggest adding a table nhrpServerDomain which includes
> :-
>
>
> nhrpServerDomainTable OBJECT-TYPE
> SYNTAX SEQUENCE OF NhrpServerDomainEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " A list of domains that a particular local NHS serves"
> ::= { nhrpServerObjects 5 }
>
> nhrpServerDomainEntry OBJECT-TYPE
> SYNTAX NhrpServerDomainEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " A list of domains that a particular local NHS serves"
> INDEX {
> nhrpServerIndex ,
> nhrpServerDomainInternetworkAddrType ,
> nhrpServerDomainInternetworkAddr ,
> nhrpServerDomainPrefixLength
> }
> ::= { nhrpServerDomainTable 1 }
>
> NhrpServerDomainEntry ::=
> SEQUENCE {
> nhrpServerDomainInternetworkAddrType
> NhrpIANAAddrFamily,
> nhrpServerDomainInternetworkAddr
> NhrpGenAddr,
> nhrpServerDomainPrefixLength
> Integer32,
> nhrpServerDomainRowStatus
> RowStatus
> }
>
> nhrpServerDomainInternetworkAddrType OBJECT-TYPE
> SYNTAX NhrpIANAAddrFamily
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " The type of the internetwork layer address of the
> server's domain. This object is used to interpret the
> value of InternetworkAddr."
> ::= { nhrpServerDomainEntry 1 }
>
> nhrpServerDomainInternetworkAddr OBJECT-TYPE
> SYNTAX NhrpGenAddr
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " The value of the internetwork layer address domain
> served by this server."
> ::= { nhrpServerDomainEntry 2 }
>
> nhrpServerDomainPrefixLength OBJECT-TYPE
> SYNTAX Integer32 (0..65535)
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> " The prefix length of the domain served by this NHS"
> ::= { nhrpServerDomainEntry 3 }
>
> nhrpServerDomainRowStatus OBJECT-TYPE
> SYNTAX RowStatus
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> " An object that allows entries in this table to be
> created and deleted using the RowStatus convention."
> REFERENCE
> " Textual Conventions for Version 2 of the Simple
Network
> Management Protocol (SNMPv2), RFC1903."
> ::= { nhrpServerDomainEntry 4 }
>
>
> 11. Mtu sizes
>
> The MTU size in the NHRP draft is only 16 bits, but is
> indicated in the mib to be 32 bits. Suggest changing
> to 16 bits.
>
ok.
>
> 12. nhrpServerMaxClients
>
> This is implementation specific and doesn't relate to
> anything in the protocol. What purpose does it fulfil
> for management purposes? Suggest removing.
>
ok.
>
> 13. nhrp Server Stats
>
> Should the NHS stats table be on a per interface
> basis?
>
If there were problems with an interface, there would be
issues elsewhere, so I'd prefer to keep stats tied to an
NHS.
>
>
> 14. nhrpNextHopRes
>
> There is no distinction of authoritative and non-
> authoritative responses. Suggest nhrpNextHopEntryState
> have extra completePosNonAuth and nhrpNextHopEntryType
> have an extra value resolveNonAuth.
I agree that it may be useful to add the resolveNonAuth to the
nhrpNextHopEntryType, but don't see a need for the EntryState
to change. In other words, completePos could be used for
either Authoritative responses or non-auth responses.
>
> This is required as the nhrp client will take
> different actions for the case of a NonAuth call set
> up failure to an Authoritative call set up failure.
>
> As well, this would allow the client to put into the
> cache a request for a non-auth mapping, and allow the
> ResEntryState to show that this was incomplete, i.e.,
> still resolving.
>
> What state do initial resolution requests go into?
That would be incomplete(1)
>
>
> 15. Only one internetwork address allowed per client in
> nhrpClient table though the NHRP registration protocol
> allows multiple registrations through allowing
> multiple CIEs in registration packets.
>
> How do you handle proxy registrations or non-unique
> registrations by a client? Suggest modifying the
> nhrpClientTable and adding a new table
> nhrpClientRegistrations as follows:-
>
>
> - Keep the current addresses in the nhrpClient
> table, these are the addresses that would go in
> the Mandatory header part of the NHRP messages.
>
>
> - Add an attribute
>
> nhrpClientUniqueReg TruthValue
>
> This would indicate if the client is to register
> with the Unique flag set.
>
>
> Create the nhrpClientRegistrations table with the
> following attributes:-
>
>
> nhrpClientRegistrationsTable OBJECT-TYPE
> SYNTAX SEQUENCE OF NhrpClientRegistrationsEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "Table of the CIEs to be sent in the NHRP registration
> request"
> ::= { nhrpClientObjects 7 }
>
> nhrpClientRegistrationsEntry OBJECT-TYPE
> SYNTAX NhrpClientRegistrationsEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "A CIE to be sent in the NHRP registration
> request for the client nhrpClientIndex"
> INDEX {
> nhrpClientIndex ,
> nhrpClientRegistrationsInternetworkAddrType ,
> nhrpClientRegistrationsDestInternetworkAddr ,
> nhrpClientRegistrationsPrefixLength
> }
> ::= { nhrpClientRegistrationsTable 1 }
>
> NhrpClientRegistrationsEntry ::=
> SEQUENCE {
> nhrpClientRegistrationsInternetworkAddrType
> NhrpIANAAddrFamily,
> nhrpClientRegistrationsDestInternetworkAddr
> NhrpGenAddr,
> nhrpClientRegistrationsPrefixLength
> INTEGER,
> nhrpClientRegistrationsNbmaAddrType
> NhrpIANAAddrFamily,
> nhrpClientRegistrationsNbmaAddr
> NhrpGenAddr,
> nhrpClientRegistrationsNbmaSubaddr
> NhrpGenAddr,
> nhrpClientRegistrationsPreference
> INTEGER,
> nhrpClientRegistrationsMTU
> INTEGER,
> nhrpClientRegistrationsNumRetries
> Integer32,
> nhrpClientRegistrationsLastNhrpCieCode
> INTEGER,
> nhrpClientRegistrationsRowStatus
> RowStatus
> }
>
> nhrpClientRegistrationsInternetworkAddrType OBJECT-TYPE
> SYNTAX NhrpIANAAddrFamily
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 1 }
>
> nhrpClientRegistrationsDestInternetworkAddr OBJECT-TYPE
> SYNTAX NhrpGenAddr
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 2 }
>
> nhrpClientRegistrationsPrefixLength OBJECT-TYPE
> SYNTAX INTEGER (0..255)
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 3 }
>
> nhrpClientRegistrationsNbmaAddrType OBJECT-TYPE
> SYNTAX NhrpIANAAddrFamily
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 4 }
>
> nhrpClientRegistrationsNbmaAddr OBJECT-TYPE
> SYNTAX NhrpGenAddr
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 5 }
>
> nhrpClientRegistrationsNbmaSubaddr OBJECT-TYPE
> SYNTAX NhrpGenAddr
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 6 }
>
> nhrpClientRegistrationsPreference OBJECT-TYPE
> SYNTAX INTEGER (0..255)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 7 }
>
> nhrpClientRegistrationsMTU OBJECT-TYPE
> SYNTAX INTEGER (0..65535)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> ""
> ::= { nhrpClientRegistrationsEntry 8 }
>
> nhrpClientRegistrationsNumRetries OBJECT-TYPE
> SYNTAX Integer32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "For this CIE, the number of times since the
> last valid registrations that this CIE has
> tried to register. This would be used by the
> NMS to see that a client is trying to register,
> but is failing."
> ::= { nhrpClientRegistrationsEntry 9 }
>
> nhrpClientRegistrationsLastNhrpCieCode OBJECT-TYPE
> SYNTAX INTEGER (0..255)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> " The last NHRP CIE code received for this entry."
> ::= { nhrpClientRegistrationsEntry 10 }
>
> nhrpClientRegistrationsRowStatus OBJECT-TYPE
> SYNTAX RowStatus
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> " An object that allows entries in this table to be
> created and deleted using the RowStatus convention."
> REFERENCE
> " Textual Conventions for Version 2 of the Simple
Network
> Management Protocol (SNMPv2), RFC1903."
> ::= { nhrpClientRegistrationsEntry 11 }
>
>
>
> 16. nhrpClientTable attributes.
>
> The following attributes are in the nhrpClientTable,
> but are not specified in the NHRP draft. We think that
> they are useful, and should be referenced in the NHRP
> draft.
>
>
> - nhrpClientInitialRequestTimeout
>
> - nhrpClientRegistrationRequestRetries
>
> - nhrpClientResolutionRequestRetries
>
> - nhrpClientPurgeRequestRetries
I don't believe there are direct references to these
in the spec, but they are implied so were called out
as objects to allow for easier configuration. I will
add the relevant references to the MIB.
>
> Suggest also to add the following attributes to the
> nhrpClientTable
I hesitate to put in values so specific to a retry mechanism
because the retry algorithm is up to the implementor. These
may be too specific/restricting for all retry implementations.
Besides, the retry mechanism should be documented in the
enterprise MIB.
>
> - nhrpClientHoldDownTime Integer32 (30..1200)
>
> Minimum time to wait before reinitiating a failed
> resolution attempt.
>
>
> - nhrpClientFlowRate Integer32 (1..65535)
>
> The number of packets in the nhrpClientFlowTime
> interval which represents a flow to a
> destination. When exceded, this initiates the
> NHRP resolution process.
>
> A value of 1 implies that resolutions for short-
> cuts are attempted for all flows.
>
>
> - nhrpClientFlowTime Integer32 (1..60)
>
> The time measured in seconds for the flow
> detection calculation.
>
>
> 17. RegistrationState is unclear for case where reregister
> before expiry. If a reregister fails to be
> acknowledged, but the original registration has a hold
> time that is unexpired, is the state 'registering',
> 'registered' or 'reRegisteringFault'? (I presume
> latter).
Okay, I can see why this may cause confusion. I'll rework
these descriptions. This is supposed to be an indication of
what the NHC is doing, so I'll focus on that.
>
>
> 18. representation of stabiliy bits and router bits Should
> the cache have a representation of the stability (S&D)
> bits and of the station type bit (Q) in a cached
> record?
These bits have value in the protocol, but don't necessarily
provide that much extra information to the cache entry.
>
>
> 19. The SYNTAX for the various client and server indices
> are inconsistent. ( Integer32 (1..2147483647),
> Integer32 (1..65535) ) Suggest changing the syntax to
> a textual convention
ok.
>
> NhcIndex ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "A unique value, for each nhrp client
> which this SNMP agent manages. It is recommended that
values
> are assigned contiguously starting from 1."
> SYNTAX Integer32 (1..2147483647)
> NhsIndex ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "A unique value, for each nhrp server
> which this SNMP agent manages. It is recommended that
values
> are assigned contiguously starting from 1."
> SYNTAX Integer32 (1..2147483647)
>
>
>=====================================================
>
> David Horton
> CiTR Pty Ltd
> Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064
> Email: d.horton@citr.com.au Phone +61 7 32592222 Fax +61 7 32592259
>X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
>X-Info: 'unsubscribe ion' in the body of the message.
>
X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with
X-Info: 'unsubscribe ion' in the body of the message.
|
|