Subject: Re: (ION) NHRP MIB - comments

From: David Horton <[email-masked]>
Date: Mon, 16 Feb 98 14:51:07 +1000

Joan,

We have included some clarifications below. 
It makes for a rather long email, sorry everyone.

regards,
David

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

I would question whether this is sufficient reason to add complexity
to the agent. 

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

5.2.3 NHRP Registration Request
    U
       This is the Uniqueness bit. When set in an NHRP Registration
       Request, this bit indicates that the registration of the protocol
       address is unique within the confines of the set of synchronized
       NHSs.  This "uniqueness" qualifier MUST be stored in the NHS/NHC
       cache. 

Thus the uniqueness is needed in both the NHS and NHC cache, that is why we
suggest putting in the uniqueness field in to the nhrpNextHopRes table.

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

Non-unique registrations were introduced to NHRP without a lot of
discussion on the list. What I am trying to get a feel for is the
circumstances when a client will 
(a) register a non-unique address,
(b) explicitly request a resolution for a unique address.
e.g. are they intended for doing proxy registrations of devices
on a legacy subnet bridged by an NHC? (An alternative to MPOA).

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

 From Guidelines for Next Hop Client (NHC) developers
                           <draft-carlson-nhrp-00.txt>

   6. Need for State
   ....
   Some of the features of this state are:
   ....
      3.    Both ACK and NAK data should be cached for the length of the
            holding time parameter in the NHRP response.

   Since state must be maintained, the questions of where to maintain it,
   how to manually managed it, and how to selectively override it need to
   be addressed.  No matter where this state information is kept, a method
   for manually examining and changing this state information must be
   provided.  This is essential to insure that the network is operating
   properly.

Thus it is necessary for the NHC to maintain data for the NAK cache entries.

Compare this to the MPOA "HOLD DOWN" state. 
A resolution has failed, and given a number of reties it would
appear that for the moment it will stay that way. We do not want
the NHC to continue retrying NHRP resolution of that address.
The egress point may not be MPOA/NHRP, and there may be no router
along the path willing to act as a part-way shortcut.
MPOA defaults to 160 secs.

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

The preference value is needed so that the semantics of the NHC's cache
entry in the MIB shows 
(1) the CIE with the best preference
(2) the CIE which actually accepted the shortcut setup request

Are the other CIEs present in the table with higher ResIndex values?

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

nhrpClientHoldTime is only the hold time that the NHC uses in the nhrp registra
tion
request, not the hold time of the cached entries. As above, the hold time
is necessary. For the cases of administrator added entries, the hold time
would be ignored. Suggest adding as follows:-
nhrpNextHopResHoldingTime OBJECT-TYPE
     SYNTAX Integer32
     MAX-ACCESS read-create
     STATUS current
     DESCRIPTION
        "If the nhrpNextHopResEntryType for this entry is not
	staticNonVolatile, and the nhrpNextHopResEntryState is either
	completePos, or completeNeg then this represents  number of seconds for
	which the cache entry is considered to be valid. Otherwise, this
	value is undefined."

This undefined value may be 2^31 -1, i.e, MAX INT. This may be useful for
highlight entries which do not time out.

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

>From draft-ietf-rolc-nhrp-14.txt

5.3.1  Responder Address Extension
...
   CIE Code
     5 - Insufficient Resources
       If the responder to an NHRP Resolution Request is an egress point
       for the target of the address resolution request (i.e., it is one
       of the stations identified in the list of CIEs in an NHRP
       Resolution Reply) and the Responder Address extension is included
       in the NHRP Resolution Request and insufficient resources to
       setup a cut-through VC exist at the responder then the Code field
       of the Responder Address Extension is set to 5 in order to tell
       the client that a VC setup attempt would in all likelihood be
       rejected; otherwise this field MUST be coded as a zero.  NHCs MAY
       use this field to influence whether they attempt to setup a cut-
       through to the egress router.

