IETF
roll@jabber.ietf.org
Monday, December 28, 2015< ^ >
Thomas Watteyne has set the subject to: IETF93 ROLL WG meeting
Room Configuration
Room Occupants

GMT+0
[02:04:24] <Michael Richardson> hi!
[13:27:40] Michael Richardson leaves the room: Disconnected: No route to host
[15:17:25] mcr2 leaves the room: Disconnected: Replaced by new connection
[15:17:25] mcr2 joins the room
[17:00:48] Michael Richardson joins the room
[17:06:31] Michael Richardson leaves the room: Disconnected: Replaced by new connection
[17:06:32] Michael Richardson joins the room
[17:45:56] Michael Richardson leaves the room: Disconnected: closed
[19:40:52] eintopf joins the room
[20:54:04] Michael Richardson joins the room
[21:53:01] Michael Richardson leaves the room: Disconnected: Replaced by new connection
[21:53:01] Michael Richardson joins the room
[22:00:04] <eintopf> mcr: my fosdem talk is rejected :(
[22:02:06] <eintopf> I told you, too many sumbission, few slots
[22:02:19] <eintopf> I hope I can hear something about big magic RPL
[22:02:45] <eintopf> okay for me it's magic right now, I never tried to get into it
[22:02:55] <eintopf> okay I tried, but then stopped
[22:03:10] <eintopf> other work to do
[22:13:31] <eintopf> and it's not easy
[22:15:06] <Michael Richardson> hi, they accepted mine, but I suspect that I won't make it.  I told them to give a slot to someone else.
[22:15:21] <eintopf> mh, okay. :(
[22:15:38] <Michael Richardson> I have not yet booked ticket; might still do that by end of week.  Some contracts are significantly delayed.
[22:16:06] <eintopf> oh
[22:16:17] <eintopf> but I am at netdev11
[22:16:51] <eintopf> ehm, I am at fosdem also
[22:16:56] <eintopf> but netdev11 accepted my talk
[22:20:37] <eintopf> there I can do some face2face discussion about handling neighbor discovery things for 6lowpan
[22:21:02] <eintopf> the NS/NA handling of rfc6775
[22:21:59] <eintopf> and of course the short address handling
[22:22:09] <eintopf> mhh
[22:44:12] <Michael Richardson> good!!!!
[22:44:31] <Michael Richardson> I think that we have to make up 10-byte addresses, 8+2.  Maybe there is a better way to do it, but I suspect not.
[22:45:59] <eintopf> yes that's one of the ideas which is around
[22:47:10] <eintopf> then if short address != 0xffff || != 0xfffe, use extended
[22:47:14] <eintopf> otherwise short
[22:48:00] <eintopf> for determine source address
[22:49:57] <eintopf> The only thing is maybe that the core netlink API which says "give me the mac address and put it in some array" will have more semantic
[22:50:16] <eintopf> it's then not just one mac address, it's two.
[22:50:57] <eintopf> then the complete netlink API will link-layer specfiic, but that's what net core api offers.
[22:51:33] <eintopf> I talked with one of my co-workers about that, they said "sounds like a hack"
[22:52:01] <eintopf> but then I can try to make some "dev_addr2" array inside struct net_device
[22:53:16] <eintopf> "dev_addr2" <- I would not do that, we can access the wpan_dev struct over the struct_netdevice and then get the short_address
[22:53:29] <eintopf> but the short address will den not be handled inside net core api
[22:55:29] <eintopf> btw: I don't know how slip solutions which doing 6lowpan adaptation at mcu side will ever handle that
[22:55:40] <eintopf> because it's not adaptable to ethernet
[22:57:09] <eintopf> so if we support that, then we have some useful stuff which others can't supported :-)
[22:59:44] <eintopf> but I think also to make 8+2 address change sounds the best option
[23:47:26] eintopf leaves the room: Disconnected: closed
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!