This is the ROLL 2015-02-10 Virtual Interim meeting notes. (PLEASE SET YOUR NAME IN THE UPPER RIGHT CORNER, WHERE THERE IS A PERSON ICON) {always good to have an anonymous observer: please make you don't type anything here[]} Slides are at: http://www.sandelman.ca/SSW/ietf/roll/ or: http://www.ietf.org/proceedings/interim/2015/02/10/roll/proceedings.html JITSI URL is: https://jitsi.tools.ietf.org/Roll20150210VirtualInterim I am also in the ROLL jabber conference. == Time in EDT == Presenter: Ralph Droms, Thank you very much Ralph! Present: Michael Richardson Xavier Vilajosana Robles Ines Cenk Gündoğan Robert Cragie Pascal Thubert Gabriel Montenegro Anon> Simon Yusuke Doi (etherpad only) Ralph Droms Thomas Watteyne Okay, we have started at 10:15, with Ralph leading. 1. Agenda bashing 2. Goals and desired outcomes for this meeting 3. Cover origin of problem: how did we get here a. 6tisch requirements for minimal b. 6man review of flow label c. 6lo review of NHC d. publication of dispatch header solution 4. Architectural deep dive of proposals on the table Goals Michael: Note well, Ralph: Agenda,develop a strategy to go forward what we think that it is better. which working group should handle this. Comments on agenda? Slide 5: Goal - what process do we want to follow? Outcome: last call on 6tisch tsch, which WG, how much do we try to compress, effort to get the spec published, how quick we can do that Slide 8: firs 3 efforts, flow label, NHC for RPI only, and NHC+IPinIP+RH using a dispatch discussion about choosing a mechanism for the IETF 93 Interop 6tisch. ETSI Plugtest: Should we encourage implementations to try more than one proposal? Slide 9: Discussion with Brian Haberman Slide 10 Problem statement RPL add 3 artifacts Pascal: discussion whether put the information in the specs, it should be there. Gabriel: had considered deprecating RPI? Pascal: answering -- - RPI could be replaced with Flow-Label, RPI and RH3 are not mutually exclusive, but RPI is critical for storing mode, while RH3 is critical for non-storing mode. One can sometimes omit one or the other, but in general you may need one or both. Slide 11: RPL needs RPI, that's a mandatory component of the design. discussion about overhead.... headers can be modified en-route. Overhead can be significant, 8 bytes for the RPI. Addition and deletion requires IP in IP encaps. Because IPv6 rules that headers cannot be added or deleted on the way. SLide 12: IP-in-IP encapsulation Ralph: uncompressed packet, packet come from the root, from inside-outside you should use IP-in-Ip [Dispatch draft] Ralph: discussion when IP-in-IP is necessary mcr asks if the originating node in the LLN can insert the RH3, such that the root doesn't need to add it, but Pascal points out that we wouldn't know how big an RH3 to add? Slide 13: problem with RH3 Ralph: Rules should be written down, seems not to be included. Consensus about minimu conclusion, about RH3, we need to add it Pusshing this off mcr: what is the roll packet structure up/down when 6lowpan is not available pascal: we have to find one or two cases for that Thomas: specify cases is important for implementations. Xavi: agree with more details when use IP-in-IP Ralph: Rules are not completed, need to reflect what it is relevant in an architechtural description. mcr: it is necessary have a distintion between LLN and DODAG, help to clarify when it is inside or outside, different header requirements. Pascal: to define how we compress. {mcr: comment for ETSI plugfest. We should do an interop test with 6lowpan turned off...} {mcr: do a set of slides explaining all of the combinations of add/remove, storing/non-storing and talk about this at 6man}miXnimu Ralph: Partial compression IP-in-IP encapsulation need define inside An attempt to show how you use RPI, RH3 and IP-in-IP for traffic within a LLN 1. [RH] -R-> [RR] -R-> [RR] -R-> [R] -3-> [RR] -3-> [RR] -3-> [RH] 2. [RH] IR-> [RR] IR-> [RR] IR-> [R] I3-> [RR] I3-> [RR] ---> [ H] 3. [ H] ---> [RR] IR-> [RR] IR-> [R] I3-> [RR] I3-> [RR] ---> [RH] 4. [ H] ---> [RR] IR-> [RR] IR-> [R] I3-> [RR] I3-> [RR] ---> [ H] I - IP-in-IP R - RPI option 3 - RH3 header [RH] - RPL-aware Host [ H] - Host not RPL-aware [RR] - RPL Router [R] - DODAG Root 1. Destination is in LLN and all hosts are RPL-aware so no need for IP-in-IP 2. Destination is in LLN but it is not known is all hosts are RPL aware. IP-in-IP used as unknown. 3. Destination is in LLN. First router adds IP-in-IP. Final router always removes encapsulation before forwarding to destination 4. Same as 3 Note the assumption above is that the source-routed packets from the Root do not contain RPI option. Slide 14: History Architechture discussion with 6man chairs, flow label not good solution, not compress RH3, not compress IP--in-IP encapsulation Slide 15: Proposal on the table Ralph: NHC not compress RH3, not got consensus. Dispatch, cover all the compressions, RIP, RH3, IP-in-IP Pascal described the situation mentioned in the MLs SLIDE 18: Current base solution by mcr Mcr explain the structure, is the order correct? Thomas and Ralph agrees that this is one of the possile Frames Ralph: we need to have IP-in-Ip encapsulation Discussion about 6553, 6554, 6282, need more detail to be written to understand the architechture SLide 19: FLow label approach, skip Xavi: RFC 6282, problem with extension header follow by hbh and udp header, u can not compress it, the extension header has a next header field, after htis field use a nhc, does it use rpi header? Pascal: it is out of scope of the meeting for today, we can discuss in the ML. we dont have time unfortunately for that. Mcr.: from 6282 interpreted compress extension header, nhc header can be used for it. next header is compressed. it is unclear why you can do it, but you can do it. Slide 20: NHC Solution Mcr: rfc no so clear, hard to do the diagram, nhc only will compress RPI SLide 21: Dispatch approach Mcr: Diagram showing all the compressed features other approach? whichh would be best solution? we will have more header to compress, we have to be clear that we are not duplicating the mesh header, diagram based on the draft, it is ok. Robert: use 1011xxxx for mesh under... In summary, the "half" solution is to not use dispatch code 1011xxxx. This is the dispatch code for a mesh header using 16-bit V and F addresses, which is the most likely used case (and I am aware is currently being used by an SDO in a draft specification, irrespective of who else may be using it). The rationale is that it is unlikely that you would mix 16 and 64 bit addresses in the mesh header (VF bits 01 and 10) and using 64 bits for both is costly (VF bits 00). The impact on draft-thubert-6lo-routing-dispatch would be to make the maximum length in the length field in the elective format half what it currently is. So the dispatch codes would look like: Critical - as is: 100xxxxx Elective - max. length is half what it currently is: 1010xxxx RFC4944 dispatch code retained: 1011xxxx Skip slides 22 to 31, directly go to slide 32 Slide 32: Why not NHC ++ Pascal: Code point starvation, code base, separate routing why RPL? if in the future there is another routing protocol Legacy notes, request to make it general , 6775-6lowpanND. rework to include bit about whether or knows 6LoRH. how we compress RPL artifact? Ralph gives a summary of the discussion until now, work to do: when use the compression, and consensus that the compression is necessary combine 6282 and 4944 and do a new work, to define Iot in TCP headers? discussion about mesh header type, what should be defined NHC++ draft To be reviewed by SDOs and WG for an opinion, we need comments, since we need consensus on this topic Need a document that mention what options are on the table, so the document can answer the questions whay and when we need this option Ralph: Three questions: 1- Where we need to have the discussion? 2- Which WGs goes to? 3- Which SDOs? make sure that we have a document with the solution to get the rough consensus, Need Int area AD are necessary to help to decide if it should be managed at 6lo. ROLL objected that it is not in the charter, this topic is wider, cover several WGs,. [ALvaro had connection problems to connect]. Pascal: Decision, do a document with the description of general implication. A document is needed telling about the use of mesh header whean it is good. we should work with Brian TODO: make list of questions for Liaison... interaction with ADs needed. Ted (6tisch). Where should this work take place? as the compression takes place, it should take 6lo, if the AD decide it is need for ROLL, it is ok. Ralph: since ROLL Is closing, it would be good to handle this in 6lo Gabriel: there are two components to the proposed work: general 6lo implications either in the NHC+ case or even more so in the dispatch case. so either way 6lo will be involved. given that the ROLL WG will be shutting down, it might be practical for 6lo to also do the roll-specific part of the work (the compression schemes). Xavi: for minimal, it is there acctually, not compressing the extension header it is fine, should it be NHC solution? 6554 , USING hbh Header. For Interop (Slide 39) would be used the current RFCs: 6282, 6553 and 6554, uncompressed version of rh3 RobertCragie: In ZigBee IP, we used RFC2473 for guidance wrt. IP-in-IP usage Action items: mcr: Write a document that get NHC++ with a clear description, document how/when the headers are used and, present summary at 6lo. TODO: make list of questions for Liaison... interaction with ADs needed. Ted (6tisch). Ask to ADs which would be the correct WG to handle this