Subject: (ION) NHRP MIB - comments

From: David Horton <[email-masked]>
Date: Wed, 04 Feb 98 12:42:14 +1000

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.

      As well there is no indicator of non-unique
      registrations Suggest Boolean additional attribute in
      nhrpNextHopRes, nhrpNextHopUnique.

      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?

  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.

  3.  nhrpNextHopRes missing Preference

      The nhrpNextHopRes is missing the Preference value
      associated with a cache entry. Suggest adding this
      field.

  4.  nhrpNextHopRes missing hold time

      The nhrpNextHopRes cache is missing the hold time of
      the cached information. Suggest adding the hold time.

  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.

  6.  nhrpClientNhs missing InternetworkAddr

      Suggest adding the InternetworkAddr of the NHS. If
      this is unknown, then it is set to NULL.

  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?

      For IP, what is the mapping from the nhc index to the
      IP Addr table?

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

          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.

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

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

 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.

 13.  nhrp Server Stats

      Should the NHS stats table be on a per interface
      basis?

 14.  nhrpNextHopRes

      There is no distinction of authoritative and non-
      authoritative responses. Suggest nhrpNextHopEntryState
      have extra completePosNonAuth and nhrpNextHopEntryType
      have an extra value resolveNonAuth.

      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?

 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

      Suggest also to add the following attributes to the
      nhrpClientTable

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

 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?

 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

          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: Joan Cucchiara <[email-masked]>
Date: Fri, 13 Feb 1998 22:03:22 -0500

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

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.

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

I am unclear what you are asking here.

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

>      associated with a cache entry. Suggest adding this

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

>      transit state to be used by the client.

Can you provide a reference based on the latest draft, 14,  where
this behavior is described?  

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

>      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

I believe the above table (answer to #6 above) provides information
to do this. 
>      ifIndex. Suggest adding two  tables:-

I'd like to think about this a little more, perhaps adding
to existing tables would be more beneficial.

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

>           period of a negative cache entry.  This value is

This may be useful for debugging, but is a transient value 
and not too meaningful otherwise. 
 
>         - nhrpClientNextHopResServiceCategory INTEGER

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.

>      indicated in the mib to be 32 bits. Suggest changing

ok.

>      for management purposes? Suggest removing.

ok.

>      Should the NHS stats table be on a per interface

If there were problems with an interface, there would be
issues elsewhere, so I'd prefer to keep stats tied to an
NHS.

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

>      What state do initial resolution requests go into?

That would be incomplete(1)

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

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.

>      'registered' or 'reRegisteringFault'? (I presume

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.

>      bits and of the station type bit (Q) in a cached

These bits have value in the protocol, but don't necessarily 
provide that much extra information to the cache entry.

>      Integer32 (1..65535) ) Suggest changing the syntax to

ok.

---

From: Joan Cucchiara <[email-masked]> (by way of Joan Cucchiara <[email-masked]>)
Date: Wed, 04 Mar 1998 18:43:42 -0500

David,

Here is more discussion.  Sorry that this is
so long...

	Thanks, Joan

At 02:51 PM 2/16/98 +1000, David Horton wrote:
>Joan,
>
>We have included some clarifications below. 
>It makes for a rather long email, sorry everyone.
>
>regards,
>David
>
>
>> David,
>> 
>I would question whether this is sufficient reason to add complexity
>to the agent. 

The agent needs to maintain this info anyway, sorting on addresses
vs. a simple integer is more complex, however, for faster lookups
the protocol itself will be more interested in sorting on addresses
(either directly or with some sort of hash) and that is where the 
benefit is.  I should have pointed this out previously
(although it's true that the NMS will benefit, this is probably not the
better motivation...the better motivation is that the protocol
uses the addresses to index into these tables and so the agent can 
hopefully can leverage off of this.)

>> In the NHS's nhrpServerNextHopResTable (which extends the
nhrpNextHopResTable
>)
>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.

okay, I'll take it out of the server specific table and add it to the
general table.

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

I'm not sure that I understand the above paragraph, 
state for this object  (nhrpNextHopResEntryState)
is read-only.  There is no mechanism to override this or change it.  

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

I would like to propose adding another State, incompleteNeg, with the
description 'The client has received a NAK resolution response, but is
still in the process of issuing retries.  However, once the client has
retried the specified amount of times (as shown in
nhrpClientResolutionRequestRetries)
then this cache entry should be removed from the table.'

I do not agree that the NHC should keep NAK cache entries around AFTER
retrying the specified amount of times, but agree that there may be some
merit in 
letting the user know that the NHC is retrying even after receiving a NAK.
  
>
>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.
>
>
>> 
>> >
>> >
>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

The preference field has relevance if the NHC receives a successful 
resolution reply from a responding NHS with multiple CIEs.  
However, it is implementation specific whether the NHC 
caches all of these CIEs or only the one
with the highest preference (which should be the first CIE).  

This will be added, but comparing preferences for all Entries is not
really possible, since the NHSs could all be from different vendors.

>
>Are the other CIEs present in the table with higher ResIndex values?
>
>> 
>> >
>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.

ok.

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

ok.

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

I am leaning toward NOT adding these tables, simply because 
the ifIndices can be figured out with the various addresses which
are available.  Supporting these tables would be somewhat painful
and since we are not using ifIndex in this mib (except in one place),
there is not a lot of benefit. 

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

David, an NMS can certainly use the MPOA MIB directly to find
out whether MPOA is being supported.  It's not necessary to 
duplicate information like this.

>Was this OK?

Section 2.2 of the spec states, "...Each NHS serves a set of destination
hosts, which may or may not be directly connected to the NBMA subnetwork.
NHSs cooperatively resolve the NBMA next hop within their logical NBMA
subnetwork.
In addition to NHRP, NHSs may support "classical" ARP service; however,
this will be the subject of a separate document."

I don't think that adding this table at this time is appropriate. 
Besides which other routing tables which are supported by the routing
entity should provide this information. 

>> >                      " A list of domains that a particular local NHS
serves
>"
>> >                      " A list of domains that a particular local NHS
serves
>"
>OK
>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 relates back to our questions on non-unique registrations. Is this OK?

David, I will need to check on this.  I can understand why you
are leaning towards a Table for entering non-unique registrations
although, I have trouble believing that a user will really want
to do this.    

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

---

From: Joan Cucchiara <[email-masked]>
Date: Thu, 05 Mar 1998 11:02:10 -0500

David,

I am following up on the Client Registration Table issue.
This email deals only with that topic (other subjects
which have been covered in the prior email are deleted.)

	-Joan

Ps my comments are embedded below.

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

My understanding is that the non-unique registrations requests
were so that an NHC could register addresses in multiple subnets
which are behind the client in a single registration request using
multiple CIEs.

These subnets behind the client are not easily aggregatable based
on prefix length, so an entire CIE was used.  

Concerning the table below.  I cannot find any specific reference in the
NHRP spec where a user should configure this information (i.e. the ability of
a user to configure a non-unique registration request with multiple CIEs.)
I have serious doubts as to users typing in all this info, so would
like to have more feedback from others as to if such a table is wanted.
Comments are welcomed.

Currently, I propose that we do not include this table.
However, the nhrp Client should probably have some of this info
available as read-only.  Do you agree?

	Thanks, Joan