From nobody Thu Apr 5 02:15:50 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60D7126DED for ; Thu, 5 Apr 2018 02:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLjm9LSKh6p2 for ; Thu, 5 Apr 2018 02:15:46 -0700 (PDT) Received: from lb2-smtp-cloud7.xs4all.net (lb2-smtp-cloud7.xs4all.net [194.109.24.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E510126579 for ; Thu, 5 Apr 2018 02:15:46 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud7.xs4all.net with ESMTPA id 40zffnQwr8U0740zffUVHl; Thu, 05 Apr 2018 11:15:43 +0200 Received: from 2001:983:a264:1:600b:380:6597:a9e6 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 05 Apr 2018 11:15:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Apr 2018 11:15:43 +0200 From: peter van der Stok To: Roll Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfKUXVZBi4fSBGbI6wAUnmeKj48a1GRZCOoaCtLnXz0r6pd/e86Bh6eEO1iQg9vgCOqsBvZeL5/6mHAjGw3q+xFReBigEhYWgv4oq8CRxJFW3WS1/0fQ1 Z6lenz2UAqa5wAiynZPNaen5NJsXt6H5Md0SafCz0cvMblMNRbQmKT4Hkenkb2hSBqVuM04i8t5K37t92hsfNHLwcYWRX13MUQA= Archived-At: Subject: [Roll] ietf 101 minutes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 09:15:49 -0000 Hi ROLL the meeting minutes of ietf101 in London are uploaded to https://datatracker.ietf.org/doc/minutes-101-roll/ Many thanks to Dominique and Georgios for the minute taking. Have a look and correct factual mistakes. many thanks, peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Thu Apr 5 07:58:09 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE8612D96A for ; Thu, 5 Apr 2018 07:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8442iga-eph for ; Thu, 5 Apr 2018 07:58:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D703E12D961 for ; Thu, 5 Apr 2018 07:58:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4DF1720090 for ; Thu, 5 Apr 2018 11:07:54 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32D0E80BBF for ; Thu, 5 Apr 2018 10:58:02 -0400 (EDT) From: Michael Richardson To: Roll In-Reply-To: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> References: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] ietf 101 minutes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 14:58:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://datatracker.ietf.org/meeting/101/materials/minutes-101-roll-00.txt ROLL meeting Thursday 21 March; 9h30 - 12h00 Peter and Ines: Introduction (10 minutes) . Papadopoulos: object function (15 Minutes) draft: draft-ji-roll-traffic-aware-objective-function-00 Papadopoulos: RPL DAG Metric Container (15 minutes) draft: draft-koutsiamanis-roll-nsa-extension-01 Rahul:=C2=A0discussion=C2=A0of=C2=A0open=C2=A0problems=C2=A0 (30 mi= nutes) draft-rahul-roll-rpl-observations-00 Carsten (and Pascal) use of BIER in RPL uni- and multicast (45 minutes) draft-ietf-roll-ccast-01 draft-thubert-roll-bier-01 Michael (and xxxx): Parent=C2=A0selection=C2=A0before=C2=A0or=C2=A0after=C2= =A0enrollment (30 minutes) draft-richardson-6tisch-roll-enrollment-priority-00 5 MINUTES open MIC to discuss continuation Note takers =2D Dominique Barthel, Georgios Papadopoulos =2D more welcome! Meeting notes [9:30] Meeting starts [9:30] Introduction (chairs) =C2=A0=C2=A0=C2=A0 * Note Well, note takers, blue sheets, Note Well =C2=A0=C2=A0=C2=A0 * updated the milestone list to more realistic target da= tes =C2=A0=C2=A0=C2=A0 * Active internet drafts =C2=A0=C2=A0=C2=A0 * notice IPR on two drafts, mail was sent out. Please re= act =C2=A0=C2=A0=C2=A0 * Peter: this time, long ROLL meeting. Many topics to di= scuss. Want to get some feedback on the length of this meeting =C2=A0=C2=A0=C2=A0=C2=A0 [9:36] draft-ji-roll-traffic-aware-objective-function-00 =C2=A0=C2=A0=C2=A0 Aris: is presenting his draft on Load Balancing =C2=A0=C2=A0=C2=A0 * new routing metric container proposed. =C2=A0=C2=A0=C2=A0 * simulation results =C2=A0=C2=A0=C2=A0 * the proposal is developed over Contiki OS (and Cooja s= imulator) =C2=A0=C2=A0=C2=A0 * number of DIOs sent as a measure of network stability:= this proposal does a bit better than state of the art=C2=A0(i.e., MRHOF, C= hild Count draft) =C2=A0=C2=A0=C2=A0 * open questions: packets or bytes? time units? assumpti= on of homogeneous forwarding cpapacity of nodes, should we send capacity as= well in DIO? =C2=A0=C2=A0=C2=A0 * how to relate energy consumption to packets/bytes sent? =C2=A0=C2=A0=C2=A0 *=C2=A0 =C2=A0=C2=A0=C2=A0 * Shall this value be integrated with EB/IE,=C2=A0 =C2=A0=C2=A0=C2=A0 * Giorgios: this is layer 3 info, should not get into EB =C2=A0=C2=A0=C2=A0 * Rahul: interesting work, done something similar =C2=A0=C2=A0=C2=A0 * Aris: let compare notes =C2=A0=C2=A0=C2=A0 * MCR: your diagram on slide 12, how do you ensure node = 7 attaches to 4 in order to allow 5 to accommodate 8?=C2=A0 =C2=A0=C2=A0=C2=A0 *=C2=A0Michael: there should be more experiments with mo= re children per parent, to see the impact of overloaded children per device =C2=A0=C2=A0=C2=A0 * Rahul: OF here only takes packet transmission rate int= o account. =C2=A0=C2=A0=C2=A0 * Aris: would use other metric as well, and this one as = a secondary metric. =C2=A0=C2=A0=C2=A0 * Charlie Perkins:=C2=A0 =C2=A0=C2=A0=C2=A0 * Charlie: study stability =C2=A0=C2=A0=C2=A0=C2=A0 [9:49] RPL DAG Metric Container (MC) Node State and Attribute (NSA) object = type, extension (Aris) =C2=A0=C2=A0=C2=A0 * New TLV proposed in NSA object, for packet replication= and elimination =C2=A0=C2=A0=C2=A0 * already presented at Singapore =C2=A0=C2=A0=C2=A0 * aim is determinism for reliability =C2=A0=C2=A0=C2=A0 * The employed mechanism is the so-called Packet Replica= tion and Elimination (PRE) =C2=A0=C2=A0 * key point is to select the alternate parent to send replica = to =C2=A0=C2=A0 * idea is to pick alternate parent that has common ancestor wi= th best parent. =C2=A0=C2=A0 * new TLV contains IPv6 addresses so that ancestors can be lea= rnt =C2=A0=C2=A0 * wireshark dissector was written =C2=A0=C2=A0 * drawback is size of IPv6 addresses that are sent. Compressed= out some of it. =C2=A0=C2=A0 * The idea is to keep the default parent and alternative paren= t so that to have the parents as close as possible to allow overhearing =C2=A0=C2=A0 * MCR: to compress IPv6 addresses, look at 6LoRH header, code = available =C2=A0=C2=A0 * Carsten: your draft has NSA in the title ;-) =C2=A0=C2=A0 * Peter: how does your proposal co-exist with other parent sel= ection draft? =C2=A0=C2=A0 * Aris: this is just a Constraint, not a metric. Can work with= OFs =C2=A0=C2=A0 * Pascal: the OF at IETF are simple, but more metrics exposed.= OF should be piece of logic. Your OF would be one with high level of intel= ligence. =C2=A0=C2=A0 * Peter: would be nice if this draft reflects how it interacts= with OFs =C2=A0=C2=A0 * Ines: this is of interest to ROLL, also needed by 6TiSCH =C2=A0=C2=A0 * Pascal: 6TiSCH does not *need* this, but a solution that ben= efits from 6TiSCH would also benefit from this. [10:01] draft-rahul-roll-rpl-observations-00 (Rahul) =C2=A0=C2=A0=C2=A0 * just observations of issues, no solution here =C2=A0=C2=A0=C2=A0 * Smart Meter networks, 60 hops, thousands of nodes =C2=A0=C2=A0=C2=A0 * issues mostly related to storing mode =C2=A0=C2=A0=C2=A0 * how to handle DTSN increment? want to also check how B= IER does =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * issue is DAO not getting throu= gh to the Border Router. Need for some redundancy. Re-transmit at every DIO= Trickle timer interval? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * has seen 10% of nodes not join= ed, for a long time. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * on parent switch, should node = increment DTSN * =C2=A0* (Dilemma 2) On parent switch, should node increase its DTSN? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * DAO-ACK: could be a solution i= f were handled properly. Current RPL spec has multiple interpretations poss= ible. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Contiki (new) implemented DAO-= ACK hop-by-hop. RioT implements end-to-end. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * RPL spec say aggregated target= is possible, but how to handle failure? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * problem will show on multiple = hops, not simple one-hop network =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * third proposal: downside is ag= gregated ACKs is not possible. =C2=A0=C2=A0=C2=A0 * handling node reboots: how is RPL state is maintained. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * not acceptable to write to fla= sh repeatedly (endurance issue). Incrementing DTSN 5 times a day is a probl= em, reportedly =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Carsten: what level of ?? are = you considering?=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Rahul: numbers in the draft, p= lease look at them and comment =C2=A0=C2=A0=C2=A0 * handling resource unavailability =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * neighbor cache full, routing t= able full: how do you signal it? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * impacted packet delivery rate = in this experiment. Some ideas for workaround, but would like to hear about= other's experience. =C2=A0=C2=A0=C2=A0 * MCR: excellent work, should adopt it. Lots of useful p= oints. Hadn't realized that the spec was ambiguous. =C2=A0=C2=A0=C2=A0 * MCR: one document with solution: e.g. DTSN increment i= s clearly a bug in the spec. =C2=A0=C2=A0=C2=A0 * MCR: another document to discuss issues we don't have = a solution for. =C2=A0=C2=A0=C2=A0 * Pascal: agrees to thank for the work, not so much for = the rest that michael said. =C2=A0=C2=A0=C2=A0 * Pascal: a bit of history: left a few things open when = writing spec because did not know what to decide. Don't rush to immediate s= olution. =C2=A0=C2=A0=C2=A0 * Pascal: RPL is not just for wireless. It's a routing p= rotocol. Also used on wires. =C2=A0=C2=A0=C2=A0 * Pascal: explains thinking about DAO-ACK. We need somet= hing to solve the end-to-end delivery. =C2=A0=C2=A0=C2=A0 * Pascal: version rebuilds everything, DTSN " repaints" = the DAODAG. Discrepancy is found when seeing traffic from unknown node.=C2= =A0 =C2=A0=C2=A0=C2=A0 * Pascal: wanted capability to rebuild the network intel= ligently by having a timer that is long enough so that ...., never specifie= d that. =C2=A0=C2=A0=C2=A0 * MCR: seems Pascal agrees. Just clarified a lot of thin= gs. 6550 did not capture that clearly. Low hanging fruit document should on= ly include non-controversial points. =C2=A0=C2=A0=C2=A0 * MCR: a bunch of knowledge just exposed, glad it's capt= ured on tape. Want to capture it in text quickly. =C2=A0=C2=A0=C2=A0 * Rahul: will go to the mailing list to get consensus on= what is non-controversial =C2=A0=C2=A0=C2=A0 * Ines: a document for the problem statement and links t= o solutions =C2=A0=C2=A0=C2=A0 * Pascal: problem statement does not need to be published =C2=A0=C2=A0=C2=A0 * Peter: draft could expire. =C2=A0=C2=A0=C2=A0 * Rahul: understand could maintain this draft as long as= needed, and develop solutions in other documents? =C2=A0=C2=A0=C2=A0 * Carsten: in the past in RoHC WG, have kept a standing = doc for 5 years. [10:31] draft-ietf-roll-ccast-01 (Carsten) =C2=A0=C2=A0=C2=A0 * this is more than 5 years old. =C2=A0=C2=A0=C2=A0 * thought it would be good to have multicast for non-sto= ring mode. =C2=A0=C2=A0=C2=A0 * result of a " constrained-cast"=C2=A0 reseach project. =C2=A0=C2=A0=C2=A0 * in 2014, BIER appeared, revived interest. =C2=A0=C2=A0=C2=A0 * Carsten shows tutorial slide. Efficient representation= of lists of data. Bloom filters, dating back 1970's. =C2=A0=C2=A0=C2=A0 * False positives create spurious transmissions, energy = consumption. How bad is it? In dense network, gets worse. Still, can leave = with some of it =C2=A0=C2=A0=C2=A0 * False positives depend on number of bits allocating. T= wo many bits is also a problem. =C2=A0=C2=A0=C2=A0 * Matt=C2=A0Gillmore (Itron):=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 [10:40] draft-thubert-roll-bier-01 (Pascal, Toerless Eckert) =C2=A0=C2=A0=C2=A0 * has backup slides to explain how BIER works with RPL, = look at them at the back of the presentation or ask me to present them =C2=A0=C2=A0=C2=A0 * can be used in storing or non-storing, unicast or mult= icast =C2=A0=C2=A0=C2=A0 * Carsten: *set* vs. *sequence* =C2=A0=C2=A0=C2=A0 * Pascal: set out to write a doc showing how all 4 cases= can be done. =C2=A0=C2=A0=C2=A0 * with bitmap, amount of storage is related to number of= children, which can be controlled. Could revive storing-mode. =C2=A0=C2=A0=C2=A0 * BIER-TE specifies bits for each hop to follow. False p= ositive create forwarding to wrong path =C2=A0=C2=A0=C2=A0 * Toerless:=C2=A0don't we want rough characterization (o= verhead, resources) before writing the drafts? =C2=A0=C2=A0=C2=A0 * Pascal: Bit-by-bit fits the BIER architecture. Bloom f= ilter needs some adaptations. =C2=A0=C2=A0=C2=A0 * Carsten: comparing different metrics: good way to comp= ress bit fields. Number hosts (storing mode) of forwarding nodes (non-stori= ng mode). =C2=A0=C2=A0=C2=A0 * Pascal: 200 hosts, how many bits do I need? =C2=A0=C2=A0=C2=A0 * Toerless:=C2=A0 =C2=A0=C2=A0=C2=A0 * Carsten: bit assignment can be managed with RPL, with = ND. =C2=A0=C2=A0=C2=A0 * Carsten: could look at more ways to compress bitmaps. = Could get efficiency close to that of Bloom filters. =C2=A0=C2=A0=C2=A0 * Carsten: I' m interested in non-storing mode =C2=A0=C2=A0=C2=A0 * Pascal: could use=C2=A0 =C2=A0=C2=A0=C2=A0 * Carsten: non-storing case is slightly simpler, because= the actual source is always the root.=C2=A0 =C2=A0=C2=A0=C2=A0 * Pascal: with Bloom, creates a problem. By contrast, bi= t by bit allows to send multicast from inside the network. This is a differ= entiating point =C2=A0=C2=A0=C2=A0 * Pascal: work to be done at BIER: allocation of bit to = address,=C2=A0 =C2=A0=C2=A0=C2=A0 * still work to be done to compress RPL control plane me= ssages (DIO, DAO, ...) =C2=A0=C2=A0=C2=A0 * Toerless: what 's the packet format? can we replace IP= v6 header with BIER header? =C2=A0=C2=A0=C2=A0 * Pascal: compressed form, but packet complies with the = IPv6 architecture. Can always reconstruct the full IPv6 packet using the im= plicits. =C2=A0=C2=A0=C2=A0 * Pascal goes through RPL tutorial slide. Bit allocation= . Aggregating bits in DAO operation. =C2=A0=C2=A0=C2=A0 * Giorgios: what do you do if too many nodes? =C2=A0=C2=A0=C2=A0 * Pascal: Bier can do groups. =C2=A0=C2=A0=C2=A0 * Pascal explains how to forward messages based on bitma= ps. =C2=A0=C2=A0=C2=A0 * can be made reliable with ACK, which are OR'ed togethe= r as they go back up. =C2=A0=C2=A0=C2=A0 * Peter: is there interest in the working group for this= work? Humm now: humms heard. =C2=A0=C2=A0=C2=A0 * Peter: anybody opposed? Speak up now. =C2=A0=C2=A0=C2=A0 * Carsten: IPR? =C2=A0=C2=A0=C2=A0 * Peter: propose to start design team. =C2=A0=C2=A0=C2=A0 * Carsten: send lawyers =C2=A0=C2=A0=C2=A0 * Toerless: isn't it always the case? Can create a desig= n team and see later if proposed options are covered with IPR. =C2=A0=C2=A0=C2=A0 * Peter: suggest Carsten, Pascal, Toerless, Olaf, Greg, = Ijsbrand (Cisco), Giorgios, Emmanuel. =C2=A0=C2=A0=C2=A0 * Peter: Toerless to coordinate. =C2=A0=C2=A0=C2=A0 * Peter: DT to create doc with alternatives, IPR info. =C2=A0=C2=A0=C2=A0=C2=A0 [11:16] draft-richardson-6tisch-roll-enrollment-priority-00 (Michael) =C2=A0=C2=A0=C2=A0 * set of requirements coming from 6TiSCH to do in ROLL. =C2=A0=C2=A0=C2=A0 * not specific to 6TiSCH, though. =C2=A0=C2=A0=C2=A0 * Problem is network selection. Given a node that can he= ar many routers belonging to several networks, which one to select? =C2=A0=C2=A0=C2=A0 * Would like to not have to try all routers, but rather = know which network they belonging too without revealing too much. =C2=A0=C2=A0=C2=A0 * We need to do DODAG selection, inside a network. =C2=A0=C2=A0=C2=A0 * if different PANIDs, probably different keys. =C2=A0=C2=A0=C2=A0 * Carsten: if secret handshake, none of the two parties = disclose anything to a third party.=C2=A0 =C2=A0=C2=A0=C2=A0 * Michael: not quite the same problem. =C2=A0=C2=A0=C2=A0 * our objective is node not going through all networks =C2=A0=C2=A0=C2=A0 * Carsten: done with SSID =C2=A0=C2=A0=C2=A0 * MCR: no SSID in 15.4. Has PANID, but too short and oth= er problems. =C2=A0=C2=A0=C2=A0 * in 6TiSCH, IE to contain =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * proxy priority: reflects resou= rces allocated for unknown nodes wanting to join =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * R says if it will answer unica= st Router Solicitation =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * network ID =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * DODAG priority: reflects willi= ngness to accept new traffic. =C2=A0=C2=A0=C2=A0 * Carsten: this reveal node is trying to join =C2=A0=C2=A0=C2=A0 * MCR: secret handshake in zero-touch way, would love it =C2=A0=C2=A0=C2=A0 * Thomas: emphasizes waste of energy of blind search. Th= is helps a lot. Real use case. =C2=A0=C2=A0=C2=A0 * Pascal: agrees with Thomas. Mostly interested in DODAG= priority. In the field, we see instability in structures that we build. Os= cillations. =C2=A0=C2=A0=C2=A0 * Pascal: load at the root is the load of thee network. = Work to do is to end up with balanced situation =C2=A0=C2=A0=C2=A0 * need new metric container. Will be transmitted unchang= ed as DIOs go down the network. =C2=A0=C2=A0=C2=A0 * new DIO configuration option. To convey the new networ= k ID. =C2=A0=C2=A0=C2=A0 * Pascal: your new metric does for the whole network wha= t an OF does for a node.=C2=A0 =C2=A0=C2=A0=C2=A0 * Pascal: number of node left, amount of bandwidth left.= Not so much percentages, because could translate to different absolute val= ues. =C2=A0=C2=A0=C2=A0 * MCR: in storing mode, as RPL is now, we don't know the= load of the nodes =C2=A0=C2=A0=C2=A0 * Peter: can you say again what this documennt is exactl= y about? =C2=A0=C2=A0=C2=A0 * MCR this is just the description of a DIO container. M= aybe suggest way of calculating this metric. =C2=A0=C2=A0=C2=A0 * Peter: parent selection in another document?=C2=A0 =C2=A0=C2=A0=C2=A0 * MCR: true. =C2=A0=C2=A0=C2=A0 * Peter: who's read? who's willing to review? who thinks= we should adopt? =C2=A0=C2=A0=C2=A0 * Ines: we'll go to the mailing list. =C2=A0=C2=A0=C2=A0=C2=A0 [11:43] Open mic =C2=A0=C2=A0=C2=A0 * Aris: finds all problems discussed very interesting. W= hat about replicability? how to share information that would allow to repro= duce situation in simulation =C2=A0=C2=A0=C2=A0 * Rahul: agree it's a big issue. Working on a framework = specifically for this. Whitefiled? framework. =C2=A0=C2=A0=C2=A0 * MCR: F-interop is also very cool. =C2=A0=C2=A0=C2=A0 * MCR: been the case in ROLL WG that issues were reporte= d but no detailed info was available to simulate/replicate issue. =C2=A0=C2=A0=C2=A0 * MCR: Cooja runs Contiki, does not allow to compare RIO= T and Contiki implementations. =C2=A0=C2=A0=C2=A0 * Thomas: there's a lot to verify. F-interop to verify i= nteroperability. For performance, 6TiSCH python simulator and interface. Al= lows to enter a scenario and get graphs. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Only part of the answer to your question, bu= t still something. =C2=A0=C2=A0=C2=A0 * Ines: introduces tomorrow's meeting. =C2=A0=C2=A0=C2=A0 * Peter welcome feedback on time of this meeting. Do you= prefer longer or shorter one?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 [11:51] meeting ends =3D=3D=3D=3D=3D Friday meeting Friday 23/3 9h30-11h30 Ines+Peter: Introduction (5 min) Charlie: Asymmetric AODV-P2P-RPL in LLNs (15 mins) draft-ietf-roll-aodv-rpl-02=C2=A0 Pascal:=C2=A0ND=C2=A0only=C2=A0device=C2=A0connects=C2=A0to=C2=A0RPL=C2=A0D= ODAG. (20 mins) draft-thubert-roll-unaware-leaves-01 Rahul: DCO performance report (15 mins) draft-ietf-roll-efficient-npdao Pascal: Objective function specification and selection for parent selection= , DAG selection =C2=A0(30 minutes) draft-thubert-roll-unaware-leaves-01 Pascal: Root initiated routing state in RPL =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(= 15 mins) draft-ietf-roll-dao-projection-02=C2=A0 Dominique: state of Dis-modifications (5 min) draft-ietf-roll-dis-modifications-00 xxxxx: RPL-load balancing (15 mins) draft-qasem-roll-rpl-load-balancing-02 15 MINUTES DISCUSSION: All: Discussion on new subjects Which topics and priority, Authors, Reviewers. [9:30] Meeting starts [9:31] Routing for RPL Leaves (Pascal) =C2=A0=C2=A0=C2=A0 * original idea was low cost nodes roaming through 6LRs. =C2=A0=C2=A0=C2=A0 * called a leaf, is RPL-unaware. Does not know RPL is be= ing used. Only uses 6LoWPAN ND =C2=A0=C2=A0=C2=A0 * had to change 6LoWPAN-ND because fabric has to know wh= at is the latest location, so that it can route to the leaf =C2=A0=C2=A0=C2=A0 * comparing timestamps does not work because tolerance o= n timers and mobility speed unknown =C2=A0=C2=A0=C2=A0 * now, source generates a sequence. Ordering becomes obv= ious =C2=A0=C2=A0=C2=A0 * also change source address validation. Address could b= e spoofed (stolen) and traffic diverted. =C2=A0=C2=A0=C2=A0 * association mechanism mimicking that of 802.11. Leaf p= ro-actively installs=C2=A0 state in the 6LR (equal to AP in 802.11) so that= the 6LR knows has to forward multicast =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 traffic for this leaf =C2=A0=C2=A0=C2=A0 * this supports RPL but also any other similar routing p= rotocol =C2=A0=C2=A0=C2=A0 * Pascal shows the address validation mechanism. ROVR is= token to prove ownership of address. Only proves address on first hop =C2=A0=C2=A0=C2=A0 * new spec: leaves set the R bit to 1 to instruct 6LR to= inject this address into routing =C2=A0=C2=A0=C2=A0 * Transaction ID is a sequence counter to be injected in= to the DAO Path Sequence Number. =C2=A0=C2=A0=C2=A0 * Rahul: Path Sequence is optional =C2=A0=C2=A0=C2=A0 * Pascal: believe it is mandatory. Otherwise, we have a = problem =C2=A0=C2=A0=C2=A0 * Rahul: will check. =C2=A0=C2=A0=C2=A0 * Registration lifetime: in ND, expressed in minutes. In= RPL, configuration that tells the time-unit. =C2=A0=C2=A0=C2=A0 * Rahul: Transit Info not mandatory =C2=A0=C2=A0=C2=A0 * Pascal: will check =C2=A0=C2=A0=C2=A0 * Rahul: none of the open source RPL implementation curr= ently use Path Sequence. =C2=A0=C2=A0=C2=A0 * Pascal: if the MUST is missing, this is a bug. We'll l= ook at it offline. =C2=A0=C2=A0=C2=A0 * Pascal: still lacking a reference open-source implemen= tation of RPL. Do not judge the quality of RPL by the quality of some imple= mentations out there. =C2=A0=C2=A0=C2=A0 * shows message exchange diagram. New spec mandates 6CIO= option from 6LBR down to the 6LRs. =C2=A0=C2=A0=C2=A0 * Peter (from the floor): what happens if we mix 6LR wit= h and without the new option? =C2=A0=C2=A0=C2=A0 * Pascal: the spec discusses this. It works. On security= side, weaker because smaller keys. Spec recommends a leaf attaches to a "n= ew" 6LR. An old 6LR on the way from the attachment 6LR and 5LBR is okay. =C2=A0=C2=A0=C2=A0 * signaling is in the 6775-update doc, how proxy operati= on is done is in the backbone doc. =C2=A0=C2=A0=C2=A0 * Got reviews from IESG, not quite closed yet but lookin= g good. =C2=A0=C2=A0=C2=A0 * shows diagram on=C2=A0address validation: protects the= legitimate owner against other nodes trying to steal that address. =C2=A0=C2=A0=C2=A0 * re-iterates that only first hop is protected, RPL is n= ot. =C2=A0=C2=A0=C2=A0 * we'll discuss on the mailing list on Rahul draft (DAO-= ACK). =C2=A0=C2=A0=C2=A0 * Pascal: if you're implementing RPL, understand that wh= en a 6LR accepts a DOA from a child, it takes responsibility for transmitti= ng ii up. =C2=A0=C2=A0=C2=A0 * is the RPL root the LBR? technically, could be separat= e. In Pascal's mind, should be the same =C2=A0=C2=A0=C2=A0 * big discussion that needs to be had: do we MUST that 6= LBR and RPL root are one? =C2=A0=C2=A0=C2=A0 * proposes to use RPL DAO to accomplish what DAR/DAC doe= s. =C2=A0=C2=A0=C2=A0 * remember that RPL will not do DAD, since ROVR doesn't = go to Root. =C2=A0=C2=A0=C2=A0 * summary: very simple node roams smoothly across meshed= 6LRs, many DODAGs. =C2=A0=C2=A0=C2=A0 * on terminology: RPL defines "leaf", a node that unders= tands RPL but does not route. This draft defines "unaware-leaf", a node tha= t doesn't even understand RPL. =C2=A0=C2=A0=C2=A0 * pre-requisite: 6775-update, IP-in-IP, RPI header =C2=A0=C2=A0=C2=A0 * if 6LBR was not RPL root: could make it work, no too s= ure. =C2=A0=C2=A0=C2=A0 * do we have a use case for it? =C2=A0=C2=A0=C2=A0 * Peter: who has read the draft? a few hands? =C2=A0=C2=A0=C2=A0 * Peter: is this 6Tisch-related? useful to 6TiSCH, but n= ot even routing-related. =C2=A0=C2=A0=C2=A0 * Pascal: simple work, but really important. Most of it = done at 6lo. =C2=A0=C2=A0=C2=A0 * Pascal: had this dream from the start, could not imple= ment it with RPL, now can. =C2=A0=C2=A0=C2=A0 * work not quite done yet, if you are interested, join i= n. [10:15] Asymmetric AODV-P2P-RPL in LLNs (Charlie) =C2=A0=C2=A0=C2=A0 * allows asymmetrical routes between nodes pairs. =C2=A0=C2=A0=C2=A0 * went into last call, got lots of comments =C2=A0=C2=A0=C2=A0 * most extensive comments: some features of P2P-RPL not = implemented in OADV-RPL. As a result, attempted to include these. =C2=A0=C2=A0=C2=A0 * discussion on use of DSTN for sequence number. =C2=A0=C2=A0=C2=A0 * Pascal: two sequence counters coming down from the roo= t. One when new DAODAG is built (version number), rebuilding a new DODAG in= cluding reparenting. =C2=A0=C2=A0=C2=A0 * DTSN is to refresh the state associated to current top= ology. =C2=A0=C2=A0=C2=A0 * what exactly is your destination sequence number? =C2=A0=C2=A0=C2=A0 * Charlie: not sure, will have it as a separate discussi= on. =C2=A0=C2=A0=C2=A0 * will suggest using OADV's feature to deal with uni-dir= ectional links. =C2=A0=C2=A0=C2=A0 * this draft was published quickly to meet the submissio= n deadline. Will get a revised version soon. =C2=A0=C2=A0=C2=A0 * Pascal: original P2P-RPL used DIO for RReq and DAO as = RReply. Needs a certain degree of bidirectionality. =C2=A0=C2=A0=C2=A0 * Pascal: Charlie, your work is the only one that uses D= IO both ways to discover the route. This is good: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 P2P-RPL uses DIO in one way and DAO the othe= r way, does not work as well in presence of asymmetrical links. =C2=A0=C2=A0=C2=A0 * Pascal/Dominique: discussion on the causes for asymmet= ry. =C2=A0=C2=A0=C2=A0 * this draft defines new RREQ/RREP option. Imported from= 6997 =C2=A0=C2=A0=C2=A0 * new target option. =C2=A0=C2=A0=C2=A0 * had discussion on pairing of InstanceIDs (one for each= direction). << missed part of it>>>> =C2=A0=C2=A0=C2=A0 * to be done =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * citing 6997 cannot be normativ= e, because it's experimental. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * InstanceID conflicts =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * import black-hole link detecti= on of OADV? =C2=A0=C2=A0=C2=A0 * Rahul: you said asymmetrical link detection is out of = scope. =C2=A0=C2=A0=C2=A0 * Charlie: could make it in scope =C2=A0=C2=A0=C2=A0 * Rahul: the probing of links for asymmetry should not b= e in scope =C2=A0=C2=A0=C2=A0 * Charlie: the metric should be there =C2=A0=C2=A0=C2=A0 * Pascal: doesn't seem we need to do anything. Building = another DAG, using DIO. If a link is asymmetrical, flooding will not happen= , that's it. =C2=A0=C2=A0=C2=A0 * Peter: would like this document to be completed. Have = this discussion on the mailing and get to a conclusion in the next few week= s. =C2=A0=C2=A0=C2=A0=C2=A0 [10:38] Route invalidation, experiment report (Rahul) =C2=A0=C2=A0=C2=A0 * remember NPDAO sent downstream =C2=A0=C2=A0=C2=A0 * DCO and NPDAO operating at same time in the network. =C2=A0=C2=A0=C2=A0 * report link sent on the mailing list a month and half = ago =C2=A0=C2=A0=C2=A0 * two topologies, 50 and 100 nodes. All nodes are starte= d at same time. =C2=A0=C2=A0=C2=A0 * much less stale entries with DCO than with NPDAO. =C2=A0=C2=A0=C2=A0 * control overhead better for DCO as well. =C2=A0=C2=A0=C2=A0 * analysis of what happens on parent switching (identica= l in Contiki and RIOT). Send NPDAO immediately, schedule a new DAO for late= r. Hence route downtime. =C2=A0=C2=A0=C2=A0 * Pascal: Contiki and RIOT implementations are not RPL. = Don't state the quality of RPL based on these implementations. =C2=A0=C2=A0=C2=A0 * Rahul: with DCO, .... =C2=A0=C2=A0=C2=A0 * Pascal: you may be sending two DAOs, one gets slowed d= own, your DCO gets earlier. Don't be too quick in sending the uplink =C2=A0=C2=A0=C2=A0 * Pascal: another point: traditional in LS to cleanup th= e bad state left over on mobility. From hearsay, proven to be complex. Shou= ld research on this. =C2=A0=C2=A0=C2=A0 * Pascal: bad history of doing this in other routing pro= tocols. =C2=A0=C2=A0=C2=A0 * Alvaro: in other protocols, do flush. Problem is flush= ing for somebody else that's no longer there. State expires. Connectivity f= ails. =C2=A0=C2=A0=C2=A0 * Alvaro: there has been proposals on proxying, nobody v= ery happy with this. =C2=A0=C2=A0=C2=A0 * Pascal: keep a note that we should experiment with thi= s before standard RFC. I feel this is safe, but needs a check =C2=A0=C2=A0=C2=A0 * Rahul: still kept the bit .... =C2=A0=C2=A0=C2=A0 * Rahul: next steps =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * text changes (Destination Clea= nup Object), but no semantic change for a long time. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * would like to WGLC this =C2=A0=C2=A0=C2=A0 * Peter: also wants this =C2=A0=C2=A0=C2=A0 * Peter: perf report in appendix? =C2=A0=C2=A0=C2=A0 * Peter: if you have publication elsewhere, you can also= refer to it. =C2=A0=C2=A0=C2=A0 * Pascal: Cisco and Huawei both have IPR on this. =C2=A0=C2=A0=C2=A0 * Rahul has invited Pascal to join the work on this. [10:56] Root initiated routing state in RPL (Pascal) =C2=A0=C2=A0=C2=A0=C2=A0 * two implementations under way. One by Huwaei, on= e=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 * invited Huawei (whom?) and Matt Gillmore to this= draft. =C2=A0=C2=A0=C2=A0=C2=A0 * not much progress recently =C2=A0=C2=A0=C2=A0=C2=A0 * Need to discuss size of MoP, 3 bits. AODV uses a= new MOP as well. We'll be short on bits pretty soon. =C2=A0=C2=A0=C2=A0=C2=A0 * Charlie: discussion also holds for AODV-RPL. Sho= uld it use new MOP or new message numbers? =C2=A0=C2=A0=C2=A0=C2=A0 * Pascal: 8 MOP values. 4 consumed in the base spe= c. 1 is experimental, can be claimed back. Leaving 5. =C2=A0=C2=A0=C2=A0=C2=A0 * Remaining questions =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * how is the topology know= n to the root? non-storing, DAOs tell the DODAG. storing, not much. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * how are node capabilitie= s know to the root? extend the DAO to include things such as memory size? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Rahul:=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Pascal: constrained node= s usually don't do storing mode. If you do storing mode, do it well. If nod= e reparents, need to be able to reconstruct state. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * mixed modes? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * loop avoidance =C2=A0=C2=A0=C2=A0 * Peter: could you reduce document to non-storing mode a= nd avoid all the storing-mode related problems? =C2=A0=C2=A0=C2=A0 * Pascal: answer is no. Initial motivation was to build = networks with long lines of nodes, want to compress this line with local st= oring mode. Send in non-storing mode only to the beginning of the line. =C2=A0=C2=A0=C2=A0 * Rahul: loop avoidance will be updated in this draft [11:08] Status of draft-ietf-roll-dis-modifications-00 =C2=A0=C2=A0=C2=A0 * interest for this work re-iterated on the mailing list. =C2=A0=C2=A0=C2=A0 * Dominique and Cenk will allocate resource to work on t= his by the summer =C2=A0=C2=A0=C2=A0 * Pascal willing to help =C2=A0=C2=A0=C2=A0 * discussion whether this draft should just provide the = flags and options or should also recommend the use of each mode and option = for different real-world situations =C2=A0=C2=A0=C2=A0 * Pascal: we've had these discussions in hallways on mul= tiple instances since Maastricht. =C2=A0=C2=A0=C2=A0 * not much resource available to that. =C2=A0=C2=A0=C2=A0 * Pascal: could target the experimental track and publis= h quickly =C2=A0=C2=A0=C2=A0 * Dominique: will revive this discussion on the mailing = list and move forward. [11:23] meeting closed =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrGOXkACgkQgItw+93Q 3WWeowf9EPYf5Qh6WaTg/eOKsG/wKcaD9EW6l6J4OPfmgn6Da8QOfiGSwIx8cwmr e6m2hPPnmggQIveEUMA+kJ80h1nkQU29ucBWZtkW3F2P+0KGnlSQf+YzjcdAb/7u F1XFLIXWa5th7VlSWhXgnuDO9ssBFsWCr9KooOrsHqug2SJWQSAYZ1xuTsy8raAs v9pTo3RyQwnbrqZsX8N+QFISKOv0vQQNxmtjnH9GBjcWa9GvdKpOEp3jH88D8j94 NPtqHGQWx43jkm45KCMWDgg65AYB/OIGQUM0lZzMhPcgJjcAb1pBnbIhhKvz+pwq PE07b7Ga98lAjXFIBnaJX5sgmSFLTw== =uWXy -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 5 09:14:27 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00FD12DA02 for ; Thu, 5 Apr 2018 09:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4OPScOFVepW for ; Thu, 5 Apr 2018 09:14:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4F7127876 for ; Thu, 5 Apr 2018 09:14:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BB47A20090 for ; Thu, 5 Apr 2018 12:24:16 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6FCA081A14 for ; Thu, 5 Apr 2018 12:14:24 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <31500.1522940282@obiwan.sandelman.ca> References: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> <31500.1522940282@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Roll] DTSN increment and DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 16:14:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > =C2=A0=C2=A0=C2=A0 * how to handle DTSN increment? want to also check= how BIER does .. > =C2=A0=C2=A0=C2=A0 * MCR: excellent work, should adopt it. Lots of us= eful > points. Hadn't realized that the spec was ambiguous. > =C2=A0=C2=A0=C2=A0 * MCR: one document with solution: e.g. DTSN incre= ment is clearly a > bug in the spec. > =C2=A0=C2=A0=C2=A0 * MCR: another document to discuss issues we don't= have a solution > for. My impression is that there is some clarification needed in 6550. I don't know if this should be done as errata or as an Updates, bacause I haven't internalized the scale of the issue. > =C2=A0=C2=A0=C2=A0 * Pascal: explains thinking about DAO-ACK. We need= something to > solve the end-to-end delivery. > =C2=A0=C2=A0=C2=A0 * MCR: seems Pascal agrees. Just clarified a lot o= f things. 6550 > did not capture that clearly. Low hanging fruit document should only > include non-controversial points. > =C2=A0=C2=A0=C2=A0 * MCR: a bunch of knowledge just exposed, glad it'= s captured on > tape. Want to capture it in text quickly. What I took home from the discussion is that DAO-ACK SHOULD be used on networks where this is no L2 confirmation. That it's not end-to-end (which is what I implemented!), and if we want end-to-end ACK, it would be a new extension. > =C2=A0=C2=A0=C2=A0 * Rahul: will go to the mailing list to get consen= sus on what is > non-controversial Just a reminder... Here a a few options that I was thinking about: 1) It's time to do rfc6550bis. This could be a non-trivial amount of work. It can be bounded in time, but it's hard to do. 2) We should write a document that Updates RFC6550. 2a) The *WG* creates a design team to create a low-hanging fruit document. It would start with a document (already adopted by the WG. The DHCP WG did this wrong in my opinion) that is essentially starts empty. The design team would scavenge content from Rahul's document and apply WG consensus to it being non-controversial. Lather.Rinse.Repeat. 2b) We adopt Rahul's document, or a version of, and then discover which parts are controversial, and remove them until we have a simple document. If left with empty set, STOP. Constroversial items go into new documents. 3) We adopt Rahul's document as a BCP and it contains non-normative language only. > =C2=A0=C2=A0=C2=A0 * Rahul: understand could maintain this draft as l= ong as needed, > and develop solutions in other documents? > =C2=A0=C2=A0=C2=A0 * Carsten: in the past in RoHC WG, have kept a sta= nding doc for 5 > years. That's reasonable for some things, but not for others. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlrGS2AACgkQgItw+93Q 3WW1JQf/Zx75oExhJW4PZ+wlZEb9bEKWKs8kehfbHBIuUV4c7daRz6qbpTEZyEsO HFCwnBx6LrsJtDQNSXb56bye+HAlK4oSX85SA14z9YxRrllC+9REdKegKY7gNMQY P1QvNQtfifd+GiQg7Xs0eJZYNT0EaFrOQCQ9MDVFlMRDOs3sMfKcxS0rdt1ZpO9l PBT3W2GUBJkOnZ06gI5fdpgkVCaStfvR3jVUA1wY1rw6hBX/07D0KWsELgKcGdHv AtNXqo10B1AJ/+M7ybOkHZp/ef9pamlfQsI06UL1fkQZdGQxf3UvgIp7U83+napk Nm8DpazDKxFzRLyrSQHQeP1UbUNxcQ== =z1xo -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 5 09:58:38 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9F12DA43 for ; Thu, 5 Apr 2018 09:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.265 X-Spam-Level: X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjqP7C_0J2Jw for ; Thu, 5 Apr 2018 09:58:32 -0700 (PDT) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857801271DF for ; Thu, 5 Apr 2018 09:58:32 -0700 (PDT) Received: by mail-pl0-x22e.google.com with SMTP id x4-v6so19973511pln.7 for ; Thu, 05 Apr 2018 09:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:message-id:date:references:to:cc:mime-version :content-transfer-encoding; bh=4zZzmGzmTT2tuHr29jQy+nNufoAwYne0KYpiaVemgb8=; b=imu4U+tgJ/nkj6wZQWIR6tFa1yp+n+Oy6BrWOOw88mPDPnlVQ4+xL7kRInXxEAV1Pt iXz/4/qhEGFc8C88sPpncRvTcZydNXbSiOz57lrDtTVIRgSq9CxpLWsPGu/SdiOcn9dd yW1tu2jxRFwRT3xrYKHczlfpts58KFO3mTY7UCFMXaQ3s8dFBv+xbUQ/irEHg0N45fM6 QD7D0LJd/ps91qqicbx4foIS9skM5EZUNbz+mxu9beEVRLXlVCzlyhzhwsFEcsNGH9rM 8IjmjKx4wpi8uKZLIwDbAAoRBo+tlUV0KcDc6dlIifPOkDxCdOkyawD1tpVXQL3G8xU5 8E1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:references:to:cc :mime-version:content-transfer-encoding; bh=4zZzmGzmTT2tuHr29jQy+nNufoAwYne0KYpiaVemgb8=; b=Le6gSIMnErIkz0ac34+sCp6jU6mTb8PrrsGMg2edZlxaXhsqnQgydXMzXiOpsBFeXv xuXe4Kj0jSQkUwHo2+CSF9R4/nR+IQBnBw8K5gcn2HVuyZigZ1bsnKsrPdKu8XjKKQgH 9jVj/GWg2WIu3TOBHf0GzhkfEtlc+/0hwlJ/zc7C6NpsXfjA75V5U4HzuuDo+xeX5LtP PMGqzd+1i46YnAyWgzu61CH/l6/89dpsaxpDg4WXQvqf/6wkl9TfZw2YZLd9qEGQzsU6 FbMZNqRbe9wZeHOOhlgXA/ANmfMURZFeWVtbKzGbCsVWiJ9IijLqLgFFzOsG+rFZ3jtB yLxA== X-Gm-Message-State: AElRT7FwPNd59aolTy+7S9gZDyOLZEnJRFBUuXN5OmT0vumyO9c/nyZY do62VXGhdaJHxkwuhVYfQRuhk319 X-Google-Smtp-Source: AIpwx4+ynve8W+5vY4ydgnuJJbZKxreA8dndVVTdjAD/loFNEFsoZfl1otCdfXByIdfWYsNP8SbUkA== X-Received: by 10.98.87.150 with SMTP id i22mr11418074pfj.119.1522947511868; Thu, 05 Apr 2018 09:58:31 -0700 (PDT) Received: from 192.168.10.58 ([103.65.41.168]) by smtp.gmail.com with ESMTPSA id u6sm13475600pgo.1.2018.04.05.09.58.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Apr 2018 09:58:31 -0700 (PDT) From: Rahul Jadhav Message-ID: <43688A96-53E3-41C6-9F34-54DB827F0CE8@gmail.com> Date: Fri, 6 Apr 2018 00:58:28 +0800 References: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> <31500.1522940282@obiwan.sandelman.ca> To: Routing Over Low power and Lossy networks Cc: Routing Over Low power and Lossy networks X-Mailer: NetEase iOS Mail 6.4.1.1188 [iPhone 7 iOS11.2.6] MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] DTSN increment and DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 16:58:36 -0000
=20 =20
Hi Michael, 

I agree to al= l of the things that you mentioned.  

There= are few more points that we had not added in the observations draft beca= use of lack of time for Ietf101. We wanted to add only after getting some= performance figures and more clarifications. Expect an update for the ob= servations draft in couple of weeks.

Thanks for = initiating the discussion.

Regards,
Ra= hul 

On 04/06/2018 00:14, Michael Richardson wrote:

Michael Richardson <mcr+ietf=40sandelman.ca> wrote:
   >     * how to handle DTSN incre= ment=3F want to also check how BIER does

...

   >     * MCR: excellent work, sho= uld adopt it. Lots of useful
   > points. Hadn't realized that the spec was amb= iguous.
   >     * MCR: one document with s= olution: e.g. DTSN increment is clearly a
   > bug in the spec.
   >     * MCR: another document to= discuss issues we don't have a solution
   > for.

My impression is that there is some clarification needed in 6550.
I don't know if this should be done as errata or as an Updates, bacau= se
I haven't internalized the scale of the issue.

   >     * Pascal: explains thinkin= g about DAO-ACK. We need something to
   > solve the end-to-end delivery.

   >     * MCR: seems Pascal agrees= . Just clarified a lot of things. 6550
   > did not capture that clearly. Low hanging fru= it document should only
   > include non-controversial points.
   >     * MCR: a bunch of knowledg= e just exposed, glad it's captured on
   > tape. Want to capture it in text quickly.

What I took home from the discussion is that DAO-ACK SHOULD be used o= n
networks where this is no L2 confirmation.  That it's not end-to= -end
(which is what I implemented=21), and if we want end-to-end ACK, it
would be a new extension.


   >     * Rahul: will go to the ma= iling list to get consensus on what is
   > non-controversial

Just a reminder...  Here a a few options that I was thinking abo= ut:

1) It's time to do rfc6550bis.  This could be a non-trivial amou= nt of work.
  It can be bounded in time, but it's hard to do.

2) We should write a document that Updates R=46C6550.
2a) The *WG* creates a design team to create a low-hanging fruit docu= ment.
   It would start with a document (already adopted by= the WG. The DHCP WG
   did this wrong in my opinion) that is essentially = starts empty.
   The design team would scavenge content from Rahul'= s document and
   apply WG consensus to it being non-controversial. =  Lather.Rinse.Repeat.

