The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1997-Apr> msg00127



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-ietf-ion-scsp-01.txt WG last call

  • From: Colin Verrilli <verrilli@raleigh.ibm.com>
  • Date: Thu, 24 Apr 97 14:06:17 -0400
  • Cc: ion@nexen.com


"JAMES V. LUCIANI" <jluciani@BayNetworks.COM> writes:
> There is almost certainly an algorithmic mapping (e.g., cache key=ip
> address) which is likely to not cause incorrect reuse.  In the absense of
> such then I think that the protocol specific document should describe this.
> The method by which keys are generated is in the realm of the protocol
> specific part.  It is probably worth saying this in the text though.
Well, I thought that the protocol didn't know anything about keys. The
SCSP mechanism should be the only one looking at keys (and all CSAS
information).
But, I agree that it would make life easier if the protocol generated the
key (and then forgot about it).

> One way is to merely use the largest CSA Sequence number with your OID
> which is received as part of the alignment for a given cache entry and add
> "k" to it and that is the new number to be used (no need to send new CSA
> unless the client reregisters with you).  If you do this and a client
> meanders off and registers with someone else then you have the default
> problem for dealing with duplicate entries with different OIDs (a problem
> (soon to be) previously solved *gulp*).
> 

What about entries that are there before you are aligned? What sequence
number do you start with for these? Seems like it would be easier to
just use Time of Day.


-- 
Colin Verrilli           <verrilli@vnet.ibm.com>        IBM Raleigh, NC