IETF
roll@jabber.ietf.org
Saturday, January 2, 2016< ^ >
Thomas Watteyne has set the subject to: IETF93 ROLL WG meeting
Room Configuration
Room Occupants

GMT+0
[12:43:50] eintopf joins the room
[13:54:05] eintopf leaves the room: Disconnected: closed
[15:37:17] eintopf joins the room
[15:43:59] <eintopf> hi
[15:45:27] <eintopf> I will stop the lifetime handling and "C=0 at first, then C=1 flag after some time" this is still ToDo but radvd timer handling is... much work and I don't want to put this logic into kernelspace (if that makes sense).
[15:45:39] <eintopf> for context option fields in RA
[15:46:10] <eintopf> it's enough to show how the basic architecture should work and I hope this is enough for my master course project
[15:46:35] <eintopf> I need to do some Poster session there :D I will announce it on linux-wpan mailinglist
[15:47:03] <eintopf> but maybe I can do some review about the poster
[15:47:53] <eintopf> (radvd timer) this is done by select(2) timeout handling and the timer handler has no "context information" there is only one use-case for the timer timeout "sending RA message"
[15:48:04] <eintopf> or processing RA
[15:48:56] <eintopf> but processing RA is normally not occured when select(2) timeout is there, this will check by some time_after/time_before timestamps
[15:50:06] <eintopf> radvd needs some a better "timer handling with context infromation for different callbacks" to do lifetime of 6CO/real deletion of 6CO/whatever.
[15:50:56] <eintopf> real deletion is more.. when the lifetime runs out it's at first C=0 and then after some time (300 secs (I think)) then real delete the context entry.
[15:51:21] <eintopf> and whatever should also a handling like "C=0 at first, then C=1 flag after some time"  for RA.
[15:51:53] <eintopf> I say here "after some time" because this is out of scope (if I can say that) of rfc6775
[15:52:51] <eintopf> Only when it is
   reasonable to assume that this information was successfully
   disseminated SHOULD an option with C=1 be sent, enabling the actual
   use of the context information for compression.
[15:53:06] <eintopf> that's good, I need to print that out on a big paper for the poster session.
[15:53:43] <eintopf> When
   the Valid Lifetime for a context table entry expires, the entry is
   placed in a receive-only mode, which is the equivalent of receiving a
   6CO for that context with C=0.  The entry is held in receive-only
   mode for a period of twice the default Router Lifetime, after which
   the entry is removed.
[15:53:45] <eintopf> that also
[15:54:09] <eintopf> that's what I mean with "real deletion is more.. when the lifetime runs out it's at first C=0 and then after some time (300 secs (I think)) then real delete the context entry."
[15:54:33] <eintopf> but I don't implement this yet
[15:55:34] <eintopf> reason is also what you said, maybe we put this handling in unstrung (routing userspace software) because routing software also use context information
[15:55:48] <eintopf> then radvd is wrong here, but okay to show "it works"
[16:15:25] <eintopf> btw: I think I will clear the context table if doing ifdown
[16:15:39] <eintopf> because the addresses are flushed also
[16:19:13] eintopf leaves the room: Disconnected: closed
[16:56:38] Michael Richardson leaves the room: Disconnected: No route to host
[18:14:40] Michael Richardson joins the room
[18:44:18] eintopf joins the room
[20:59:28] eintopf leaves the room: Disconnected: closed
[23:18:05] Michael Richardson leaves the room: Disconnected: No route to host
[23:53:08] Michael Richardson joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!