Subject: Re: [6lowpan] #67: Clarfication about the Neighbor Cache

From: Richard Kelsey <[email-masked]>
Date: Tue, 01 Jun 2010 14:00:32 -0400

> From: "6lowpan issue tracker" <[email-masked]>
> Date: Sat, 29 May 2010 12:16:12 -0000
> 
> #67: Clarfication about the Neighbor Cache
> --------------------------------+-------------------------------------------
>  Reporter:  zach@…              |       Owner:     
>      Type:  enhancement         |      Status:  new
>  Priority:  trivial             |   Milestone:     
> Component:  nd                  |     Version:     
>  Severity:  -                   |    Keywords:     
> --------------------------------+-------------------------------------------
>  Pascal commented on the list that the Neighbor Cache is used differently
>  than in RFC4861 thus it should have a different name etc. The use of
>  Neighbor Cache in nd-09 is however 80-90% common to the use in RFC4861 so
>  the Neighbor Cache name should be kept and as a single cache. The
>  maintenance of entries in the nd-09 Neighbor Cache is based on address
>  registration with the lifetime set buy the host, thus the following text
>  will be added to clarify the difference in the terminology under
>  registration and in Section 5.5:
> 
>  "Thus for 6LoWPAN the Neighbor Cache doesn't behave like a cache. Instead
>  it behaves as a registry of all the host addresses that are attached to
>  the Router."

I'm sorry, but I don't find the clarification very clear.
What is the significance here of the Neighbor Cache being a
registry and not a cache?  Is it that the entries should
(SHOULD? MUST?) not be removed before they expire?

                                -Richard Kelsey

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 01 Jun 2010 12:28:41 -0700

> (SHOULD? MUST?) not be removed before they expire?

Yes. 6lowpan-nd-09 already has text saying that entries not be removed 
until they expire, but it might help to also state that this means that 
it behaves more as a registry than as a cache.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Jun 2010 08:26:48 +0200

Hi Richard:

The trick is that the abstract data structure used for both is really similar. So it is highly tempting to describe them as a unique thing.

But the lifecycles of a cache and a registry have nothing in common. So I proposed to describe them as 2 different abstract entities and then explain their interaction should they both be present in a same router, like glean a cache entry from a registration or remove a cache entry upon optional NUD.

Obviously, this is all abstract and my goal was to make it the operations clearer to the reader, not to constrain an implementation. More in the thread "proposed changes for ND".

Cheers,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Kelsey
> Sent: Tuesday, June 01, 2010 8:01 PM
> To: [email-masked]
> Subject: Re: [6lowpan] #67: Clarfication about the Neighbor Cache
> 
> > --------------------------------+-------------------------------------
> > --------------------------------+------
> > --------------------------------+-------------------------------------
> > --------------------------------+------
> >  Pascal commented on the list that the Neighbor Cache is used
> > differently  than in RFC4861 thus it should have a different name etc.
> > The use of  Neighbor Cache in nd-09 is however 80-90% common to the
> > use in RFC4861 so  the Neighbor Cache name should be kept and as a
> > single cache. The  maintenance of entries in the nd-09 Neighbor Cache
> > is based on address  registration with the lifetime set buy the host,
> > thus the following text  will be added to clarify the difference in
> > the terminology under  registration and in Section 5.5:
> >
> >  "Thus for 6LoWPAN the Neighbor Cache doesn't behave like a cache.
> > Instead  it behaves as a registry of all the host addresses that are
> > attached to  the Router."
> 
> What is the significance here of the Neighbor Cache being a registry and not a
> cache?  Is it that the entries should (SHOULD? MUST?) not be removed
> before they expire?
> 
>                                 -Richard Kelsey
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 02 Jun 2010 00:18:22 -0700

On 06/ 1/10 11:26 PM, Pascal Thubert (pthubert) wrote:
> Hi Richard:
>
> The trick is that the abstract data structure used for both is really
> similar. So it is highly tempting to describe them as a unique
> thing.
>
> But the lifecycles of a cache and a registry have nothing in common.
> So I proposed to describe them as 2 different abstract entities and
> then explain their interaction should they both be present in a same
> router, like glean a cache entry from a registration or remove a
> cache entry upon optional NUD.
>
> Obviously, this is all abstract and my goal was to make it the
> operations clearer to the reader, not to constrain an implementation.
> More in the thread "proposed changes for ND".

The conceptual model is that there is only one data structure, Hence
there is no need to describe their interaction.

I suspect having a conceptual model with two data structures and the 
associated description of their interactions will most likely lead to 
more complex implementations. In any case it is more complex to describe 
that model. And it doesn't seem to add any benefits.

Of course, as long as the externally visible behavior is the same as in 
the conceptual model, an implementation can use two or more data 
structures to represent what is conceptually one data structure.

    Erik

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Sun, 06 Jun 2010 21:00:17 -0000

#67: Clarfication about the Neighbor Cache
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:        
     Type:  enhancement         |       Status:  closed
 Priority:  trivial             |    Milestone:        
Component:  nd                  |      Version:        
 Severity:  -                   |   Resolution:  fixed 
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Added in nd-10.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/67#comment:1>
6lowpan <http://tools.ietf.org/6lowpan/>