2b) We adopt Rahul's document, or a version of, and then discover whi= ch
   parts are controversial, and remove them until we = have a simple
   document.  If left with empty set, STOP.

   Constroversial items go into new documents.

3) We adopt Rahul's document as a BCP and it contains non-normative
  language only.

   >     * Rahul: understand could = maintain this draft as long as needed,
   > and develop solutions in other documents=3F
   >     * Carsten: in the past in = RoHC WG, have kept a standing doc for 5
   > years.

That's reasonable for some things, but not for others.


--
Michael Richardson <mcr+IET=46=40sandelman.ca>, Sandelman Softw= are Works
-=3D IPv6 IoT consulting =3D-



=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll=40ietf.org
https://www.ietf.org/mailman/listinfo/roll
=20
=20 =20
From nobody Mon Apr 9 00:39:56 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A0812D94C for ; Mon, 9 Apr 2018 00:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d27N67jzBIdk for ; Mon, 9 Apr 2018 00:39:53 -0700 (PDT) Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11ABA1273E2 for ; Mon, 9 Apr 2018 00:39:52 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:212]) by smtp-cloud8.xs4all.net with ESMTPA id 5RP4f38i24EsM5RP4fp2Bi; Mon, 09 Apr 2018 09:39:51 +0200 Received: from 2001:983:a264:1:c122:b170:5d1e:271e by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 09 Apr 2018 09:39:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Apr 2018 09:39:50 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Cc: Michael Richardson Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <14809.1522944864@obiwan.sandelman.ca> References: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> <31500.1522940282@obiwan.sandelman.ca> <14809.1522944864@obiwan.sandelman.ca> Message-ID: <7c3ff745d0fde59a0f023dfe540f552c@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfB2FuyP+a0xl3BLyBkuMRVrSTR2H9ZchqEC9ktiUK9+vxQtWGP8tUsUqo84Ae2Hv4T1g2M4FHHV+ojFG7flrXndJ1JhkDwudRiVVyUWR/ekz+SF7o9qG lb9MEnS90VIGSJufGRrzu4HEfsJyOdseCwxqD82WCuzdhjCY3rOfySpMKotwjAujsAIbdUs2HL9DbmCNpq2ldNKV+rkAGuuuWLtcdxCpVU2NwXDLr8n/Vu/4 yH9fjWoCVtlhOAECunLiwQ== Archived-At: Subject: Re: [Roll] DTSN increment and DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 07:39:55 -0000 > > That's reasonable for some things, but not for others. > Right, so we wait for Rahul's new document and then start collecting opinions about future work. thanks Rahul. Peter From nobody Mon Apr 9 12:15:12 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE55312D77B for ; Mon, 9 Apr 2018 12:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04PoOIazHnLs for ; Mon, 9 Apr 2018 12:15:09 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43F0129C59 for ; Mon, 9 Apr 2018 12:15:08 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id p33-v6so9911709otp.11 for ; Mon, 09 Apr 2018 12:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=XagcK1bejbfdtKA38h0p5l4Mfn9B6ax+Cfb4QoCH7I8=; b=h4c3VQ0onkrueFrrZNYXLI+sDoSaS8lZeEplkbLOT0zeMKpIPOZPKFptPLgUBqnYXb PUnBqKxHKN441RftyhSu+m2pz8qbHoJOSTz4S9bT3OfI/GxXdUtp8YCYaIt34TqXWTLo 9cNnmaZOK7Cmvfu0DW47CMurjQC0JlTxQSPMDeALKDMAI544aM8ySn21RguhtU9mwsUP OogJ+GQCdLkeD24cE7IIbA/fOR2I1b8kwEYh8NPKbfc3Cp22ZsNYdiaWNenk08/LsW0O KGiW6iExJ5uKJ57tvqjArNtQA2pX0cZAq66ursnycZlrCiiYNZwDgQPsn5wb+/E4jwvC fDbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=XagcK1bejbfdtKA38h0p5l4Mfn9B6ax+Cfb4QoCH7I8=; b=jgcUT4W4jQEYjWRxllh2MPqGBShB5QHHzhlH5GiPpZNjQEB2Uldxx7Jl0ebPsHpHT2 XH/RLGKTg5Hd26kU3WidOAi6yLNhu4g5VdOx8hOUOQ9S76H/Rq8zFJhr+pA4phsmUbjA JS8i2MI0Zy2Y5WI9LZuDQEV3HPYRiBS1m7+ZA23bkcR7ObHNhSB/Q9MCpDu21HK9NoNA dRLjpiVHWvz8nhdlrZBdpCVGTYIwW+xH96ArC6H6VAbesP2KbFn1O+jo2aAu9mWzlmyC 7XKH2Tgmjr8i3FDao/YXb1BQHTF1UufGz9uFNf/isHmkbMp8BNVKlhgg4cTd6vaNFtPv o1HA== X-Gm-Message-State: ALQs6tBWpG0TSGdnSv2iUDb0iIMVAICb2FGrvnfaQ4p4UXx3wV4DQ0h5 M6f2xaErplYe+nxGVH4wdJhdQu5ZakaPdRusCQg= X-Google-Smtp-Source: AIpwx49/l92POJkzD7tRjJvQGFNGEGuGd3GdKBBtBm3uSr6I8PQlD2Swl2MAd49QbwaoDR1hlERJJxnVCk7toDjm8wY= X-Received: by 2002:a9d:26c2:: with SMTP id i2-v6mr25238647otd.132.1523301307957; Mon, 09 Apr 2018 12:15:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:3166:0:0:0:0:0 with HTTP; Mon, 9 Apr 2018 12:15:07 -0700 (PDT) In-Reply-To: <14809.1522944864@obiwan.sandelman.ca> References: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> <31500.1522940282@obiwan.sandelman.ca> <14809.1522944864@obiwan.sandelman.ca> From: Abdussalam Baryun Date: Mon, 9 Apr 2018 21:15:07 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000058c75405696f39a8" Archived-At: Subject: Re: [Roll] DTSN increment and DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 19:15:12 -0000 --00000000000058c75405696f39a8 Content-Type: text/plain; charset="UTF-8" yes to update 6550, On Thu, Apr 5, 2018 at 6:14 PM, Michael Richardson wrote: > > Michael Richardson wrote: > > * how to handle DTSN increment? want to also check how BIER does > > ... > > > * MCR: excellent work, should adopt it. Lots of useful > > points. Hadn't realized that the spec was ambiguous. > > * MCR: one document with solution: e.g. DTSN increment is > clearly a > > bug in the spec. > > * MCR: another document to discuss issues we don't have a > solution > > for. > > My impression is that there is some clarification needed in 6550. > I don't know if this should be done as errata or as an Updates, bacause > I haven't internalized the scale of the issue. > > > * Pascal: explains thinking about DAO-ACK. We need something to > > solve the end-to-end delivery. > > > * MCR: seems Pascal agrees. Just clarified a lot of things. 6550 > > did not capture that clearly. Low hanging fruit document should only > > include non-controversial points. > > * MCR: a bunch of knowledge just exposed, glad it's captured on > > tape. Want to capture it in text quickly. > > What I took home from the discussion is that DAO-ACK SHOULD be used on > networks where this is no L2 confirmation. That it's not end-to-end > (which is what I implemented!), and if we want end-to-end ACK, it > would be a new extension. > > > > * Rahul: will go to the mailing list to get consensus on what is > > non-controversial > > Just a reminder... Here a a few options that I was thinking about: > > 1) It's time to do rfc6550bis. This could be a non-trivial amount of work. > It can be bounded in time, but it's hard to do. > > 2) We should write a document that Updates RFC6550. > 2a) The *WG* creates a design team to create a low-hanging fruit document. > It would start with a document (already adopted by the WG. The DHCP WG > did this wrong in my opinion) that is essentially starts empty. > The design team would scavenge content from Rahul's document and > apply WG consensus to it being non-controversial. Lather.Rinse.Repeat. > > 2b) We adopt Rahul's document, or a version of, and then discover which > parts are controversial, and remove them until we have a simple > document. If left with empty set, STOP. > > Constroversial items go into new documents. > > 3) We adopt Rahul's document as a BCP and it contains non-normative > language only. > agree with 1, 2 but no.3 disagree so suggest informational if non-normative, but if BCP then normative. > > * Rahul: understand could maintain this draft as long as needed, > > and develop solutions in other documents? > > * Carsten: in the past in RoHC WG, have kept a standing doc for 5 > > years. > > That's reasonable for some things, but not for others. > > > yes, AB > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --00000000000058c75405696f39a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes to update 6550,


