IETF
roll@jabber.ietf.org
Wednesday, 28 March 2012< ^ >
LAPCI0108B4863EA has set the subject to: ROLL
Room Configuration

GMT+0
[03:09:49] tzeta.tsao joins the room
[03:10:49] tzeta.tsao leaves the room
[04:10:28] tzeta.tsao joins the room
[04:32:40] mcharlesr leaves the room
[05:29:50] mcharlesr joins the room
[06:15:54] mcharlesr leaves the room
[07:04:03] mcharlesr joins the room
[09:33:37] mcharlesr leaves the room
[10:32:43] Daniel King joins the room
[10:59:57] mcr joins the room
[11:01:40] markushx joins the room
[11:01:40] tsavo_work@jabber.org/Meebo joins the room
[11:01:56] adrianfarrel joins the room
[11:02:21] <adrianfarrel> Anyone in this room not actually in the room?
[11:03:29] EskoDijk joins the room
[11:03:44] <mcr> hi.
[11:04:15] <Daniel King> Hey folks. Anyone participating remotely?
[11:04:20] <Daniel King> Is the audio ok?
[11:04:23] Ralph Droms joins the room
[11:05:44] cabo joins the room
[11:06:06] yuichi.igarashi@gmail.com joins the room
[11:06:10] <Ralph Droms> Is anyone scribing for those of us not in the room?
[11:07:12] <adrianfarrel> Dan, are you using etherpad?
[11:07:26] Daniel Gavelle [nxp] joins the room
[11:10:12] <Ralph Droms> I'm not seeing anything n etherpad.
[11:10:21] tsuichi joins the room
[11:10:47] thomas.heide.clausen joins the room
[11:11:40] <adrianfarrel> OK, I'll try to jabber a bit
[11:11:59] <adrianfarrel> So far warm words for change of chairs and RFCs published
[11:12:11] <adrianfarrel> MCR layer3 keying slide
[11:12:23] <adrianfarrel> This will be discussed in 2nd half of the meeting
[11:12:41] <adrianfarrel> main quesiton will be what decisions do we need to make
[11:13:00] <adrianfarrel> Pascal Thubert on applicablity statement
[11:13:12] <adrianfarrel> We are talking weekly, but some authors have been overwhelmed
[11:14:02] <adrianfarrel> Dan King says please coordinate across the appl statements to achieve common terminology
[11:14:05] Ralph Droms leaves the room
[11:14:55] <adrianfarrel> Chairs: need to close on security and appl. Maybe some extensions to do as well
[11:14:57] Stewart Bryant joins the room
[11:15:27] <adrianfarrel> Phil Levis on draft-ietf-rol-minrank-hysteria
[11:16:10] <EskoDijk> hysteria? :)
[11:16:40] <adrianfarrel> Oh my! Did I type that out loud?
[11:16:41] <Daniel King> :) I like the fact Apple sent a support engineer (Stuart)
[11:16:47] <adrianfarrel> Slide 2
[11:16:54] <adrianfarrel> In IETF last call
[11:16:59] <adrianfarrel> Slide 4
[11:17:10] <adrianfarrel> changes for AD review
[11:17:26] <EskoDijk> microphone of speaker seems to be off / far-away
[11:18:18] ws4d joins the room
[11:18:40] <adrianfarrel> he is fiddling with it now
[11:19:00] <EskoDijk> yes, better remote
[11:19:40] <adrianfarrel> "The Rules of Ripple" I saw that film in 1972
[11:20:05] <adrianfarrel> 1 is min cost path
[11:20:41] <adrianfarrel> 2 and 3 are different. 2 is parent set, 3 is path through parent
[11:20:48] <adrianfarrel> ETX xlide
[11:22:37] <adrianfarrel> Dominique is worried about corner cases where advertise ranks don't reflect ETX precisely
[11:22:49] Ralph Droms joins the room
[11:23:00] <adrianfarrel> Phil: yes. can occur as rank per hop increases per hop
[11:23:24] <adrianfarrel> Agree "care has to be exercised"
[11:23:37] <mcr> if one set a minrankincrease to such a high number, aren't you really saying, "I do not want a tree"?
[11:23:52] <mcr> s/tree/one-layer-of-dag/
[11:24:17] <adrianfarrel> Moves to next presentation
[11:24:37] <adrianfarrel> draft-gnawali...
[11:24:46] <adrianfarrel> Please give more feedback on implementaitons
[11:27:09] <adrianfarrel> David discusses the importance of routing table size
[11:27:28] <adrianfarrel> Phil "interop study not best place for scaling study, but better than nothing"
[11:27:41] <adrianfarrel> David: care to not draw inferences
[11:28:10] <adrianfarrel> Phil: what do you want us to put in the document? We want to document evidence and make recommendations
[11:28:54] <adrianfarrel> David: articulate the size of things and why. As the protocol has stopped changing we can start to optimise it. What is the size of the routing table. There are some crisp questions about what needs to be in the table
[11:29:19] <adrianfarrel> Phew Ralph is here
[11:29:25] <adrianfarrel> Does anyone else need me to jabber?
[11:31:00] <Ralph Droms> Thanks, Adrian.
[11:33:09] monden joins the room
[11:36:02] <Daniel King> Yes pls Adrian. I like your jabber comments.
[11:36:12] <Daniel King> Saves me taking minutes.
[11:36:38] <adrianfarrel> bog off, Dan =-O
[11:37:12] <adrianfarrel> Jari enters the room
[11:38:04] <adrianfarrel> Was I asleep when they explained jumping over draft-ietf-roll-applicability-ami ?
[11:38:26] <Ralph Droms> Thought that was later?
[11:39:23] <adrianfarrel> http://www.ietf.org/proceedings/83/agenda/agenda-83-roll.txt
[11:39:42] <Ralph Droms> Hm. You're right. Seems like we skipped from 3 to 5.
[11:39:56] <adrianfarrel> maybe square numbers are less important than primes?
[11:40:16] <Ralph Droms> A URL? How quaint. Try the IETFers app.
[11:40:18] <Daniel King> fibonacci sequence
[11:40:56] <thomas.heide.clausen> Did the chairs mention if it was being reshuffled, or not presented?
[11:41:28] <thomas.heide.clausen> [noting that, at least, some of the AMI applicability statement authors are present...]
[11:42:08] <Ralph Droms> I don't know - I wasn't in the room.
[11:43:38] <thomas.heide.clausen> Well, Well, the chair-slides http://tools.ietf.org/agenda/83/slides/slides-83-roll-3.pdf still lists AMI Applicability before P2P...
[11:43:47] alex joins the room
[11:44:34] <adrianfarrel> I suppose we could wait and see or ask a chair
[11:45:49] <thomas.heide.clausen> I am just curious - I thought that we were promised documents of that nature, but there has been no progress on this particular one (i.e. my objections from Taipei and before still apply) and I see no efforts on the other applicability statements....
[11:47:32] <adrianfarrel> "promise" is an interesting verb in a contribution-driven organisation
[11:48:33] <thomas.heide.clausen> Well, I am glad that the IETF has changed from being a "rough consensus" driven organization ... explains the state of RPL ;)
[11:50:51] mab joins the room
[11:52:20] Dan York joins the room
[11:53:54] <Stewart Bryant> Thomas - did you write a draft?
[11:54:51] <thomas.heide.clausen> Stewart, I have written several - anything in particular?
[11:55:06] <adrianfarrel> draft-clausen-lln-rpl-experiences-01
[11:55:18] <thomas.heide.clausen> That's one, yep.
[11:55:43] <Ralph Droms> Did anyone hear that change to the agenda?
[11:56:30] <thomas.heide.clausen> Ulrich says that it was announced in the agenda bashing, alas, I did not notice it then.
[11:56:58] <adrianfarrel> Rely on Ulrich to actually listen to what is going on
[11:57:00] Stewart Bryant leaves the room
[11:57:15] <thomas.heide.clausen> ;)
[11:59:54] Dan York leaves the room
[12:00:36] eckerted joins the room
[12:00:50] Stewart Bryant joins the room
[12:06:51] <adrianfarrel> Do smart water meters handle flooding?
[12:07:04] <adrianfarrel> Or is it limited to a trickle?
[12:10:06] tsavo_work@jabber.org/Meebo leaves the room
[12:12:04] <Ralph Droms> Adrian - I don't think the specs have been sufficiently well-baked to have a standard method for multicast. I can't speak to proprietary solutions.
[12:12:15] <Daniel King> As an FYI, the last set of slides ( draft-vanderstok-roll-mcreq-01) are being uploaded now.
[12:13:18] <Daniel King> http://www.ietf.org/proceedings/83/slides/slides-83-roll-5.pptx
[12:13:26] <mcr> have there been anyone remote who had questions?
[12:14:23] <Ralph Droms> I haven't seen any...
[12:16:19] <adrianfarrel> The only one was "could you use the mic?"
[12:19:15] tsavo_work@jabber.org/Meebo joins the room
[12:20:42] <mcr> if you are in a non-storing network, don't all the nodes know that, and could plan for the source routing header. I agree that it might be hard to know how big it should be, but on average it might not much worse than your rank#...
[12:34:52] <thomas.heide.clausen> You could always plan for worst case, of course.
[12:35:19] <thomas.heide.clausen> Which, alas, also means that you plan for poor utilization of your channel capacity. If you're OK with that...
[12:36:04] <adrianfarrel> Question. Are networks never allowed to partition under multi-failure conditions?
[12:36:07] tsavo_work@jabber.org/Meebo leaves the room
[12:36:33] <thomas.heide.clausen> Adrian: to the security preso, or to something else?
[12:37:08] <Ralph Droms> Do you mean concurrent failures of multiple nodes?
[12:37:10] <adrianfarrel> to your comment
[12:37:27] <adrianfarrel> @ralph yes
[12:37:30] <thomas.heide.clausen> Partitioning was something we actually saw, which caused multiple "floating DODAGs" to happen - which triggered that our network behaved "weirdly"
[12:37:55] <thomas.heide.clausen> "weirdly"as we had not provisioned all for being DODAG roots.
[12:38:22] <adrianfarrel> so it is not possible to supress becoming a dodag root?
[12:38:55] <Ralph Droms> @adrian: My understanding is "yes". Partitioning can occur with even a single failure (of course).
[12:38:58] <thomas.heide.clausen> Hmm....
[12:39:08] <thomas.heide.clausen> You can, of course, decide to not become a DODAG root.
[12:39:26] <thomas.heide.clausen> And have just one DODAG root in your network, with all other devices refusing that role even for internal connectivity.
[12:39:33] <thomas.heide.clausen> Alas, that's a single-point-of-failure
[12:39:52] <adrianfarrel> well you seem to offer all or nothing. I was wondering about "some"
[12:39:58] <thomas.heide.clausen> As was discussed in homenet (I think): loosing the ability to print to your printer in your house, just because your ISP breaks down, is bad.
[12:39:59] <adrianfarrel> Noting I am not an implementer
[12:40:03] <Ralph Droms> @thomas: and then converge to a new dodag?
[12:40:21] <thomas.heide.clausen> @ralph: sorry, lost the prvious?
[12:40:45] <Ralph Droms> "decide not to form a dodag"
[12:40:51] <adrianfarrel> Actually, that example is precisely what I have for the last 2 months. I am here and my printer is in my house
[12:40:53] <thomas.heide.clausen> @adrian: Actually, I think that I am trying explicitly to offer "all" or "something less than all"
[12:41:23] <thomas.heide.clausen> As in: if my router provisioned as DODAG root falls out, I still want internal connectivity
[12:41:28] <adrianfarrel> right "something less than all" sounds right
[12:41:30] <thomas.heide.clausen> (if possible, that is)
[12:41:32] <Daniel King> http://www.ietf.org/proceedings/83/slides/slides-83-roll-6.ppt
[12:42:10] <Ralph Droms> @thomas: why did the node decide to form a new dodag rather than waiting to be "healed" into the existing dodag?
[12:42:32] <thomas.heide.clausen> But, that is the thing: to offer "something less than all" (internal connectivity, even of LBR / DODAG Root dies), then unless I have an extremely planned network, all devices need to be provisioned as DODAG root
[12:43:05] <thomas.heide.clausen> @ralph: well, there was no existing DODAG for long enough, and the network was deployed for (also) internal connectivity.
[12:43:44] <thomas.heide.clausen> @ralph: so, after "more than a threshold of no LBR present", the policy was "form floating DODAG as permitted by RPL spec"
[12:44:18] <thomas.heide.clausen> @ralph: with the notion of "and do so if you think you are the closest to the now defunct dodag root"
[12:44:23] <Ralph Droms> So the dodag repair exceeded some threshold, which the node interpreted as loss of dodag, even though there was enough connectivity to eventually form a dodag?
[12:44:56] <thomas.heide.clausen> Actually, what happened was (when we observed it) that the battery ran out on the original DODAG root
[12:44:56] <Ralph Droms> (messages crossed in flight)
[12:45:20] <thomas.heide.clausen> So there was still connectivity the 1-hop-from-dodag-root was fully meshed
[12:45:46] <thomas.heide.clausen> (that 1-hop-fully-meshed was by accident, not design)
[12:45:51] <Ralph Droms> Dodag root failure is different from interior link failure. I was curious why interior link failure caused floating root formation.
[12:46:35] <thomas.heide.clausen> It shouldn't (typically)
[12:46:48] <thomas.heide.clausen> My slides showed the DODAG root going up in flames ;)
[12:47:01] <Ralph Droms> Root failure obviously causes floating dodag. Link failure would, i think, cause dodag restructure.
[12:47:39] <Ralph Droms> Sorry, missed that detail.
[12:48:12] <thomas.heide.clausen> Link failure *may* cause dodag restructure (if possible)
[12:48:40] <thomas.heide.clausen> But, may also cause floating DODAG (partitioning, wanting to maintain internal connectivity in each partition). But, I agree that this is rarer.
[12:49:16] <Ralph Droms> So, one can still hypothesize that all nodes require resources for full dodag in the case of dodag root failure ... *unless* the the dodag can be organized with "backups" one hop from the root.
[12:49:57] <thomas.heide.clausen> Well, I do not know if I will agree with exactly that.
[12:49:59] <thomas.heide.clausen> But....
[12:50:09] <thomas.heide.clausen> I will agree with that if you know your failure models well enough...
[12:50:30] <Ralph Droms> ... And deployment models.
[12:50:40] <thomas.heide.clausen> .....you _may_ get away with placing fewer strategically positioned "backup roots"
[12:51:07] <thomas.heide.clausen> Alas, then we are ending up in deployments that are not applicable, for example, for some of the scenarios that we're interested in
[12:51:17] <thomas.heide.clausen> (whereas it would be applicable for others)
[12:53:37] ws4d leaves the room
[12:53:53] <thomas.heide.clausen> This is, incidentally, one of the things - one of the restrictions on deployment - that I thought the "applicability statement documents" had (Adrian, are you paying attention, get ready to jump...) promised to spell out , with their importance for various scenarios
[12:56:13] rogeralexar joins the room
[13:00:23] alex leaves the room
[13:00:37] Daniel King leaves the room
[13:00:37] tsuichi leaves the room
[13:01:49] tsuichi joins the room
[13:03:06] eckerted leaves the room
[13:03:07] tsuichi leaves the room
[13:03:07] cabo leaves the room
[13:03:16] yuichi.igarashi@gmail.com leaves the room
[13:03:31] tzeta.tsao leaves the room
[13:03:52] EskoDijk leaves the room
[13:04:14] Stewart Bryant leaves the room
[13:04:32] Daniel Gavelle [nxp] leaves the room
[13:05:32] rogeralexar leaves the room
[13:07:37] adrianfarrel leaves the room
[13:08:25] mcr leaves the room
[13:09:19] eckerted joins the room
[13:12:27] adrianfarrel joins the room
[13:13:07] Ralph Droms leaves the room
[13:13:12] cabo joins the room
[13:13:17] mcr joins the room
[13:14:04] tsuichi joins the room
[13:14:11] tsuichi leaves the room
[13:15:37] monden leaves the room
[13:16:14] mab leaves the room
[13:17:06] Daniel Gavelle [nxp] joins the room
[13:17:08] adrianfarrel leaves the room
[13:17:11] markushx leaves the room
[13:18:08] cabo leaves the room
[13:18:37] cabo joins the room
[13:20:26] Stewart Bryant joins the room
[13:21:36] eckerted leaves the room
[13:24:25] nestor.tiglao joins the room
[13:27:45] mcr leaves the room
[13:30:23] monden joins the room
[13:36:00] monden leaves the room
[13:51:56] Stewart Bryant leaves the room
[14:02:08] nestor.tiglao leaves the room
[14:10:38] cabo leaves the room
[14:12:01] adrianfarrel joins the room
[14:13:50] Daniel Gavelle [nxp] leaves the room
[14:22:09] adrianfarrel leaves the room
[14:31:09] Daniel Gavelle [nxp] joins the room
[14:34:39] Daniel Gavelle [nxp] leaves the room
[14:37:35] adrianfarrel joins the room
[14:47:46] Daniel Gavelle [nxp] joins the room
[14:53:07] cabo joins the room
[15:25:19] adrianfarrel leaves the room
[17:34:10] cabo leaves the room
[17:39:24] cabo joins the room
[17:41:48] Stewart Bryant joins the room
[17:45:47] Stewart Bryant leaves the room
[18:08:41] cabo leaves the room
[18:24:19] mcr joins the room
[19:28:13] thomas.heide.clausen leaves the room
[20:56:24] mcr leaves the room
[20:59:20] mcr joins the room
[21:01:39] mcr leaves the room
[21:16:13] mcr joins the room
[21:23:57] Stewart Bryant joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!