[13:58:56] bnsmith joins the room [14:05:20] tutu joins the room [14:05:35] tutu leaves the room [14:06:12] pthubert@cisco joins the room [14:27:43] TJ joins the room [14:32:16] Hi TJ [14:33:58] 'Ello [14:34:08] ... top of the morning. [14:34:17] R U in Minne? [14:34:30] Yes [14:34:35] In NIce [14:34:49] I hope I'll be in SF though [14:35:17] I don't know yet if I'll be @ SF ... req management buy in :) [14:35:42] But no travel right [14:35:47] You're still there? [14:35:56] I might not be the TJ you think I am ... [14:36:03] :) [14:36:12] Oups: TJ Kniveton [14:36:19] no? [14:36:43] Well if not nice meeting you :) [14:36:51] Nope ... allow me to introduce myself; TJ Evans, with CommandInformation (IPv6 consulting / design / engineering / pre-certification /etc /etc) ... [14:37:13] Pascal Thubert, cisco (you might have guessed) [14:37:26] Nice to "meet" you as well ... [14:37:45] :) [14:37:54] 6LowPAN will be good today [14:38:02] don't miss Zach's presentation [14:38:14] he has great slides (I found) [14:38:44] I look forward to it [14:39:17] call [14:39:28] talk to you in person next time [14:39:58] hopefully! [14:44:23] Pete St. Pierre joins the room [14:46:20] dmw.winter joins the room [14:50:20] pthubert@cisco leaves the room [14:50:26] Pascal Thubert joins the room [14:57:06] cabo joins the room [14:58:41] yes [14:58:46] Hi Pascal [14:58:49] Hi Carsten [14:59:03] Hi Geoff [14:59:07] bonjour [14:59:16] Sound's a bit low [14:59:27] :^0 [15:00:19] Better now? :) [15:00:25] yes [15:00:50] Carsten is beginning the meeting. [15:01:25] standard RFC 3979 IPR disclaimer made [15:01:47] Slide 3: agenda [15:03:09] no proposed agenda changes. [15:03:10] Slide 4 [15:04:36] Carsten notes: 6lowpan makes 802.15.4 look "almost" like an IPv6 link [15:04:47] slide 5: milestone review [15:06:26] yuichi joins the room [15:07:04] slide: Draft status use cases [15:07:18] Use cases draft in WGLC [15:07:35] correction: want to be ready for WGLC by next meeting [15:08:06] slide 11: [15:08:19] Routing Requirements [15:08:33] Eunsook Kim speaking [15:09:01] First slide: Draft status [15:09:37] (Current draft @ http://tools.ietf.org/html/draft-dokaspar-6lowpan-routreq-08) [15:09:56] next slide [15:10:24] slides are unnumbered [15:10:34] next slide "Major Changes" [15:10:39] #4 [15:11:25] slide 5 [15:12:11] lion joins the room [15:13:12] (Solicitation for feedback ...) [15:13:12] carsten commenting [15:13:22] pee joins the room [15:14:17] JP Vasseur commenting [15:14:24] Carsten : 32 is not scientifically chosen (routing table entries) [15:14:59] JP's comment: what is the WG going to do with this draft [15:15:49] Geoff M: 6lowpan not specifically chartered to do protocol. this document may be used by other groups. [15:15:55] JP what is the goal ... Carsten: publish it ... conversation ensues ... ~"Chartered to create an informational document for other WGs to reference .. .we do not (currently) design the routing protocols" [15:17:22] JP's comment: much of this is reflected in the roll routing req. drafts. [15:17:31] JP: ~"90% of these requirements are not LoWPAN specific ... (seems to believe this belongs solely in ROLL) ... "agree to disagree" ... [15:17:33] Geoff disagrees. [15:18:30] Carsten: this document deals specifically with 802.15.4 which is a well defined set. [15:19:07] ShoichiSakane joins the room [15:19:44] Carsten : "We have a well defined market" ... JP:"Yes, we need to deal with it ... but this is not LoWPAN specific .. low memory, mow CPU" ...Carsten:"But how low? this market is well deifned, we have (LoWPAN) chipsets in the market ... have numbers to work with .. little use in debating the value of the charter at every meeting, rather work on fulfilling the charter" [15:20:26] Mark Townsley commenting [15:21:53] Summary of Mark's comment to JP: "even if 80% of this overlaps roll, roll should accept the input" [15:21:58] Mark : ~"If this doc will be ignored, then we have a problem ... this WG's charter was approved to design the LoWPAN req's, even if ther is 80% overlap / non-LoWPAN specific" ... ~"Work is happening here" ... ~"comments to date not constructive" [15:22:21] JP:~"should delineate what is LoWPAN speciifc and what is not" [15:23:15] Mark: ~"But this doc is trying to achieve the stated goal, with an eye for 15.4's needs and overlap is good" [15:24:14] JP: are we going to do routing at the adaptation layer? [15:24:19] Geoff: We don't know yet. [15:24:26] JP: Is mesh under something the IETF will be doing? Several: Not our charter currently ... [15:25:35] David Culler commenting [15:26:55] lion leaves the room: Computer went to sleep [15:28:38] David: voices support for this doc, and wants to encourage further refinement: 1) Is 6LoWPAN dependent upon 15.4 format and/or protocol? Make the answer clear ... 2) Impact of routing on Header Compression, and vice versa 3) 1494 / mesh routing header is defined ... existing mesh routing non-conformant ... this should be talked in this doc. [15:29:18] ((general consensus that these are good points)) [15:30:03] slide 6 [15:30:30] ( reminder: audio feed can be found @ http://videolab.uoregon.edu/events/ietf/ietf735.m3u ) [15:32:28] one comment missed [15:32:32] ______: Autoconf mtg this afternoon recommended, collides with ROLL mtg :( [15:32:41] thanks [15:34:29] lion joins the room [15:34:37] Pete St. Pierre leaves the room [15:35:10] Pete St. Pierre joins the room [15:36:43] David: will need to clarify / comes to grips with MAC-but-not-really-MAC ... mentions defective beacon method ... low duty cycle ... cautions about dictating non MAC behavior (IIUC) Geoff: More talk on 15.4 dependent stuff ... "we need to decide" ... "How do we decide?" ... how much of that MAC are we dependent upon David: ... Arch doc tried, maybe revisit ... PAN coord bad match (DHCP/autoconf) ... things left unimplemented ... beacon + TDMA / sample lsiten cycling and the hybridization of these ... we must cater to these ... Do we depend on rigid scheduling? How do we not break ... [15:36:46] Pete St. Pierre leaves the room [15:36:46] TJ leaves the room [15:36:46] dmw.winter leaves the room [15:36:58] TJ joins the room [15:37:03] who's that? [15:37:21] Did the room die for everyone, or just me? [15:38:11] Pete St. Pierre joins the room [15:38:11] Pete St. Pierre leaves the room [15:39:41] dmw.winter joins the room [15:40:08] (Still on slide 7) [15:43:12] Pete St. Pierre joins the room [15:43:12] (Slide 8) ... security and mesh fwding (r14-18) [15:43:12] Pete St. Pierre leaves the room [15:43:34] Solicits input ... [15:44:59] David : Opportunity here to see transitions in 15.4 ... routing implications = retrans/ack is important ... currently sent unprotected ... commercial implementations today tend to use data packet rather than HW ack ...move towards encr/auth is needed (stupid to have left it out). [15:46:17] (Slide 9) ... need feedback ... ready for WG draft? ... hope to finish by EOY. (Any volunteers??) [15:47:42] lion leaves the room: Replaced by new connection [15:48:13] Pete St. Pierre joins the room [15:48:13] Pete St. Pierre leaves the room [15:48:19] lion joins the room [15:48:23] Carsten: So, shall we make this a WG doc? ... very little participation ... Mark: Is there a competing doc? Is it chartered work? Asks David & JP specifically to ensure supporting work? Why would we not do this? ... noone opposed. [15:48:42] ... motion carries, it is a WG doc. [15:48:55] Next up: IPv6 Header Comp for LoWPANs ... [15:49:53] Slide23 - 4944 fails to address some things ... trying to define framework for doing more generalized compressions [15:50:18] ((Draft @ http://tools.ietf.org/html/draft-ietf-6lowpan-hc-02)) [15:50:36] TJ: 03 is actually out [15:50:55] Thx, missed that - http://tools.ietf.org/html/draft-ietf-6lowpan-hc-03 ... [15:51:17] (Agenda references older ... ) [15:51:28] We published yesterday :) [15:51:58] just in time delivery, eh? [15:52:10] That's right [15:52:29] Slide 26 ... Traffic Class and Flow Label handling ... [15:53:14] Slide 27 ... Hop Limit handling ... maybe debate 64 being the right "middle" value [15:53:23] Pete St. Pierre joins the room [15:53:24] pee leaves the room [15:53:24] Pete St. Pierre leaves the room [15:54:00] pee joins the room [15:55:06] Slide 28 ... Context handling ... Identifier Extension ... default vs "+src, dst context" appendage ... is 16 enough? (Note: exact # is out of scope; concern over severe resource constraints) [15:56:57] Slide 29 ... Src Addr compr ... SAC=0 is stateless, link local ... new part == SAC=1 is context based [15:57:26] Pete St. Pierre joins the room [15:57:26] Pete St. Pierre leaves the room [15:57:57] Slide 30 ... Uni ... [15:58:48] Pete St. Pierre joins the room [15:58:48] Pete St. Pierre leaves the room [15:59:10] Slide 31 ... MCast - new stuff ... 4 cases ... stateless [15:59:59] Slide 32 ... Mcast - more new, stateful .. accounts for Unicast Prefix Based MCast ... [16:00:46] Slide 33 - UDP ... checksum inline or not ... port comp cases ... [16:02:03] Pete St. Pierre joins the room [16:02:03] Pete St. Pierre leaves the room [16:02:41] test [16:02:52] MIC is not hop by hop [16:03:04] We are talking about transport level MIC [16:03:20] Jonathan is right [16:03:28] Geoff: few comments ... Hop Limit Comp, using 2 bits to save 8 bits (stoeln from dispatch space) ... choose 64 as middle value ... ... conversations ... using "premature optimization" ... maybe use default Hop Limit from RA? ... checksum comp - impact on intermediate nodes ... ... [16:03:51] Pete St. Pierre joins the room [16:03:51] Pete St. Pierre leaves the room [16:04:03] That's a matter of apreciation [16:04:11] it looks smells like udp [16:04:19] need to go through the INternet [16:04:22] the firewalls [16:04:23] etc [16:04:41] when the packet is recomposed, it is a UDP packet [16:04:47] with checksum [16:05:11] Carsten reading Pascal's comments ... [16:05:11] that's right [16:05:21] Pete St. Pierre joins the room [16:05:21] Pete St. Pierre leaves the room [16:05:37] right [16:05:40] it is [16:06:46] No [16:07:04] ____(missed name) : questions about skipping checksum, decompression / recompression ... ____2 (missed name again) : define end to end here; w/i LoWPAN or real E2E ... [16:07:06] There will be a checksum and a MIC [16:07:17] Geoff is wrong [16:07:42] No!!!! [16:08:01] This is UDP [16:08:31] the checksum computation is done but the router that expands the packet [16:08:36] No [16:09:22] Then the receiver receives a true UDP packet [16:09:31] If the checksum is wrong it drops it [16:09:40] otherwise it checks the MIC [16:09:49] if the MIC si wrong then it drops it [16:10:22] Pete St. Pierre joins the room [16:10:44] David: CID: Likes draft overall, but :when in doubt leave it out" ... the real cost is not in number of bits, but in the number of test cases for interop ... tiny namespaces bad ... compression is compression, not the everycase ... votes for reserving the bit, but not defining currently. [16:13:58] Carsten: Concern over CID as well, set to 0 when communication w/i LoWPAN A: Yes, or carrying comp addr. Carston: use cases / when applicable .. .seems like a very small of uses. David: if default context is subnet, Carsten : CID0 means both S and D are compressed? A: It means an address (or both) are compressed. Carsten: Let's be sure to evaluate "If this would actually get used?" ... can be done vs should be done ... consider simplify doc by removing? ... [16:15:49] David: very few cases where it wasn't obvious it would be used ... questions assumption of widespread global scope, at the expesne of other optimizations [16:16:40] Erik: the ND spec, the use of LL addresses becomes quite limited ... "subnet local" usage reqs. [16:17:16] Carsten: Alrighty ... another round of review & comment / writing needed ... [16:17:21] ... next presentation ... [16:18:02] Zach Sheldby presenting http://tools.ietf.org/html/draft-shelby-6lowpan-nd-01 (another JIT update :) ) [16:19:00] Zach ... hopefully not a 50m job ... combination of 5 drafts, latest draft posted yesterday (link above) ... [16:20:14] slide 38 [16:21:54] Slide 38 ... defining the main goals of ND in the context of 6LoWPAN ... chartered items ... notes that this draft, and HC, are 15.4 agnostic (no assumptions of specific link layer) ... DAD/NS sans MCast, and in fact try to avoid NS/NA altogether ... goaol of handing out 16bit addrs in "cheap" fashion ... LoWPAN and Extended LoWPAN ...covers both mesh-under and route-over [16:22:44] Slide 39 ... Route-Over ... (re)define Link Local and introduce Subnet-local ... Link-Local is transmission radius [16:23:22] Slide 40 - Mesh Under ... subnet-local and link-local should overlap ("if you are lucky") [16:24:41] Slide 41 ... [16:25:46] Slide 42 ... Extended LoWPAN ... link-local between host and "first" router ... but the Subnet Local Scope covers the entire LoWPAN, incl backbone link ... ND-proxy, etc. [16:26:13] lion leaves the room: Computer went to sleep [16:27:23] Slide 43 - Start with 4861 (kinda important) ... use RAs (+ extra bit) ... bootstrapping, sans 15.4 specific mechanisms ... NEW: Router Registration/Confirmation ("whiteboard") ... Extended LoWPANs [16:27:33] lion joins the room [16:28:26] Slide 44 - Whiteboard means ... similar to MIPv6 ... the Edge Router can ("may"?) maintain a "soft" binding list, and may be shuffled between ERs. [16:29:46] Slide 45 - Whiteboard basic features ... DAD (and NS, when needed) for entired LoWPAN performed by ER ... nodes register, RAs send info [16:30:31] ____: whiteboard useful for DAD ... A: ... yes, and for forwarding ... [16:32:31] Slide 46 - Whiteboard Optional features ... Extended LoWPAN (subnet local scope covering the entire space; ND Proxy (incl bug fix) ...) ... enabling LoWPAN to non-LoWPan communication, with a mobile LoWPAN host w/o requiring MIPv6. + addr configuration [16:33:02] Right, but the mobility is within the subnet, say switch edge router [16:34:28] Slide 47 - messages ... Node to ER can be direct, or relayed ... can request (stateless) address ... ER can assign 16 bit dynamic address handouts, host then defends it. [16:36:33] Slide 48 ... talking lightly about RAs ... work like expected, except than be trickled (not in draft currently) ... new 4bit field for CIDs ... MultiHop info option still under refinement IIUC [16:38:26] Slide 49 - Current spec uses "E" flag ... may get dropped ... ... conversation about making this very generic to reduce MCast/NS/NA ... maybe an ICMP error? [16:39:18] Slide 50 - RA options ... [16:41:16] Slide 51 - RR/RC ...maybe drop X flag ... (explicit prox indication) ... an identified problem if EUI64 is not unique, need to have a way to deal with this ... [16:42:18] Slide 52 ... RR/RC options ... just one option now ... [16:42:43] Slide 53 - diff 00, 01 ... simplifications, clarifications [16:43:39] Slide 54 - 01 nits ... E flag, tickle, routing alg vs ND-Proxy, X flag, pri/sec bindings, Address Option index, editorial [16:44:20] Slide 55 - Getting to 02 ... est 2-3 weeks from today ... wants more feedback [16:45:32] Slide 56 - this, and HC, are needed by industry (quickly) ... encouraging (other) test implementations ... java simulator working (may not be sharable) ... so far, looking good ... SEND FEEDBACK. [16:45:47] Slide 57 - Accept as WG doc? [16:49:51] Carsten: I think this is big. Really big. Surprised at the integration into ND done to date. Desirable feature. ... one nit: Commerical incentive to create duplicates; pirated HW ... how to handle? IPv6 DAD works because the nodes can see each other, but by trying to avoid that (or it not being possible at all) ... How can the ER accomdate this? A: references slide 51, the TID is meant to be a unique identifier which at this point is assumed to be unique. Perhaps add a 32b nonce? ... and then how would we recover from this? [16:50:41] Pete St. Pierre leaves the room [16:50:52] Could someone (chairs?) help set up the issue tracking on IETF.org [16:51:04] Eric Levy Abegnoli @ cisco joins the room [16:51:22] Pete St. Pierre joins the room [16:51:43] ... converation continues ... nonce generated on boot ... (doesn't address the recovery from failure problem though) ...rebooted node then needs to "win against" its old address ... sticky. [16:53:09] ... conversation still going ... this is an L2 problem ... no DHCP ... "claim and defend", whiteboard to make it scale ... [16:54:57] David: 3 questions WRT sanity checking: 1) Eliminatin of MCast? But wasn't the original reason for LoWPAN MCast? 2) Need more discussion WRT whiteboarding ... lease based ... is this just DHCP in disguise? 3) Subnet-Local ... is there actual a Subnet Local Scope defined? [16:55:31] Pete St. Pierre leaves the room [16:56:05] Answers: There are big diffs between WB and DHCP ... the IID is the MAC (L2) ... therefore much lighter. ... [16:56:12] Normal case is the node autoconfs its address [16:56:27] though the router can give away an address [16:59:29] Ralph: Speaking WRT DHCP ... this is significantly simpler, it requires MCast ... DHCP has a formal relationship with the lease mechanism, this is not a lease but a soft-binding ... "claim and defend" is soft state only, and not centralized (and state is primarily stored in the node, not the ER). Zach: we are only really doing ND, don't need entire DHCP impl. ... we don't define how the addresses are formed ... could even be provided to ER by DHCP, but we don't want LoWPAN nodes to require DHCP ... [17:00:13] _____: Interesting and relevant to Autoconf as well, someone should go there (conflists with ROLL mtg) [17:01:06] Mark: Great job of pulling together all of this work, these are the kinds of hard problems we should be working on. A: We benefit from having (the appearance of) a clean slate ... [17:04:39] _____: Are we eliminating MCast? Initial bootstrapping will still use it. A: MeshUnder has a real problem here. And Link Local Mcast is still useful ... we are just trying to reduce this. ... we are trying to get these different topologies to work _____: What about these new subnet local addresses? ... Address could be ULA, or would it be useful to define this special prefix? A: Envision your regular prefix (regular global scope) as the subnet local address ... [17:04:59] lion leaves the room: Computer went to sleep [17:05:17] ... remaining problem for AdHoc LoWPAN for multihop routing ... [17:05:29] lion joins the room [17:07:20] David: Just don't fool ourselves that we use the word subnet ... ethernet backbone ... sounds a lot like Site Local scope, doesn't it? ... afraid a lot of the same DHCP complexities will come into the picture as this scale/scope grows [17:07:43] disagree [17:07:57] Carsten : It was deprecated because defining site is hard, not because there was no use. [17:08:01] When the backbone is the internet then we are in backhaul mode [17:08:34] when the backbone is a link then we are really in backbone mode and then we use ND proxy, not routing [17:08:51] Pascal: Just FYI - Carsten is at mic, so not reading your comments just yet ... [17:11:43] ... conversation ... network design/deployment concerns ... multi-link subnet (TTL implications - potential benefit there, actually) ... [17:11:54] ... so, accept as WG doc? [17:14:30] Carsten: Any competing docs? No ... Are we chartered? Yes ... Mark: All of the contributing docs reflected here, is this is the way forward? ... call for consensus ... noone opposed, consensus in favor. [17:14:32] Pete St. Pierre joins the room [17:15:00] ... Carsten presenting "Whither 6LoWPAN" ... [17:17:20] Slide 59 - things nobody appears to have noticed ... HC - is 64 good, does it get decremented by >1 routinely? UDP - MIC is not E2E ND - goes beyond LoWPAN, wider audience ... (requires wider review?) MCast - still here, just less often [17:17:58] ... back to milestones ... (Slide 7) [17:18:59] ... specifically the red items - Sec Analysis and Architecture ... [17:19:08] Slide 61 - Arch ... [17:19:39] ... is everything accounted for in other docs, or do we need an arch doc? [17:21:34] David: DOn't see the need to do it as a catch all ... but willing to take it up if needed. ... summarizes that draft, serves as a starting point and to tie all of the other docs together. Previously their wasn't consensus on the view of the IP-down part of the picture. ... Votes for reviving it, to nail down some principles. [17:22:44] Zach: David's draft was the basis for a lot of the following / current work and would like to have it back. At the very least, useful as a newcomer's first look ... [17:23:21] Mark: It also serves as a great refresher ... a good arch doc is very valuable. If what we have is good, polish it and get it published. [17:25:05] Carsten: David volunteerfed to author, Zach volunteered to review ... others? Geoff: It is useful, but sorry others have not volunteered ... Mark has tagged someone else (back of room) ... OK, looks like we are getting enough - we just need to be sure there are interested aprties. [17:25:48] Carsten: So ... revive Arch, rev +=1 as an individual submission and then review as potential WG doc afterwards ... [17:26:47] Slide 62 - On to Security ... Carsten: apparent lack of interest from industry ... so, what to do about draft? [17:27:27] Geoff: Has anybody read the draft? [17:28:15] Daniel : A revision is under way ... [17:29:04] Geoff: Anyone out htere willing to read & review this draft? ... very limited support (2) ... Note that if the vendors don't care, and we largely don't care ... ?? [17:30:21] Mark: Encourages that someone talk to the Secuirty ADs WRT realm-specific security ... THIS might be a corner case for them to consider / note as well. And get direction from that. [17:30:26] @TJ - thanks for covering today's play-by-play. My jabber client has had a horrible time staying connected today. [17:30:45] Pete: No worries ... it helps me remember better :) [17:30:59] Slide 63 - Anything else? [17:30:59] Yes, rework 4944 [17:31:14] use it as a binder fro the other drafts [17:37:46] JP: InterOp testing ... ? Geoff: I am for it. Do you mean - Should the WG actively do that? Zach: ~"My bad." We were mostly waiting on IPSO ... maybe time for us to take lead there ... maybe we should recommend to IPSO what/how to test ... ? JP: ... Mark: Forums need reasons to exist ... like IPSO writing up their own test plan in conjunction with all other smart obj SDOs ... vote to let IPSO do it, but with our input / clarifications. Geoff: IPSO does need our input on what 6LoWPAN interop means. Mark: ~"Why don't a few of you meander over to IPSO and start writing" Carsten: InterOp guideline is in our charter. Zach: HC and ND taking all cycles, soliciting volunteers ... failing that, just point them to our RFCs. _____: Already some crosspolination between IPSO and here ... we need to do it just one time ... Carsten: ... but where? ... Proposes taking it offline? Mark: InterOp inour charter because IPSO didn't exist when charter drafted. [17:37:52] Pete St. Pierre leaves the room [17:37:52] --fin [17:38:01] Pascal Thubert leaves the room [17:38:12] pee leaves the room [17:38:13] yuichi leaves the room [17:38:56] Eric Levy Abegnoli @ cisco leaves the room [17:43:26] lion leaves the room: Computer went to sleep [17:48:53] cabo leaves the room [17:50:33] ShoichiSakane leaves the room [17:52:35] dmw.winter leaves the room [17:52:38] TJ leaves the room [19:03:24] cabo joins the room [21:12:29] cabo leaves the room [21:29:05] cabo joins the room [21:35:00] cabo leaves the room