On Thu, Apr 5, 2018 at 6:14 PM= , Michael Richardson <mcr+ietf@sandelman.ca> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-= left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le= ft-style:solid">
Michael Richardson <mcr+ietf@= sandelman.ca> wrote:
=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * how to handle DTSN increment? want = to also check how BIER does

...

=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * MCR: excellent work, should adopt i= t. Lots of useful
=C2=A0 =C2=A0 > points. Hadn't realized that the spec was ambiguous.=
=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * MCR: one document with solution: e.= g. DTSN increment is clearly a
=C2=A0 =C2=A0 > bug in the spec.
=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * MCR: another document to discuss is= sues we don't have a solution
=C2=A0 =C2=A0 > for.

My impression is that there is some clarification needed in 6550.
I don't know if this should be done as errata or as an Updates, bacause=
I haven't internalized the scale of the issue.

=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * Pascal: explains thinking about DAO= -ACK. We need something to
=C2=A0 =C2=A0 > solve the end-to-end delivery.

=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * MCR: seems Pascal agrees. Just clar= ified a lot of things. 6550
=C2=A0 =C2=A0 > did not capture that clearly. Low hanging fruit document= should only
=C2=A0 =C2=A0 > include non-controversial points.
=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * MCR: a bunch of knowledge just expo= sed, glad it's captured on
=C2=A0 =C2=A0 > tape. Want to capture it in text quickly.