5.3.2  NHRP Forward Transit NHS Record Extension
   CIE Code
     5 - Insufficient Resources
       If an NHRP Resolution Request contains an NHRP Forward Transit
       NHS Record Extension and insufficient resources to setup a cut-
       through VC exist at the current transit NHS then the CIE Code
       field for NHRP Forward Transit NHS Record Extension is set to 5
       in order to tell the client that a VC setup attempt would in all
       likelihood be rejected; otherwise this field MUST be coded as a
       zero.  NHCs MAY use this field to influence whether they attempt
       to setup a cut-through as described in Section 2.2.  Note that
       the NHRP Reverse Transit NHS Record Extension MUST always have
       this field set to zero.

2.2 Protocol Overview
...
   When a source station is unable to communicate
   with the responder (e.g., an attempt to open an SVC fails), it may
   attempt to do so successively with other subnetwork layer addresses
   in the NHRP Forward Transit NHS Record Extension until it succeeds
   (if authentication policy permits such action).  This approach can
   find a suitable egress point in the presence of subnetwork-layer
   filtering (which may be source/destination sensitive, for instance,
   without necessarily creating separate logical NBMA subnetworks) or
   subnetwork-layer congestion (especially in connection-oriented
   media).

Thus the NHC does use the transit extension data.

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

5.2.3 NHRP Registration Request
   When an NHS receives an NHRP Registration Request which has the
   Destination Protocol Address field set to an address which belongs to
   a LIS/LAG for which the NHS is serving then if the Destination
   Protocol Address field is equal to the Source Protocol Address field
   (which would happen if the NHC put its protocol address in the
   Destination Protocol Address) or the Destination Protocol Address
   field is equal to the protocol address of the NHS then the NHS
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   processes the NHRP Registration Request after doing appropriate error
   checking (including any applicable policy checking).

5.3  Extensions Part
5.3.1
 If an NHS has more
   than one protocol address, it SHALL use the same protocol address
   consistently in all of the Responder Address, Forward Transit NHS
   Record, and Reverse Transit NHS Record extensions.

Thus the NHC only needs to know the protocol address of the NHS on the
LIS/LAG for the LIS/LAG on which the NHC is registering. Thus the NHC only
needs to know one protocol address per NHS. Thus I do not think that there
is a need to provide the separate nhrpClientNhsInternetworkTable.

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

It is recommended (Appendix V MPOA Spec) that the NHC 
1.  Support the use of the MPOA tag extension.
2.  Support the use of the service category extension.

For the case of the NHC being in a pure NHRP domain (where there are no
MPOA devices, i.e., the NHC is not associated with an MPC), the tag and
service category are not stored in any other MIB table. That is why we
suggest adding these to the nhrpClientNextHopRes table, and using a
conformance statement about MPOA-Friendly devices.

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

Was this OK?

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

OK

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

The rationale is that a call-setup failure for a non-authoritative
resolution results in the sending of a new authoritative request.
(OK I am being picky. Either table would do).

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

This relates back to our questions on non-unique registrations. Is this OK?

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

OK. MPOA progressed this work quite well, but the model doesn't 
cover other strategies such as triggering all TCP connections
but not UDP (say).

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

OK

> 
> 
> >
> >
> > 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: [email-masked]      Phone +61 7 32592222   Fax +61 7 32592259

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Eric W Gray <[email-masked]>
Date: Mon, 16 Feb 1998 08:14:06 -0500

David,

You wrote:
...
> on a legacy subnet bridged by an NHC? (An alternative to MPOA).

In the text from draft-ietf-rolc-nhrp-14.txt - relating to the 
uniqueness bit - there is a fairly complete description of at
least one instance when a non-unique address registration may
occur.  That is, when the address being registered is a prefix
associated with an entire subnet.

An interesting twist on this, however, is what does it mean to
get a different next hop for a specific address within a range
than was received from an earlier request for the corresponding
subnet.  If my memory is not completely failing me, it means
that the next hop for the subnet is invalidated by the newly
determined next hop for the specific address.

Assuming that it is meaningfull to have "unique" registrations 
that are "better" (more specific) than non-unique registrations,
it is easy to imagine an implementation that always asks first
for unique resolutions and then - on receipt of NAK code 13 
"Binding Exists But Is Not Unique") - asks for a non-unique 
resolution.

-- 
Eric Gray