Subject: RE:ServerID length

From: cliff wang <[email-masked]>
Date: Mon, 15 Dec 1997 09:44:29 -0500

Sorry for the truncated message. It got lost somewhere. This is the
repost about ServerID length.

> Something like this extra table, and using the SCSPIDEntryidIndex in
> scspDCSTable replacing scspDCSID, and in scspLSTable replacing 
> scspLSID.

>     SCSPIDEntryEntry OBJECT-TYPE
>         SYNTAX   SCSPIDEntryEntry
>         MAX-ACCESS       not-accessible
>         STATUS   current
>         DESCRIPTION
>                 "Server ID entry"
>         INDEX   {
>                  SCSPIDEntryidIndex
>                 }
>         ::= { SCSPIDEntryTable 1 }

>     SCSPIDEntryEntry  ::=
>         SEQUENCE {
>                 SCSPIDEntryidIndex INTEGER,
>                 SCSPIDEntryid OCTET STRING
>                 }                     

Although creating additional table to map SGID to an index is
doable, I object to such scheme unless that is the only way to do
it. Basically, everytime you want to get server information, you
have to search through the intermediate table and do server ID mapping 
in order to get the index into the server table. This is not an ideal
solution. Using extra table and table searching/lookup is
expensive when the table gets larger. In addition whenever a server
entry gets deleted, the index table also needs to be updated.
Maintaining two tables are not efficient.

Using Server ID directly as index is the most direct way to get server
information. Actually, the LSID is kind of redundant, since there is
only one Local Server per Server group. SGID plus PID can identify the
LS uniquely. But ServerID is needed to identify DCS. BTW, NHRP MIB 
uses an octet string (0..60) as a table index ("nhrpNextHopResDestAddr"
for nhrpNextHopResTable).

> P.S. If you are still going to restrict the SCSP specification to fit
> the MIB by making the serverID length six bits (a questionable
> approach), then the OCTET STRINGs should have a size of 0..63 and not
> 0..64.     

Maybe I didn't explain clearly in my last reply. Actually I am not
trying to restrict the SCSP specification. MIB implementation
should always follow protocol instead of adding restrictions. 
Suggestion of using 6 bits has good reasons behind it, not just
because of SNMP implementation restriction.  For most practical
implementations, serverID is probably the server protocol Address (such
as its IP addr), 63 bytes is long enough to cover every existing 
address type.  I am sure no realistic user would like to choose a
ServerID longer than 63 bytes. Plus, it is wasteful in SNMP
implementation to have a 255 octet string filled with most zeros.
I discussed ServerID length with Jim Luciani at IETF this week and we
agreed that server ID of 6 bit is enough.

-- 

*************************************************
  Cliff Wang                                    
  IPSEC/IPV6 team,  Dept.L04A/NHD               
  International Business Machines Corp.         
  800 Park Offices Drive, G418/B664             
  Research Triangle Park, NC 27709              
  Email: [email-masked]                
  Voice: (919)486-1255 (IBM T/L 526-1255)       
  Fax:   919-254-0391                           
*************************************************

---

From: Hoylen Sue <[email-masked]>
Date: Tue, 16 Dec 1997 16:54:01 +1000 (EST)

Cliff,

 > it.

I agree totally!  It will be inefficient and messy.  However, it
probably is the only correct solution to fully support the current SCSP
specification which allows 255 byte Server IDs.

If the SCSP uses only six bits, then I'm all for your 0..63 solution.

Hoylen
__________________________________________________________ Dr Hoylen Sue
[email-masked]                                        +61 7 3259 2222
CiTR Pty Ltd, PO Box 1643, Milton, 4064, Australia. Fax: +61 7 3259 2259
http://www.citr.com.au           http://www.dstc.edu.au/RDU/staff/hoylen