What I took home from the discussion is that DAO-ACK SHOULD be used on
networks where this is no L2 confirmation.=C2=A0 That it's not end-to-e= nd
(which is what I implemented!), and if we want end-to-end ACK, it
would be a new extension.


=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * Rahul: will go to the mailing list = to get consensus on what is
=C2=A0 =C2=A0 > non-controversial

Just a reminder...=C2=A0 Here a a few options that I was thinking about:
1) It's time to do rfc6550bis.=C2=A0 This could be a non-trivial amount= of work.
=C2=A0 =C2=A0It can be bounded in time, but it's hard to do.

2) We should write a document that Updates RFC6550.
2a) The *WG* creates a design team to create a low-hanging fruit document.<= br> =C2=A0 =C2=A0 It would start with a document (already adopted by the WG. Th= e DHCP WG
=C2=A0 =C2=A0 did this wrong in my opinion) that is essentially starts empt= y.
=C2=A0 =C2=A0 The design team would scavenge content from Rahul's docum= ent and
=C2=A0 =C2=A0 apply WG consensus to it being non-controversial.=C2=A0 Lathe= r.Rinse.Repeat.

2b) We adopt Rahul's document, or a version of, and then discover which=
=C2=A0 =C2=A0 parts are controversial, and remove them until we have a simp= le
=C2=A0 =C2=A0 document.=C2=A0 If left with empty set, STOP.

=C2=A0 =C2=A0 Constroversial items go into new documents.

3) We adopt Rahul's document as a BCP and it contains non-normative
=C2=A0 =C2=A0language only.

agree with = 1, 2 but no.3=C2=A0 disagree=C2=A0so suggest informational if non-normative= , but if BCP then normative.


=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * Rahul: understand could maintain th= is draft as long as needed,
=C2=A0 =C2=A0 > and develop solutions in other documents?
=C2=A0 =C2=A0 > =C2=A0=C2=A0=C2=A0 * Carsten: in the past in RoHC WG, ha= ve kept a standing doc for 5
=C2=A0 =C2=A0 > years.

That's reasonable for some things, but not for others.


yes,


AB=C2=A0=
--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


--00000000000058c75405696f39a8-- From nobody Mon Apr 9 18:35:15 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A62812D86E for ; Mon, 9 Apr 2018 18:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WHwB07_Y97f for ; Mon, 9 Apr 2018 18:35:11 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B41126B72 for ; Mon, 9 Apr 2018 18:35:11 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 62B5022CB50C8 for ; Tue, 10 Apr 2018 02:35:07 +0100 (IST) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Apr 2018 02:35:08 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Tue, 10 Apr 2018 09:34:59 +0800 From: "Liubing (Remy)" To: "roll@ietf.org" Thread-Topic: Updates of AODV-RPL since IETF101 Thread-Index: AdPP5WICQ1DxaeWwQkaiOu+P/Y37Aw== Date: Tue, 10 Apr 2018 01:34:59 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] Updates of AODV-RPL since IETF101 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 01:35:13 -0000 Hello ROLL, We are working on the revision of AODV-RPL. Hopefully, we will submit the n= ext version very soon. In the current draft, a 'T' bit is used in the RREP-DIO, when it is clear, = the Target Option encapsulating the OrigNode's address can be elided. Recen= tly, we discovered that if local InstanceID is used for the RREQ and RREP i= nstances, in RREP-DIO the Target Option MUST be present. This is due to the following two reasons: 1. The first reason is related to the route entries built in hop-by-hop mod= e. We think one route entry should have at least the following items: the r= oute's source and destination addresses, InstanceID, next-hop, lifetime. Be= cause the Instance ID is locally assigned, so it should be used with the so= urce address, which is the DODAGID. For the a upward route entry, all the i= tems can be learnt by related fields in the RREQ-DIO. For an intermediate n= ode not on the upward route, it won't get the source address for the downwa= rd route entry if the Target Option (including the OrigNode's address) is e= lided in the RREP-DIO, even though the InstanceID is well paired without an= y conflict. 2. The second reason is to solve the corner case when two router happen to = use the same local instanceID to do RD to the same TargNode. For example, N= ode A and B are trying to find routes to C, coincidentally, they use the sa= me InstanceID. They both are not aware of this situation when they send out= the RREQs, because the InstanceID is assigned locally. When A's RREQ arri= ves at C earlier than B' RREQ, C will send out the RREP-DIO to build route = to A. The InstanceID of RREP-DIO is paired to A's RREQ-DIO, and A's address= is elided ('T'=3D0). When receive B's RREQ, C will use another number shif= ted from the original one as the instanceID is already used by the RREP for= A. (But B is not aware of this.) When the RREP-DIO dedicated for A arrives= at B, B thinks this RREP-DIO is for itself by identify the paired Instance= ID and the DODAGID (which is C's address). In this case, B will build route= to C, but the routes follows A's requirements not B's. And B will not forw= ard the RREP-DIO to A. Probably, A will never get its RREP. Therefore, if local instanceID is used, the RREP-DIO for asymmetric route M= UST have exactly one target option, and the 'T' bit in RREP option is no lo= nger needed in this case. For symmetric route, the RREP-DIO is unicast to t= he OrigNode, the Target Option can be elided, because the addresses can be = learnt from the IPv6 header of RREP-DIO. Another solution to solve this problem is to use global InsanceID, which is= 128 in total. Is this a feasible solution? Looking forward to your comments. Best regards, Remy From nobody Fri Apr 20 20:51:07 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C616E12DA04 for ; Fri, 20 Apr 2018 20:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoifM0u1xDAR for ; Fri, 20 Apr 2018 20:51:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFB3124BFA for ; Fri, 20 Apr 2018 20:51:03 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9DD6C7AE7217F for ; Sat, 21 Apr 2018 04:50:59 +0100 (IST) Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 21 Apr 2018 04:51:00 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.113]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0382.000; Sat, 21 Apr 2018 09:20:52 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: Updates of AODV-RPL since IETF101 Thread-Index: AdPP5WICQ1DxaeWwQkaiOu+P/Y37AwJOg0Jg Date: Sat, 21 Apr 2018 03:50:52 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DBCCA95@BLREML503-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Updates of AODV-RPL since IETF101 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 03:51:06 -0000 Yes I understand that the 'T' bit in RREP-DIO cannot be elided because of t= he reasons you mentioned. It's fairly reasonable to assume that different n= odes might end up choosing the same local instance id (given that it is mer= ely 6 bits) to the same TargNode. Also I don't think using global InstanceID for solving this makes sense at = all. One scenario is, some 6LRs choose to be a 6LR only for global instance= s and avoid been 6LR for local instances, such scenarios will break. I'm su= re there will be many more reasons for not using global instance ids for su= ch use-case. One more point... You mentioned, " For symmetric route, the RREP-DIO is un= icast to the OrigNode, the Target Option can be elided, because the address= es can be learnt from the IPv6 header of RREP-DIO." Unicasting to OrigNode will not work because intermediate 6LRs won't proces= s it anymore. You need unicast hop-by-hop DIO to be used for this so that i= ntermediate 6LRs can process it. Regards, Rahul -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy) Sent: 10 April 2018 09:35 To: roll@ietf.org Subject: [Roll] Updates of AODV-RPL since IETF101 Hello ROLL, We are working on the revision of AODV-RPL. Hopefully, we will submit the n= ext version very soon. In the current draft, a 'T' bit is used in the RREP-DIO, when it is clear, = the Target Option encapsulating the OrigNode's address can be elided. Recen= tly, we discovered that if local InstanceID is used for the RREQ and RREP i= nstances, in RREP-DIO the Target Option MUST be present. This is due to the following two reasons: 1. The first reason is related to the route entries built in hop-by-hop mod= e. We think one route entry should have at least the following items: the r= oute's source and destination addresses, InstanceID, next-hop, lifetime. Be= cause the Instance ID is locally assigned, so it should be used with the so= urce address, which is the DODAGID. For the a upward route entry, all the i= tems can be learnt by related fields in the RREQ-DIO. For an intermediate n= ode not on the upward route, it won't get the source address for the downwa= rd route entry if the Target Option (including the OrigNode's address) is e= lided in the RREP-DIO, even though the InstanceID is well paired without an= y conflict. 2. The second reason is to solve the corner case when two router happen to = use the same local instanceID to do RD to the same TargNode. For example, N= ode A and B are trying to find routes to C, coincidentally, they use the sa= me InstanceID. They both are not aware of this situation when they send out= the RREQs, because the InstanceID is assigned locally. When A's RREQ arri= ves at C earlier than B' RREQ, C will send out the RREP-DIO to build route = to A. The InstanceID of RREP-DIO is paired to A's RREQ-DIO, and A's address= is elided ('T'=3D0). When receive B's RREQ, C will use another number shif= ted from the original one as the instanceID is already used by the RREP for= A. (But B is not aware of this.) When the RREP-DIO dedicated for A arrives= at B, B thinks this RREP-DIO is for itself by identify the paired Instance= ID and the DODAGID (which is C's address). In this case, B will build route= to C, but the routes follows A's requirements not B's. And B will not forw= ard the RREP-DIO to A. Pr obably, A will never get its RREP. Therefore, if local instanceID is used, the RREP-DIO for asymmetric route M= UST have exactly one target option, and the 'T' bit in RREP option is no lo= nger needed in this case. For symmetric route, the RREP-DIO is unicast to t= he OrigNode, the Target Option can be elided, because the addresses can be = learnt from the IPv6 header of RREP-DIO. Another solution to solve this problem is to use global InsanceID, which is= 128 in total. Is this a feasible solution? Looking forward to your comments. Best regards, Remy _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Mon Apr 23 02:09:40 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37528120713 for ; Mon, 23 Apr 2018 02:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjoKUijNFDQY for ; Mon, 23 Apr 2018 02:09:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E321200C1 for ; Mon, 23 Apr 2018 02:09:37 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8E49AC2D95F6B for ; Mon, 23 Apr 2018 10:09:33 +0100 (IST) Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 23 Apr 2018 10:09:34 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.113]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0382.000; Mon, 23 Apr 2018 14:39:24 +0530 From: Rahul Arvind Jadhav To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" CC: Michael Richardson Thread-Topic: [Roll] DTSN increment and DAO-ACK Thread-Index: AQHTzPk2N+MZjeNz3UWqAWi0snbupaP3tbsAgBYQvNA= Date: Mon, 23 Apr 2018 09:09:23 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DBCD143@BLREML503-MBS.china.huawei.com> References: <0b9d724cc65ecec4d40425903628c068@xs4all.nl> <31500.1522940282@obiwan.sandelman.ca> <14809.1522944864@obiwan.sandelman.ca> <7c3ff745d0fde59a0f023dfe540f552c@xs4all.nl> In-Reply-To: <7c3ff745d0fde59a0f023dfe540f552c@xs4all.nl> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] DTSN increment and DAO-ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 09:09:39 -0000 Hello ROLL,=20 As discussed, the document is updated (with some new section additions) whi= le retaining all the previous sections. https://tools.ietf.org/html/draft-rahul-roll-rpl-observations-01 Regards, Rahul -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: 09 April 2018 15:40 To: Routing Over Low power and Lossy networks Cc: Michael Richardson Subject: Re: [Roll] DTSN increment and DAO-ACK >=20 > That's reasonable for some things, but not for others. >=20 Right, so we wait for Rahul's new document and then start collecting opinio= ns about future work. thanks Rahul. Peter _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Mon Apr 23 03:06:59 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD2F126BF6 for ; Mon, 23 Apr 2018 03:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh92_5EcGcCg for ; Mon, 23 Apr 2018 03:06:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4BA1241F8 for ; Mon, 23 Apr 2018 03:06:55 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E9B79185FAE62 for ; Mon, 23 Apr 2018 11:06:51 +0100 (IST) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 23 Apr 2018 11:06:52 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Mon, 23 Apr 2018 18:06:46 +0800 From: "Liubing (Remy)" To: Routing Over Low power and Lossy networks Thread-Topic: Updates of AODV-RPL since IETF101 Thread-Index: AdPP5WICQ1DxaeWwQkaiOu+P/Y37AwJOg0JgAHKX5FA= Date: Mon, 23 Apr 2018 10:06:45 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DBCCA95@BLREML503-MBS.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DBCCA95@BLREML503-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Updates of AODV-RPL since IETF101 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 10:06:57 -0000 Hello Rahul, Thank you for your comments.=20 Yes, the RREP-DIO should be unicast hop-by-hop from the TargNode to the Ori= gNode. I just realized that for the second scenario that I've described, even for = symmetric route, it can also happen. Therefore, the RREP-DIO MUST carry exa= ctly one target option for both symmetric and asymmetric routes. Best regards, Remy > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Arvind Jadha= v > Sent: Saturday, April 21, 2018 11:51 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Updates of AODV-RPL since IETF101 >=20 > Yes I understand that the 'T' bit in RREP-DIO cannot be elided because of= the > reasons you mentioned. It's fairly reasonable to assume that different no= des > might end up choosing the same local instance id (given that it is merely= 6 bits) > to the same TargNode. >=20 > Also I don't think using global InstanceID for solving this makes sense a= t all. > One scenario is, some 6LRs choose to be a 6LR only for global instances a= nd > avoid been 6LR for local instances, such scenarios will break. I'm sure t= here > will be many more reasons for not using global instance ids for such use-= case. >=20 > One more point... You mentioned, " For symmetric route, the RREP-DIO is > unicast to the OrigNode, the Target Option can be elided, because the > addresses can be learnt from the IPv6 header of RREP-DIO." > Unicasting to OrigNode will not work because intermediate 6LRs won't > process it anymore. You need unicast hop-by-hop DIO to be used for this s= o > that intermediate 6LRs can process it. >=20 > Regards, > Rahul >=20 > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy) > Sent: 10 April 2018 09:35 > To: roll@ietf.org > Subject: [Roll] Updates of AODV-RPL since IETF101 >=20 > Hello ROLL, >=20 > We are working on the revision of AODV-RPL. Hopefully, we will submit the > next version very soon. >=20 > In the current draft, a 'T' bit is used in the RREP-DIO, when it is clear= , the > Target Option encapsulating the OrigNode's address can be elided. Recentl= y, > we discovered that if local InstanceID is used for the RREQ and RREP > instances, in RREP-DIO the Target Option MUST be present. >=20 > This is due to the following two reasons: >=20 > 1. The first reason is related to the route entries built in hop-by-hop m= ode. > We think one route entry should have at least the following items: the > route's source and destination addresses, InstanceID, next-hop, lifetime. > Because the Instance ID is locally assigned, so it should be used with th= e > source address, which is the DODAGID. For the a upward route entry, all t= he > items can be learnt by related fields in the RREQ-DIO. For an intermediat= e > node not on the upward route, it won't get the source address for the > downward route entry if the Target Option (including the OrigNode's addre= ss) > is elided in the RREP-DIO, even though the InstanceID is well paired with= out > any conflict. >=20 > 2. The second reason is to solve the corner case when two router happen t= o > use the same local instanceID to do RD to the same TargNode. For example, > Node A and B are trying to find routes to C, coincidentally, they use the= same > InstanceID. They both are not aware of this situation when they send out = the > RREQs, because the InstanceID is assigned locally. When A's RREQ arrives= at > C earlier than B' RREQ, C will send out the RREP-DIO to build route to A.= The > InstanceID of RREP-DIO is paired to A's RREQ-DIO, and A's address is elid= ed > ('T'=3D0). When receive B's RREQ, C will use another number shifted from = the > original one as the instanceID is already used by the RREP for A. (But B = is not > aware of this.) When the RREP-DIO dedicated for A arrives at B, B thinks = this > RREP-DIO is for itself by identify the paired InstanceID and the DODAGID > (which is C's address). In this case, B will build route to C, but the ro= utes > follows A's requirements not B's. And B will not forward the RREP-DIO > to A. P > r obably, A will never get its RREP. >=20 > Therefore, if local instanceID is used, the RREP-DIO for asymmetric route > MUST have exactly one target option, and the 'T' bit in RREP option is no > longer needed in this case. For symmetric route, the RREP-DIO is unicast = to > the OrigNode, the Target Option can be elided, because the addresses can > be learnt from the IPv6 header of RREP-DIO. >=20 > Another solution to solve this problem is to use global InsanceID, which = is 128 > in total. Is this a feasible solution? >=20 > Looking forward to your comments. >=20 > Best regards, > Remy >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Apr 23 03:29:08 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0211243F6 for ; Mon, 23 Apr 2018 03:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmPtn_MOeHZU for ; Mon, 23 Apr 2018 03:29:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EACA120454 for ; Mon, 23 Apr 2018 03:29:05 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 40FF2339C3DC4 for ; Mon, 23 Apr 2018 11:29:02 +0100 (IST) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 23 Apr 2018 11:29:03 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.113]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0382.000; Mon, 23 Apr 2018 15:58:54 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling Thread-Index: AQHTwcibFnu8hxNmEkuDN8v/VkuQIaQN4y+Q Date: Mon, 23 Apr 2018 10:28:53 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DBCD1B4@BLREML503-MBS.china.huawei.com> References: <8EC2893F-731B-439D-86FE-984505349D8D@tzi.org> In-Reply-To: <8EC2893F-731B-439D-86FE-984505349D8D@tzi.org> Accept-Language: en-IN, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 10:29:07 -0000 SGVsbG8gQ2Fyc3RlbiwNCg0KVGhhbmtzIGZvciByYWlzaW5nIHRoaXMuDQpMaWtlIHlvdSBtZW50 aW9uZWQsIHdlYXIgbGV2ZWxpbmcgcmVxdWlyZXMgb3Zlci1wcm92aXNpb25pbmcgb2YgZmxhc2gg c2VjdG9ycy4gSW4gc29tZSBzY2VuYXJpb3MsIGFwcGxpY2F0aW9uIGRvZXMgbm90IChvciBkb2Vz IHZlcnkgbGltaXRlZCkgcGVyc2lzdGVudCB3cml0ZSAoZm9yIGUuZy4gc3RyZWV0IGxpZ2h0IHNj ZW5hcmlvKS4gVGh1cyB0aGVyZSBpcyB2ZXJ5IGxlc3Mgb3Zlci1wcm92aXNpb25pbmcgYXNzdW1l ZC4gSW4gc3VjaCBjYXNlcywgaXQgaXMgZGlmZmljdWx0IHRvIGFzayBmb3Igb3Zlci1wcm92aXNp b25pbmcganVzdCBmb3IgdGhlIHNha2Ugb2YgUlBMIChzaW5jZSB0aGVyZSBpcyBubyBvdGhlciBt b2R1bGUgZG9pbmcgc3VjaCAocmVsYXRpdmVseSkgZnJlcXVlbnQgd3JpdGVzKS4gQWxzbyBSUEwg c2lnbmFsaW5nIGRvZXMgbm90IGFsbG93IG11bHRpcGxlIHN0YXRlIGluZm9ybWF0aW9uIHRvIGJl IGNsdWJiZWQgdG9nZXRoZXIgYW5kIGRvIGEgc2luZ2xlIHdyaXRlKHdyaXRlIGlzIGluIHRlcm1z IG9mIHBhZ2VzIGFuZCB0aHVzIG5vdCBnb29kIGZvciBsZXNzIG51bWJlciBvZiBieXRlcykuIFRo ZSBxdWVzdGlvbiBpcywgSXMgaXQgcG9zc2libGUgZm9yIFJQTCBzaWduYWxpbmcgdG8gcmVkdWNl IHBlcnNpc3RlbnQgd3JpdGUgYXQgdGhlIGNvc3Qgb2YgYWRkaW5nIHNvbWUgc2lnbmFsaW5nIGR1 cmluZyBub2RlIGJvb3QgKGF0LWxlYXN0IGZvciA2TFJzIGFuZCA2TE5zKS4gTm9kZSByZWJvb3Qg d2lsbCBiZSByZWxhdGl2ZWx5IHJhcmUtb2NjdXJyZW5jZSAob3IgYXQtbGVhc3QgbXVjaCBsZXNz IGZyZXF1ZW50KSBhbmQgdGh1cyB0aGUgY29zdCBvZiBhZGRpdGlvbmFsIHNpZ25hbGluZyBiaXRz IG1pZ2h0IGJlIHdvcnRoIGl0ICg/KS4gQWxzbyBJIGZlZWwgbmV3IFJQTCBleHRlbnNpb25zIHNo b3VsZCBjb25zaWRlciB0aGlzIGFuZCBkbyBub3QgY29tbWl0IHRvIHBlcnNpc3RlbnQgc3RvcmFn ZSBtb3JlIGZyZXF1ZW50bHkuDQoNClRoYW5rcywNClJhaHVsDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBSb2xsIFttYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQ2Fyc3RlbiBCb3JtYW5uDQpTZW50OiAyMiBNYXJjaCAyMDE4IDE4OjI5DQpUbzog Um91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbUm9sbF0gZHJhZnQtcmFodWwtcm9sbC1ycGwtb2JzZXJ2YXRpb25zLTAwIFNl Y3Rpb24gMi4xOiBXZWFyIGxldmVsaW5nDQoNClRvZGF5LCBhdCB0aGUgbWlrZSwgSSBhc2tlZCBh Ym91dCB3ZWFyIGxldmVsaW5nLg0KDQpUaGUgbnVtYmVycyBpbiAyLjEgc2VlbSB0byBhc3N1bWUg eW91IGRvIGEgZnVsbCBlcmFzZS93cml0ZSBjeWNsZSBwZXIgc3RvcmUgb3BlcmF0aW9uLg0KVGhh dCBpcyBub3QgYSBnb29kIHdheSB0byB1c2UgRmxhc2ggc3RvcmFnZS4gIE9idmlvdXNseSwgZm9y IHRydWUgd2VhciBsZXZlbGluZyB5b3UgbmVlZCBhIGJpdCBtb3JlIGZsYXNoIHNwYWNlIChhbmQg YSBiaXQgbW9yZSBjb2RlLCB3aGljaCBhbHNvIG5lZWRzIGZsYXNoIHNwYWNlKSwgYnV0IHRoZW4g dGhlcmUgYWxyZWFkeSBhcmUgb3RoZXIgaXRlbXMgdGhhdCB5b3Ugd2FudCB0byBjb21taXQgdG8g c3RhYmxlIHN0b3JhZ2Ugb24gYSBzb21ld2hhdCByZWd1bGFyIGJhc2lzLg0KDQpHcsO8w59lLCBD YXJzdGVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Tue Apr 24 07:10:56 2018 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1242C128C0A; Tue, 24 Apr 2018 07:10:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?UmFkZWsgS3JlasSNw60=?= To: Cc: draft-ietf-roll-mpl-yang.all@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152457905501.28827.10765559103930741007@ietfa.amsl.com> Date: Tue, 24 Apr 2018 07:10:55 -0700 Archived-At: Subject: [Roll] Yangdoctors early review of draft-ietf-roll-mpl-yang-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 14:10:55 -0000 Reviewer: Radek Krejčí Review result: Not Ready This document specifies 4 YANG modules for Multicast Protocol for Low power and lossy Networks (MPL) implementations. The document is not NMDA compliant and the separated modules are not correctly linked together (not even via leafrefs, but I suggest to redesign them as augments). document - all the modules are YANG 1.1, but you refer to RFC 6020 which defines YANG 1.0, fix the references to RFC 7950 - there is no note about NMDA, the document is NOT NMDA compliant because of the separated status data which are actually connected with the specific mpl domains (see below) Section 1.1 - there is no note about SID term, you should refer draft-ietf-core-sid Section 1.1.1 - instead of text description, refer to the Tree diagram specification (follow rfc6087bis sec. 3.4) Section 2 - consider to split description of the modules to their tree diagrams, the intro of the section could be just about motivation to split all the data into a separated modules Section 3 - as mentioned for section 1.1, there is no explanation of SID term, no reference, nothing Section 4 OLD This section describes four yang modules. The model is based NEW This section describes four yang modules. The models are based - RFC 7223 was obsoleted by 8343 - division between the schemas is not clear to me. Isn't the mpl-domain kind of core module, while the others extend it? In mpl-ops, I see mpl-parameter list connected with domainID from mpl-domain. Despite it should be at least leafref, I believe that it should actually augment the domains list from mpl-domain. Similarly, you can have the mpl-domain's top level domain (or better rename it to something like mpl) container as a top-level container holding all the mpl-related data together. This is also the reason why the document is NOT NMDA compliant - instead of augmenting domains list, the status data are held in a separate data tree. - please fix indentation in the models. It makes reading of the model very difficult. If statement (mainly descriptions) carry into a subsequent line, please indent also those consequent lines. Also indent opening { of a node definition (e.g. domainID{ -> domainID {) - update copyright notice (year) - you mix several naming conventions: domainID, SEED_SET_ENTRY_LIFETIME, life-time - please follow rfc6087bis sec 4.3.1 Section 5 - draft must register schema modules, so there are definitely IANA considerations. Besides this, I believe that also SID numbers are supposed to be registered via IANA. Section 7 - update and maintain the changelog! The current information are taken from draft-vanderstok-roll-mpl-yang. ietf-yang-mpl-domain@2018-03-29.yang /domain/single - calling the whole switch as one of its case does not seem descriptive /domain/single/mpl-domain/mpl-domain/addresses/interfaces - where, in RFC 6206, is interface name defined? Probably should be RFC 8343 - why not use leafref to ietf-interfaces? ietf-yang-mpl-ops@2018-03-29.yang /mpl-ops/SEED_SET_ENTRY_LIFETIME (and several others) - use default statement - consider using units statement /mpl-ops/mpl-parameter/domainID - should be leafref, but actually the whole mpl-parameter should be an augment of domains list in mpl-domain /mpl-ops/mpl-parameter/CONTOL_MESSAGE_I* (and possibly others) - aren't there some limitations? Such as min < max? Then there should be must statement with the appropriate constraint specification. ietf-yang-mpl-seeds@2018-03-29.yang /mpl-seeds/local - fix upper cases in description or better rewrite the description as a sentence /mpl-seeds/buffered-messages/t I - there is no SE-LIFETIME in the modules nor draft ietf-yang-mpl-statistics@2018-03-29.yang /mpl-statistics/nr-of-copies-forwarded - there is no number-of-copies-received in the modules nor draft /mpl-statistics/reset-statistics - according to the location of the action, it is supposed to reset just the statistics for the specific buffer set (instance of the mpl-statistics list), right? Maybe it should be clarified in description, now there is "all statistics" which can be confusing according to the place of the action. From nobody Tue Apr 24 17:28:38 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED212D948 for ; Tue, 24 Apr 2018 17:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XHZ3HVpBcT3 for ; Tue, 24 Apr 2018 17:28:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EE5126D85 for ; Tue, 24 Apr 2018 17:28:34 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F2366D1B9F2FA for ; Wed, 25 Apr 2018 01:28:31 +0100 (IST) Received: from BLREML702-CAH.china.huawei.com (10.20.4.171) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 25 Apr 2018 01:28:32 +0100 Received: from BLREML503-MBS.china.huawei.com ([169.254.12.113]) by blreml702-cah.china.huawei.com ([::1]) with mapi id 14.03.0382.000; Wed, 25 Apr 2018 05:58:22 +0530 From: Rahul Arvind Jadhav To: Routing Over Low power and Lossy networks Thread-Topic: Updates of AODV-RPL since IETF101 Thread-Index: AdPP5WICQ1DxaeWwQkaiOu+P/Y37AwJOg0JgAHKX5FAAAScCsA== Date: Wed, 25 Apr 2018 00:28:22 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DBCEF31@BLREML503-MBS.china.huawei.com> References: <982B626E107E334DBE601D979F31785C5DBCCA95@BLREML503-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Updates of AODV-RPL since IETF101 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 00:28:37 -0000 Thanks Remy, Thus I assume T bit will be removed?=20 Another Question: Section 6.3.3. last para talks about handling paired inst= anceID collision on TargNode. The details are insufficient regarding how to= handle "shifting of instanceID". RREP option has SHIFT field to indicate = the shifting, but when it reaches OrigNode and if the resulting shifted ins= tanceID is already in use by OrigNode then how should the handling be? How = to clean-up the states established on 6LRs because of previous RREQ-DIO ins= tance? Will shifting result in another round of RREQ-DIO, RREP-DIO ? IMO, this warrants a separate section. Regards, Rahul -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy) Sent: 23 April 2018 18:07 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Updates of AODV-RPL since IETF101 Hello Rahul, Thank you for your comments.=20 Yes, the RREP-DIO should be unicast hop-by-hop from the TargNode to the Ori= gNode. I just realized that for the second scenario that I've described, even for = symmetric route, it can also happen. Therefore, the RREP-DIO MUST carry exa= ctly one target option for both symmetric and asymmetric routes. Best regards, Remy > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Arvind=20 > Jadhav > Sent: Saturday, April 21, 2018 11:51 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Updates of AODV-RPL since IETF101 >=20 > Yes I understand that the 'T' bit in RREP-DIO cannot be elided because=20 > of the reasons you mentioned. It's fairly reasonable to assume that=20 > different nodes might end up choosing the same local instance id=20 > (given that it is merely 6 bits) to the same TargNode. >=20 > Also I don't think using global InstanceID for solving this makes sense a= t all. > One scenario is, some 6LRs choose to be a 6LR only for global=20 > instances and avoid been 6LR for local instances, such scenarios will=20 > break. I'm sure there will be many more reasons for not using global inst= ance ids for such use-case. >=20 > One more point... You mentioned, " For symmetric route, the RREP-DIO=20 > is unicast to the OrigNode, the Target Option can be elided, because=20 > the addresses can be learnt from the IPv6 header of RREP-DIO." > Unicasting to OrigNode will not work because intermediate 6LRs won't=20 > process it anymore. You need unicast hop-by-hop DIO to be used for=20 > this so that intermediate 6LRs can process it. >=20 > Regards, > Rahul >=20 > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy) > Sent: 10 April 2018 09:35 > To: roll@ietf.org > Subject: [Roll] Updates of AODV-RPL since IETF101 >=20 > Hello ROLL, >=20 > We are working on the revision of AODV-RPL. Hopefully, we will submit=20 > the next version very soon. >=20 > In the current draft, a 'T' bit is used in the RREP-DIO, when it is=20 > clear, the Target Option encapsulating the OrigNode's address can be=20 > elided. Recently, we discovered that if local InstanceID is used for=20 > the RREQ and RREP instances, in RREP-DIO the Target Option MUST be presen= t. >=20 > This is due to the following two reasons: >=20 > 1. The first reason is related to the route entries built in hop-by-hop m= ode. > We think one route entry should have at least the following items: the=20 > route's source and destination addresses, InstanceID, next-hop, lifetime. > Because the Instance ID is locally assigned, so it should be used with=20 > the source address, which is the DODAGID. For the a upward route=20 > entry, all the items can be learnt by related fields in the RREQ-DIO.=20 > For an intermediate node not on the upward route, it won't get the=20 > source address for the downward route entry if the Target Option=20 > (including the OrigNode's address) is elided in the RREP-DIO, even=20 > though the InstanceID is well paired without any conflict. >=20 > 2. The second reason is to solve the corner case when two router=20 > happen to use the same local instanceID to do RD to the same TargNode.=20 > For example, Node A and B are trying to find routes to C,=20 > coincidentally, they use the same InstanceID. They both are not aware=20 > of this situation when they send out the RREQs, because the InstanceID=20 > is assigned locally. When A's RREQ arrives at C earlier than B' RREQ,=20 > C will send out the RREP-DIO to build route to A. The InstanceID of=20 > RREP-DIO is paired to A's RREQ-DIO, and A's address is elided ('T'=3D0).= =20 > When receive B's RREQ, C will use another number shifted from the=20 > original one as the instanceID is already used by the RREP for A. (But=20 > B is not aware of this.) When the RREP-DIO dedicated for A arrives at=20 > B, B thinks this RREP-DIO is for itself by identify the paired=20 > InstanceID and the DODAGID (which is C's address). In this case, B will b= uild route to C, but the routes follows A's requirements not B's. And B wil= l not forward the RREP-DIO > to A. P > r obably, A will never get its RREP. >=20 > Therefore, if local instanceID is used, the RREP-DIO for asymmetric=20 > route MUST have exactly one target option, and the 'T' bit in RREP=20 > option is no longer needed in this case. For symmetric route, the=20 > RREP-DIO is unicast to the OrigNode, the Target Option can be elided,=20 > because the addresses can be learnt from the IPv6 header of RREP-DIO. >=20 > Another solution to solve this problem is to use global InsanceID,=20 > which is 128 in total. Is this a feasible solution? >=20 > Looking forward to your comments. >=20 > Best regards, > Remy >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Tue Apr 24 18:48:25 2018 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7098F12DA07 for ; Tue, 24 Apr 2018 18:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhJv_rjFFAQm for ; Tue, 24 Apr 2018 18:48:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B52E126D85 for ; Tue, 24 Apr 2018 18:48:21 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8EEE0949357AD for ; Wed, 25 Apr 2018 02:48:18 +0100 (IST) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 25 Apr 2018 02:48:19 +0100 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Wed, 25 Apr 2018 09:48:14 +0800 From: "Liubing (Remy)" To: Routing Over Low power and Lossy networks Thread-Topic: Updates of AODV-RPL since IETF101 Thread-Index: AdPP5WICQ1DxaeWwQkaiOu+P/Y37AwJOg0JgAHKX5FAAAScCsABRe2eg Date: Wed, 25 Apr 2018 01:48:14 +0000 Message-ID: References: <982B626E107E334DBE601D979F31785C5DBCCA95@BLREML503-MBS.china.huawei.com> <982B626E107E334DBE601D979F31785C5DBCEF31@BLREML503-MBS.china.huawei.com> In-Reply-To: <982B626E107E334DBE601D979F31785C5DBCEF31@BLREML503-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Updates of AODV-RPL since IETF101 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2018 01:48:24 -0000 Hello Rahul, Yes, the T bit will be removed. Thanks for raising a good point about the SHIFT field. We will add a sectio= n talking about this. The "shifting of instanceID" is used to distinguish the two RREP-instances = at the TargNode, when two OrigNodes happen to use the same local InstanceID= s to the same TargNode. Any intermediate node should rebroadcast the RREP-D= IO without changing the (shifted) InstanceID. However, when building routin= g state in hop-by-hop mode ('H'=3D1) at an intermediate node, the original = InstanceID (shift back) should be used. When receiving the RREP-DIO, the Or= igNode will shift back to the original InstanceID. Since the original Insta= nceID is assigned by the OrigNode, there should be no conflict. There is no= need to have another round of RREQ-DIO and RREP-DIO if the routes are foun= d successfully. The states established on 6LRs will timeout eventually if t= hey are not used for packet forwarding. Best regards, Remy > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Arvind Jadha= v > Sent: Wednesday, April 25, 2018 8:28 AM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Updates of AODV-RPL since IETF101 >=20 > Thanks Remy, >=20 > Thus I assume T bit will be removed? >=20 > Another Question: Section 6.3.3. last para talks about handling paired > instanceID collision on TargNode. The details are insufficient regarding = how > to handle "shifting of instanceID". RREP option has SHIFT field to indic= ate the > shifting, but when it reaches OrigNode and if the resulting shifted insta= nceID > is already in use by OrigNode then how should the handling be? How to > clean-up the states established on 6LRs because of previous RREQ-DIO > instance? Will shifting result in another round of RREQ-DIO, RREP-DIO ? > IMO, this warrants a separate section. >=20 > Regards, > Rahul >=20 >=20 > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy) > Sent: 23 April 2018 18:07 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Updates of AODV-RPL since IETF101 >=20 > Hello Rahul, >=20 > Thank you for your comments. >=20 > Yes, the RREP-DIO should be unicast hop-by-hop from the TargNode to the > OrigNode. >=20 > I just realized that for the second scenario that I've described, even fo= r > symmetric route, it can also happen. Therefore, the RREP-DIO MUST carry > exactly one target option for both symmetric and asymmetric routes. >=20 > Best regards, > Remy >=20 > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Arvind > > Jadhav > > Sent: Saturday, April 21, 2018 11:51 AM > > To: Routing Over Low power and Lossy networks > > Subject: Re: [Roll] Updates of AODV-RPL since IETF101 > > > > Yes I understand that the 'T' bit in RREP-DIO cannot be elided because > > of the reasons you mentioned. It's fairly reasonable to assume that > > different nodes might end up choosing the same local instance id > > (given that it is merely 6 bits) to the same TargNode. > > > > Also I don't think using global InstanceID for solving this makes sense= at all. > > One scenario is, some 6LRs choose to be a 6LR only for global > > instances and avoid been 6LR for local instances, such scenarios will > > break. I'm sure there will be many more reasons for not using global > instance ids for such use-case. > > > > One more point... You mentioned, " For symmetric route, the RREP-DIO > > is unicast to the OrigNode, the Target Option can be elided, because > > the addresses can be learnt from the IPv6 header of RREP-DIO." > > Unicasting to OrigNode will not work because intermediate 6LRs won't > > process it anymore. You need unicast hop-by-hop DIO to be used for > > this so that intermediate 6LRs can process it. > > > > Regards, > > Rahul > > > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy) > > Sent: 10 April 2018 09:35 > > To: roll@ietf.org > > Subject: [Roll] Updates of AODV-RPL since IETF101 > > > > Hello ROLL, > > > > We are working on the revision of AODV-RPL. Hopefully, we will submit > > the next version very soon. > > > > In the current draft, a 'T' bit is used in the RREP-DIO, when it is > > clear, the Target Option encapsulating the OrigNode's address can be > > elided. Recently, we discovered that if local InstanceID is used for > > the RREQ and RREP instances, in RREP-DIO the Target Option MUST be > present. > > > > This is due to the following two reasons: > > > > 1. The first reason is related to the route entries built in hop-by-hop= mode. > > We think one route entry should have at least the following items: the > > route's source and destination addresses, InstanceID, next-hop, lifetim= e. > > Because the Instance ID is locally assigned, so it should be used with > > the source address, which is the DODAGID. For the a upward route > > entry, all the items can be learnt by related fields in the RREQ-DIO. > > For an intermediate node not on the upward route, it won't get the > > source address for the downward route entry if the Target Option > > (including the OrigNode's address) is elided in the RREP-DIO, even > > though the InstanceID is well paired without any conflict. > > > > 2. The second reason is to solve the corner case when two router > > happen to use the same local instanceID to do RD to the same TargNode. > > For example, Node A and B are trying to find routes to C, > > coincidentally, they use the same InstanceID. They both are not aware > > of this situation when they send out the RREQs, because the InstanceID > > is assigned locally. When A's RREQ arrives at C earlier than B' RREQ, > > C will send out the RREP-DIO to build route to A. The InstanceID of > > RREP-DIO is paired to A's RREQ-DIO, and A's address is elided ('T'=3D0)= . > > When receive B's RREQ, C will use another number shifted from the > > original one as the instanceID is already used by the RREP for A. (But > > B is not aware of this.) When the RREP-DIO dedicated for A arrives at > > B, B thinks this RREP-DIO is for itself by identify the paired > > InstanceID and the DODAGID (which is C's address). In this case, B will= build > route to C, but the routes follows A's requirements not B's. And B will n= ot > forward the RREP-DIO > > to A. P > > r obably, A will never get its RREP. > > > > Therefore, if local instanceID is used, the RREP-DIO for asymmetric > > route MUST have exactly one target option, and the 'T' bit in RREP > > option is no longer needed in this case. For symmetric route, the > > RREP-DIO is unicast to the OrigNode, the Target Option can be elided, > > because the addresses can be learnt from the IPv6 header of RREP-DIO. > > > > Another solution to solve this problem is to use global InsanceID, > > which is 128 in total. Is this a feasible solution? > > > > Looking forward to your comments. > > > > Best regards, > > Remy > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll