From nobody Fri Jan 5 03:42:11 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 EE6271205F0 for ; Fri, 5 Jan 2018 03:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 V_7yXVAR___e for ; Fri, 5 Jan 2018 03:42:06 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 87ED81200C5 for ; Fri, 5 Jan 2018 03:42:05 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g130so6005279wme.0 for ; Fri, 05 Jan 2018 03:42:04 -0800 (PST) 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 :cc; bh=FX1u6rVN+N5BnPjpSpxVqkOtGrq0LLlf5TiQuqCl/TA=; b=ierSzpeaEnalR3SY+mc6ZnZFkDfe5IKtyfwGZnAnAEhjxOoRN4y+HWzsMOA88ZQtNq fIsdYBMo7m4VAuNlazxR+ighdc4OBVNNcmT8rjh1uxNJXo6EAKUZrKPFhzw3AepQlWmA Y7t46K6tb6kbZVmfAJXP6tyVr9fCU5cIOmpNo+ANx9290GnjhlniY9NdUQxVhbEeB8Jc UL21O2VhGrXEs8I3NS2Ou9ghfHQJA+LbcHh5EJuyaGJE8lEMgSiZVSzzY/+juUn4jUDq v1fD3S8YWAjWdpNDMimBBMl3M5kx6IDbXksKzXU7e/AYedPcOtOIfnwzIUh6Si4ccsty nl+w== 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:cc; bh=FX1u6rVN+N5BnPjpSpxVqkOtGrq0LLlf5TiQuqCl/TA=; b=V9UNQZGXVBWbz7skU7jf2V0H3h+dcwdfX+jLb0v4FmxY6hXqjvJslSungqdrLGmLZk ys3x0FNfRAfs5BOK7xWZF8jhlj8iGOrLXMpKp+hLHXYYxFERDJate1zaClwZAKD1Uzzu VXcTndu4P7CL+UCgq23/FsmIYNiDpKw3rnu2wWpoT8P8v5qGreXTxauobFGBEgUV6/OB z6vISULzQaJ17DQYT1FnijuhL5y/9W1RGqbjxAkgl2zpOv2kN3nrjEyisKH9QccXww0d cIllXPu5RBplron8AwYr35vXJ7zH7YJYv46dkTKmhdBcp0UycKStU3SYgLATvCXMmfkc axCg== X-Gm-Message-State: AKGB3mIC0bwYl57fM2dOHed/tJdDxGWbUYPUPGq7jvh6mz1F1OlJEUtB vuBwHTL5DaDy7qBmTHItUdHkQM5JotP7JtkMKoU= X-Google-Smtp-Source: ACJfBosTJrjg8x/sapRNEtmexv2aamuypyKhSwWcvBXm4Ok0FMi0Iw9mjp3Gcv27G1Tz9ACwYBZU8dkDSFGwlPFl0v0= X-Received: by 10.80.245.71 with SMTP id w7mr3730318edm.59.1515152523450; Fri, 05 Jan 2018 03:42:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.142.4 with HTTP; Fri, 5 Jan 2018 03:42:02 -0800 (PST) In-Reply-To: References: From: Rahul Jadhav Date: Fri, 5 Jan 2018 17:12:02 +0530 Message-ID: To: "Liubing (Remy)" Cc: Charlie Perkins , "Zhangmingui (Martin)" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a114f4844f0dd5b056205efd1" Archived-At: Subject: Re: [Roll] Review of AODV-RPL 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: Fri, 05 Jan 2018 11:42:10 -0000 --001a114f4844f0dd5b056205efd1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Remy, Please find my comments inline. Regards, Rahul p.s. i feel a voice call will help us better here. Will ping you. On 25 December 2017 at 12:44, Liubing (Remy) wrote: > Hi Rahul, > > > > Please find my comments inline. > > > > Best regards, > > Remy > > > > *From:* Roll [mailto:roll-bounces@ietf.org ] *On > Behalf Of *Rahul Jadhav > *Sent:* Wednesday, December 20, 2017 8:11 PM > *To:* Charlie Perkins > *Cc:* Routing Over Low power and Lossy networks > *Subject:* Re: [Roll] Review of AODV-RPL > > > > Hello Charlie, > > > > Please find my response inline.. > > Regards, > > Rahul > > > > On 15 December 2017 at 20:49, Charlie Perkins < > charles.perkins@earthlink.net> wrote: > > Hello Rahul, > > Thanks for the review! It is much appreciated. I have some follow-up > below. > > > > On 11/15/2017 8:57 PM, Rahul Jadhav wrote: > > Following is my review of AODV-RPL. > > One of the stated goal of AODV-RPL is to cater to asymmetric links. While > this is really great to have, I have doubts that the current specificatio= n > achieves it in a practical way. Foll is the reasoning: > > 1. The Messaging: > > AODV-RPL requires that you send a multicast message from OrigNode to > TargNode and realise a routing path in the opposite direction. > > For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards D and > nodes B,C,D establish routing adjacencies in the opposite direction. This > kind of messaging is the reason why RPL depends on bidirectional links fo= r > control/data paths. > > > It's not just RPL. A lot of protocols work this way. > > > > [RJ] But this mode of signaling does not help satisfy the stated goal of > establishing asymmetric links. RPL (and others like p2p-rpl) follows this > mode of signaling and hence depend on bidirectional links. > > [Remy] I think we have a misunderstanding here. =E2=80=9CBidirectional=E2= =80=9D talks > about the reachability, while =E2=80=9Csymmetric=E2=80=9D talks about the= upward and > downward routes. The =E2=80=9Casymmetric=E2=80=9D here signifies the upwa= rd and downward > routes between the OrigNode and the TargNode are different, while > "bidirectional" means control messages can be received in two directions. > Both RPL and AODV-RPL use bidirectional links. > [RJ] I m not very clear of this text. AODV-RPL cannot depend on bidirectional links to establish asymmetric paths. > 2. The Assumptions: > > a. Quoting draft, > > =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance a= nd > creates a routing table entry for the upstream route towards the source > if the routing metrics/constraints are satisfied. For this purpose R_i > ***must use the asymmetric link metric measured in the upstream > direction***, from R_i to its upstream neighbor that multicasted the > RREQ-Instance message.=E2=80=9D > > This is the primary assumption which achieves asymmetric behaviour. But > it=E2=80=99s an implementation nightmare to do this measurement especiall= y because > we do not know which neighbour we might end up tieing up with (thus need = to > probe all neighbours). > > > I don't think this is true. A node simply has to keep track of the > information for the upstream destination, and the information about the > specific node from which the RREQ was received. > > > > [RJ] Assuming a moderately populated hop, a node now needs to keep track > of information in context all the peers on the same hop. You mentioned, > 'node needs to track only upstream destination' ... but imo this is not > true. For P2P paths, its a different DAG instance and thus there are no > pre-determined *upstream destinations*. > > [Remy] The upstream destination is the OrigNode, which is the root of the > DODAG. An intermediate node only needs to maintain a route entry to the > OrigNode, including the information of the next hop on the upstream route= . > The next hop is actually the node=E2=80=99s preferred parent in this DODA= G. > [RJ] I understand that from the routing table perspective only the OrigNode entry has to be established. My point was in context to identifying/probing adjoining next hop through which this route would be established. For this probing you need to maintain a table which will have all adjoining peers. > > > It will add up so much to the control overhead and also requires (a good > deal of) state info to be maintained on behalf of the neighbouring nodes. > > > I don't see why it adds much to the control overhead. The state can be > timed out after a relatively small duration of time. We will add that > timeout parameter for the next revision. > > > > [RJ] The reason for high control overhead is that the node will have to > keep probing the neighbors to maintain state. The problem with smaller > duration time is that thhen e probe will be more frequent! Regardless, th= e > table that needs to be maintained for such information is directly > proportional to the number of neighboring peers. > > [Remy] The node doesn=E2=80=99t have to probe all its neighbor. Don=E2=80= =99t forget that > AODV-RPL is an extension of RPL, and the RREP and RREQ are two new DIO > options. Thus the DIO transmission, local repair and many other mechanism= s > to maintain the state are the same as RPL. Therefore, the control overhe= ad > will stay the same. > [RJ] I understand that the DIO transmission, and other factors remain the same. Adding RREP/RREQ on top of existing DIO messaging does not achieve asymmetric paths. When OrigNode sends a DIO, its received by another node downstream and the path is established upstream. This is the mechanism RPL follows. Also AODV-RPL follows the same signalling mechanism and this is where the problem starts with the asymmetric path claim. > > > > > > > > Anyways i tried to search for your implementation to check on this but i > could not find it. > > b. Use of past conditions to suggest future traffic path selection: > > =E2=80=9CIf the RREQ-Instance arrives over an interface that is not known= to be > symmetric, or is known to be asymmetric, the 'S' bit is set to be 0.=E2= =80=9D > > This is a typical problem we face as well. Probing for measurements at > such scale (all neighbours) is a problem. If you do the probing sparsely, > the network conditions might have changed when you want to use the > measurements. > > > Yes, this is naturally a problem in dynamic networks. We can't predict > the future, so we are stuck with recording salient aspects of the past. = No > matter how often we measure, it is guaranteed to be wrong some (or most!) > of the time in the future. And yet we persist. > > But we do not require periodic or exhaustive measurements for all > neighbors -- only as needed for the protocol to work. > > > > [RJ] May be this is the part i don't get ... You mentioned "only as neede= d > for the protocol to work" ... Can this be elaborated? > > [Remy] Again, it is still in the framework of RPL, so the probing is done > in the same way as RPL, i.e. by DIO and DIS, which are controlled by the > trickle timer. > [RJ]: No. Probing cannot be done the same way. In case of RPL, DIO is sent downstream and the downstream nodes use DIO metrics and messaging signal qualities to establish upstream path. This is ok in case of RPL because RPL says that it depends upon bidirectional connectivity (not necessarily symmetric but still bidirectional for e.g. power levels in both direction might vary but the messaging still works) for it to work. Now for AODV-RPL's asymmetric claim to work, the upstream and downstream paths between the same pair of nodes can be different. For asymmetric links, AODV-RPL cannot depend upon RPL's style of DIO messaging. > > > > > Other points: > > 1. Use of odd/even numbers for pairing instances may not be a robust > way of pairing =E2=80=A6 There could be race conditions where other P2= P-RPL > instances or floating DODAG instances end up using one of the same val= ue in > the instance-id pair. How to resolve such collision? > > > But, the instance-ids are local. So if two different nodes use the same > ID that is O.K. If those two nodes need to have a peer-to-peer route to > the same destination, that is still O.K., but the RREP sent back to one o= f > the source nodes will be able to use the paired instance-ID and the > streamlined RREP, and the other RREP will have to include an unpaired > instance-ID along with the IPv6 address of the target node. That will be= a > rare occurrence, and so the optimization of eliding the IPv6 address wil= l > usually be possible. > > > > [RJ] Yeah, for local instances this might not be a problem. Thanks. > > > > > 1. I would recommend to use Cooja with links in DGRM mode to evaluate > the perf. > > > This sounds like a good idea. The other co-authors will probably have > more follow-up about this. > > > 1. The RSSI values in the Appendix do not look correct. An RSSI of > <-70dbm is too good [1] to have for good PDR. The mapping of RSSI-ETX = in > the appendix hence may not be correct (i believe these values are from > Cooja). > > > I don't understand how an RSSI could be "too good", unless you mean that > the power level is too high and causes widespread interference. > Admittedly, I am no expert in interpreting PHY layer effects, but anyway > usually higher received power allows more accurate detection, if the > background noise level remains the same. > > > > [RJ] My reference here is to the RSSI to ETX mapping table in the draft. > The values noted in that table do not look correct. For RSSI -55 to -45db= m, > the expected ETX is 993. On what basis was this table generated ? Typical= ly > i have found that RSSI of < -80dbm results in very good PDRs (also the re= f > i attached says the same). > > > > > > > > [1] RSSI is Under-Appreciated https://sing.stanford.edu/ > site/publications/emnets2006srinivasan.pdf > > > Thanks for the link. I read through it very briefly on this fine > morning. However, I have also read other papers that seriously question > the value of relying on RSSI. > > I'll try to remember and find one for further discussion. Notably, the > authors seem to focus on particular hardware, and a single link between t= wo > neighbors, for their discussion, unless I missed something. > > > > [RJ] The authors have not merely focused on single link between two > neighbors. The slides of the paper-talk gives a better picture, > https://sing.stanford.edu/site/talks/emnets2006srinivasan.ppt > > > > > > > Regards, > Charlie P. > > > --001a114f4844f0dd5b056205efd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Remy,=C2=A0

Please find my comments = inline.

Regards,
Rahul
p.s. i = feel a voice call will help us better here. Will ping you.

On 25 December 2017 at = 12:44, Liubing (Remy) <remy.liubing@huawei.com> wrote:=

Hi Rahul,

=C2=A0

Please find my comments inline.

=C2=A0

Best regards,

Remy

=C2=A0

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Jadhav
Sent: Wednesday, December 20, 2017 8:11 PM
To: Charlie Perkins <charles.perkins@earthlink.net>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Review of AODV-RPL

=C2=A0

Hello Charlie,

=C2=A0

Please find my respon= se inline..

Regards,

Rahul

=C2=A0

On 15 December 2017 at 20:49, Charlie Perkins <charles.pe= rkins@earthlink.net> wrote:

Hello Rahul,

Thanks for the review!=C2=A0 It is much appreciated.=C2=A0 I have some f= ollow-up below.

=C2=A0

On 11/15/2017 8:57 PM, Rahul Jadhav wrote:=

Following is my review of AODV-RPL.

One of the stated goal of AODV-RPL is to cater to asymmetric links. While t= his is really great to have, I have doubts that the current specification a= chieves it in a practical way. Foll is the reasoning:

  1. The Messaging:

AODV-RPL requires that you send a multicast message from OrigNode to TargNo= de and realise a routing path in the opposite direction.=C2=A0

For e.g. A -> B -> C -> D, A sends a RREQ-Instance message towards= D and nodes B,C,D establish routing adjacencies in the opposite direction.= This kind of messaging is the reason why RPL depends on bidirectional link= s for control/data paths.


It's not just RPL.=C2=A0 A lot of protocols work this way.

=C2=A0

[RJ] But this mode of signaling does not help satisf= y the stated goal of establishing asymmetric links. RPL (and others like p2= p-rpl) follows this mode of signaling and hence depend on bidirectional lin= ks.

[Remy] I think we have a misunderstanding here. =E2= =80=9CBidirectional=E2=80=9D talks about the reachability, while =E2=80=9Cs= ymmetric=E2=80=9D talks about the upward and downward routes. The =E2=80=9C= asymmetric=E2=80=9D here signifies the upward and downward routes between t= he OrigNode and the TargNode are different, while "bidirectional" means cont= rol messages can be received in two directions. Both RPL and AODV-RPL use b= idirectional links.


[RJ] I m not very clear of this text. AODV-RPL canno= t depend on bidirectional links to establish asymmetric paths.=C2=A0=C2=A0<= /div>
<= div>

2. The Assumptions:

a. Quoting draft,=C2=A0

=E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance and= creates a routing table entry for the upstream route towards the=C2=A0source if the routing metrics/constraints are satisfied.=C2=A0 For this purpose R_i ***must use the asymmetric link metric measured= in the upstream direction***, from R_i to its upstream neighbor that multi= casted the RREQ-Instance message.=E2=80=9D

This is the primary assumption which achieves asymmetric behaviour. But it= =E2=80=99s an implementation nightmare to do this measurement especially be= cause we do not know which neighbour we might end up tieing up with (thus n= eed to probe all neighbours).


I don't think this is true.=C2=A0 A node simply has to keep track of th= e information for the upstream destination, and the information about the s= pecific node from which the RREQ was received.

=C2=A0

[RJ] Assuming a moderately populated hop, a node now= needs to keep track of information in context all the peers on the same ho= p. You mentioned, 'node needs to track only upstream destination' .= .. but imo this is not true. For P2P paths, its a different DAG instance and thus there are no pre-determined *upstrea= m destinations*.

[Remy] The upstream= destination is the OrigNode, which is the root of the DODAG. An intermedia= te node only needs to maintain a route entry to the OrigNode, including the= information of the next hop on the upstream route. The next hop is actually the node=E2=80=99s preferred pare= nt in this DODAG.


[RJ] I understand that from the routing table p= erspective only the OrigNode entry has to be established. My point was in c= ontext to identifying/probing adjoining next hop through which this route w= ould be established. For this probing you need to maintain a table which wi= ll have all adjoining peers.

=C2=A0<= /p>

It will add up so much to the control overhead and also requires (a good de= al of) state info to be maintained on behalf of the neighbouring nodes.<= /u>


I don't see why it adds much to the control overhead.=C2=A0 The state c= an be timed out after a relatively small duration of time.=C2=A0 We will ad= d that timeout parameter for the next revision.

=C2=A0

[RJ] The reason for high control overhead is that th= e node will have to keep probing the neighbors to maintain state. The probl= em with smaller duration time is that thhen e probe will be more frequent! = Regardless, the table that needs to be maintained for such information is directly proportional to the number of = neighboring peers.

[Remy] The n= ode doesn=E2=80=99t have to probe all its neighbor. Don=E2=80=99t forget th= at AODV-RPL is an extension of RPL, and the RREP and RREQ are two new DIO o= ptions. Thus the DIO transmission, local repair and many other mechanisms to maintain the state are the same as RPL.=C2=A0 Therefore, the= control overhead will stay the same.


[RJ] I understand that the = DIO transmission, and other factors remain the same. Adding RREP/RREQ on to= p of existing DIO messaging does not achieve asymmetric paths. When OrigNod= e sends a DIO, its received by another node downstream and the path is esta= blished upstream. This is the mechanism RPL follows. Also AODV-RPL follows = the same signalling mechanism and this is where the problem starts with the= asymmetric path claim.=C2=A0

=C2=A0

=C2=A0

=C2=A0



Anyways i tried to search for your implementation to check on this but i co= uld not find it.

b. Use of past conditions to suggest future traffic path selection:<= u>

=E2=80=9CIf the RREQ-Instance arrives over an interface that is not known t= o=C2=A0be symmetri= c, or is known to be asymmetric, the 'S' bit is set to be 0.=E2=80= =9D

This is a typical problem we face as well. Probing for measurements at such= scale (all neighbours) is a problem. If you do the probing sparsely, the n= etwork conditions might have changed when you want to use the measurements.=


Yes, this is naturally a problem in dynamic networks.=C2=A0 We can't pr= edict the future, so we are stuck with recording salient aspects of the pas= t.=C2=A0 No matter how often we measure, it is guaranteed to be wrong some = (or most!) of the time in the future.=C2=A0 And yet we persist.

But we do not require periodic or exhaustive measurements for all neighbors= -- only as needed for the protocol to work.

=C2=A0

[RJ] May be this is the part i don't get ... You= mentioned "only as needed for the protocol to work" ... Can this= be elaborated?

[Remy] Again, it is= still in the framework of RPL, so the probing is done in the same way as R= PL, i.e. by DIO and DIS, which are controlled by the trickle timer.<= /p>

[RJ]: No. Pr= obing cannot be done the same way. In case of RPL, DIO is sent downstream a= nd the downstream nodes use DIO metrics and messaging signal qualities to e= stablish upstream path. This is ok in case of RPL because RPL says that it = depends upon bidirectional connectivity (not necessarily symmetric but stil= l bidirectional for e.g. power levels in both direction might vary but the = messaging still works) for it to work.=C2=A0
Now for AODV-RPL'= ;s asymmetric claim to work, the upstream and downstream paths between the = same pair of nodes can be different. For asymmetric links, AODV-RPL cannot = depend upon RPL's style of DIO messaging.
=C2=A0
=

=C2=A0



Other points:

  1. Use of odd/even numbers for pairing instances may not be a robust way of pa= iring =E2=80=A6 There could be race conditions where other P2P-RPL instance= s or floating DODAG instances end up using one of the same value in the ins= tance-id pair. How to resolve such collision?


But, the instance-ids are local.=C2=A0 So if two different nodes use the sa= me ID that is O.K.=C2=A0 If those two nodes need to have a peer-to-peer rou= te to the same destination, that is still O.K., but the RREP sent back to o= ne of the source nodes will be able to use the paired instance-ID and the streamlined RREP, and the other RREP will h= ave to include an unpaired instance-ID along with the IPv6 address of the t= arget node.=C2=A0 That will be a rare occurrence, and so the optimization o= f eliding the IPv6 address=C2=A0 will usually be possible.

=C2=A0

[RJ] Yeah, for local instances this might not be a p= roblem. Thanks.

=C2=A0<= /p>

  1. I would recommend to use Cooja with links in DGRM mode to evaluate the perf= .


This sounds like a good idea.=C2=A0 The other co-authors will probably have= more follow-up about this.

  1. The RSSI values in the Appendix do not look correct. An RSSI of <-70dbm = is too good [1] to have for good PDR. The mapping of RSSI-ETX in the append= ix hence may not be correct (i believe these values are from Cooja).=


I don't understand how an RSSI could be "too good", unless yo= u mean that the power level is too high and causes widespread interference.= =C2=A0 Admittedly, I am no expert in interpreting PHY layer effects, but an= yway usually higher received power allows more accurate detection, if the background noise level remains the same.

=C2=A0

[RJ] My reference here is to the RSSI to ETX mapping= table in the draft. The values noted in that table do not look correct. Fo= r RSSI -55 to -45dbm, the expected ETX is 993. On what basis was this table= generated ? Typically i have found that RSSI of < -80dbm results in very good PDRs (also the ref i attache= d says the same).

=C2=A0

I'll try to remember and find one for further di= scussion. Notably, the authors seem to focus on particular hardware, and a = single link between two neighbors, for their discussion, unless I missed so= mething.

=C2=A0

=C2=A0

=C2=A0


Regards,
Charlie P.

=C2=A0


--001a114f4844f0dd5b056205efd1-- From nobody Fri Jan 5 11:19:55 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 EBE9E12AF77 for ; Fri, 5 Jan 2018 11:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 CIwvvEBFkZjD for ; Fri, 5 Jan 2018 11:19:50 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 E51F6129C6D for ; Fri, 5 Jan 2018 11:19:49 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id u193so3745027oie.1 for ; Fri, 05 Jan 2018 11:19:49 -0800 (PST) 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 :cc; bh=ruSDClyTIuYQuBh/N6kSuuuq530A7KT8TNZYcTX8nIA=; b=epr6wLsejAq7gQ9+hGOVtWY19hVw7oscXtqtcDkd0OcUICr5bmWraiBceI9gLit0i/ Lm8oD53kOO8CjdnLYsRZLlIU1lQVzkI3SOwtzEwa1PhCZSTSIyuVX+sZeppyby58oOAI KkS3LX7h9MCYSfs/9jyWCdgzV7yoiDdHMRbP0lcVp3h4J3feh+XTDCk8GFK+rRKPYO0E 5KaQXUIZSxH7WRbknSN66dHAGd0CsVG5KqxggJoXpX4+lNtZLHIL+9vtHSqeXJ2mkhB5 VtG3sOVyebtCSGJqcoXo8Em8TZowzvrfO25bvmaRyF99wxGbH3NHI+YrA7vtddt4JJ4N NHcw== 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:cc; bh=ruSDClyTIuYQuBh/N6kSuuuq530A7KT8TNZYcTX8nIA=; b=m04Kd/hZTv1RgzFTeqQPxzTHaL4jepIQXKIq5uE17D3homQZMbz/cmW+dOGPtPQsA6 tKowE2ZByrvZ8Q6wUgmzJlXFjRNL/1kgNcFQIdFTmAPihCsRRFil4dx/q84nF5BJ8oyz 4X9dtbFGnctMpr1hgnp1mEwXNo79Vv0V4nuF+rXsdQEO7MBfUT8d0YDfzsDCkyFr2QgE 3Dbu77gTyHL0Bs6JfkvEqliSEBXlrCQDhc6xre3gnb7BOGY/TJG5to4taOhaCELA3QSs x4Ja7Jswe/ZkLQH5Kbe+M5hnhtkwX6jyt2Ue8yNoii1nQOmIxXlqykOozFzYcusubLD5 X0kg== X-Gm-Message-State: AKGB3mIB+2UyVMkTNt3kcLOAjg9t0E+GGD2J4MCVTihMwpglL+MTbzjY m6Q+JY8vIK5ra5WSAE2hybEP5VjorGcHWOVQgKIImg== X-Google-Smtp-Source: ACJfBosU3lkC1UKUeHzpBblZ7PjkcF8Cbp7337oNzUEy1CwHYUj6WOZeEUHQN+vhTXAo+0VcqaQqWXuHuAiVQTve/gg= X-Received: by 10.202.68.214 with SMTP id r205mr1768408oia.80.1515179989242; Fri, 05 Jan 2018 11:19:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.26.42 with HTTP; Fri, 5 Jan 2018 11:19:48 -0800 (PST) In-Reply-To: References: From: Abdussalam Baryun Date: Fri, 5 Jan 2018 21:19:48 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a113da9b00797fe05620c55e5" Archived-At: Subject: Re: [Roll] Review of AODV-RPL 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: Fri, 05 Jan 2018 19:19:53 -0000 --001a113da9b00797fe05620c55e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rahul On Fri, Jan 5, 2018 at 1:42 PM, Rahul Jadhav wrote: > > [RJ] I m not very clear of this text. AODV-RPL cannot depend on > bidirectional links to establish asymmetric paths. > My understanding: means that any physical link cannot be dependent that it connects two way communication, so we always expect one-way. other protocols assume that any link is bidirectional as two way, so RPL depends on bidirectional links, but AODV-RPL claims that is not. > 2. The Assumptions: >> >> a. Quoting draft, >> >> =E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance = and >> creates a routing table entry for the upstream route towards the source >> if the routing metrics/constraints are satisfied. For this purpose R_i >> ***must use the asymmetric link metric measured in the upstream >> direction***, from R_i to its upstream neighbor that multicasted the >> RREQ-Instance message.=E2=80=9D >> >> This is the primary assumption which achieves asymmetric behaviour. But >> it=E2=80=99s an implementation nightmare to do this measurement especial= ly because >> we do not know which neighbour we might end up tieing up with (thus need= to >> probe all neighbours). >> >> >> I don't think this is true. A node simply has to keep track of the >> information for the upstream destination, and the information about the >> specific node from which the RREQ was received. >> >> >> >> [RJ] Assuming a moderately populated hop, a node now needs to keep track >> of information in context all the peers on the same hop. You mentioned, >> 'node needs to track only upstream destination' ... but imo this is not >> true. For P2P paths, its a different DAG instance and thus there are no >> pre-determined *upstream destinations*. >> >> [Remy] The upstream destination is the OrigNode, which is the root of th= e >> DODAG. An intermediate node only needs to maintain a route entry to the >> OrigNode, including the information of the next hop on the upstream rout= e. >> The next hop is actually the node=E2=80=99s preferred parent in this DOD= AG. >> > > [RJ] I understand that from the routing table perspective only the > OrigNode entry has to be established. My point was in context to > identifying/probing adjoining next hop through which this route would be > established. For this probing you need to maintain a table which will hav= e > all adjoining peers. > why you need the adjoining? > >> >> It will add up so much to the control overhead and also requires (a good >> deal of) state info to be maintained on behalf of the neighbouring nodes= . >> >> >> I don't see why it adds much to the control overhead. The state can be >> timed out after a relatively small duration of time. We will add that >> timeout parameter for the next revision. >> >> >> >> [RJ] The reason for high control overhead is that the node will have to >> keep probing the neighbors to maintain state. The problem with smaller >> duration time is that thhen e probe will be more frequent! Regardless, t= he >> table that needs to be maintained for such information is directly >> proportional to the number of neighboring peers. >> >> [Remy] The node doesn=E2=80=99t have to probe all its neighbor. Don=E2= =80=99t forget that >> AODV-RPL is an extension of RPL, and the RREP and RREQ are two new DIO >> options. Thus the DIO transmission, local repair and many other mechanis= ms >> to maintain the state are the same as RPL. Therefore, the control overh= ead >> will stay the same. >> > > [RJ] I understand that the DIO transmission, and other factors remain the > same. Adding RREP/RREQ on top of existing DIO messaging does not achieve > asymmetric paths. When OrigNode sends a DIO, its received by another node > downstream and the path is established upstream. This is the mechanism RP= L > follows. Also AODV-RPL follows the same signalling mechanism and this is > where the problem starts with the asymmetric path claim. > I agree that the draft needs more explaining of the AODV_RPL mechanism to show that it is not same as RPL. I agree that the draft is not well detailed. > > > > Yes, this is naturally a problem in dynamic networks. We can't predict >> the future, so we are stuck with recording salient aspects of the past. = No >> matter how often we measure, it is guaranteed to be wrong some (or most!= ) >> of the time in the future. And yet we persist. >> >> But we do not require periodic or exhaustive measurements for all >> neighbors -- only as needed for the protocol to work. >> >> >> >> [RJ] May be this is the part i don't get ... You mentioned "only as >> needed for the protocol to work" ... Can this be elaborated? >> > [Remy] Again, it is still in the framework of RPL, so the probing is done >> in the same way as RPL, i.e. by DIO and DIS, which are controlled by the >> trickle timer. >> > [RJ]: No. Probing cannot be done the same way. In case of RPL, DIO is sen= t > downstream and the downstream nodes use DIO metrics and messaging signal > qualities to establish upstream path. This is ok in case of RPL because R= PL > says that it depends upon bidirectional connectivity (not necessarily > symmetric but still bidirectional for e.g. power levels in both direction > might vary but the messaging still works) for it to work. > Now for AODV-RPL's asymmetric claim to work, the upstream and downstream > paths between the same pair of nodes can be different. For asymmetric > links, AODV-RPL cannot depend upon RPL's style of DIO messaging. > > AODV-RPL has different messages, so it is different style to establish path= s > >> >> >> >> >> >> > > --001a113da9b00797fe05620c55e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rahul

On Fri, Jan 5, 2018 at 1:42 PM, Rahul Jadhav <rahu= l.ietf@gmail.com> wrote:

[RJ] I m not very clear of this tex= t. AODV-RPL cannot depend on bidirectional links to establish asymmetric pa= ths.=C2=A0=C2=A0

<= div>My understanding:=C2=A0=C2=A0 means that any=C2=A0physical link cannot = be dependent that it connects two way communication, so we always expect on= e-way.=C2=A0other protocols assume that any link=C2=A0is bidirectional as t= wo way, so RPL depends on bidirectional links, but AODV-RPL claims that is = not.
=C2=A0
<= div>

2. The Assumptions:

a. Quoting draft,=C2=A0

=E2=80=9CEach intermediate node R_i computes the rank for RREQ-Instance and= creates a routing table entry for the upstream route towards the=C2=A0so= urce if the routing metrics/constraints are satisfied.=C2=A0 For this purpose R_i ***must use the asymmetric link metric measured= in the upstream direction***, from R_i to its upstream neighbor that multi= casted the RREQ-Instance message.=E2=80=9D

This is the primary assumption which achieves asymmetric behaviour. But it= =E2=80=99s an implementation nightmare to do this measurement especially be= cause we do not know which neighbour we might end up tieing up with (thus n= eed to probe all neighbours).


I don't think this is true.=C2=A0 A node simply has to keep track of th= e information for the upstream destination, and the information about the s= pecific node from which the RREQ was received.

=C2=A0

[RJ] Assuming a moderately populated hop, a node now= needs to keep track of information in context all the peers on the same ho= p. You mentioned, 'node needs to track only upstream destination' .= .. but imo this is not true. For P2P paths, its a different DAG instance and thus there are no pre-determined *upstrea= m destinations*.

[Remy] The upstream d= estination is the OrigNode, which is the root of the DODAG. An intermediate= node only needs to maintain a route entry to the OrigNode, including the i= nformation of the next hop on the upstream route. The next hop is actually the node=E2=80=99s preferred pare= nt in this DODAG.


[RJ] I understand that from the routing = table perspective only the OrigNode entry has to be established. My point w= as in context to identifying/probing adjoining next hop through which this = route would be established. For this probing you need to maintain a table w= hich will have all adjoining peers.

why you need the adjoining?
=C2=A0

<= span style=3D"font-size:11pt">

=C2=A0

It will add up so much to the control overhead and also requires (a good de= al of) state info to be maintained on behalf of the neighbouring nodes.<= /u>


I don't see why it adds much to the control overhead.=C2=A0 The state c= an be timed out after a relatively small duration of time.=C2=A0 We will ad= d that timeout parameter for the next revision.

=C2=A0

[RJ] The reason for high control overhead is that th= e node will have to keep probing the neighbors to maintain state. The probl= em with smaller duration time is that thhen e probe will be more frequent! = Regardless, the table that needs to be maintained for such information is directly proportional to the number of = neighboring peers.

[Remy] T= he node doesn=E2=80=99t have to probe all its neighbor. Don=E2=80=99t forge= t that AODV-RPL is an extension of RPL, and the RREP and RREQ are two new D= IO options. Thus the DIO transmission, local repair and many other mechanisms to maintain the state are the same as RPL.=C2=A0 Therefore, the= control overhead will stay the same.


[RJ] I understand th= at the DIO transmission, and other factors remain the same. Adding RREP/RRE= Q on top of existing DIO messaging does not achieve asymmetric paths. When = OrigNode sends a DIO, its received by another node downstream and the path = is established upstream. This is the mechanism RPL follows. Also AODV-RPL f= ollows the same signalling mechanism and this is where the problem starts w= ith the asymmetric path claim.

I agree that the draft needs more explaining of the AODV_= RPL mechanism to show that it is not same as RPL. I agree that the draft is= not well detailed.
=C2=A0
=C2=A0


Yes, this is naturally a problem in dynamic networks.=C2=A0 We can&#= 39;t predict the future, so we are stuck with recording salient aspects of = the past.=C2=A0 No matter how often we measure, it is guaranteed to be wron= g some (or most!) of the time in the future.=C2=A0 And yet we persist.

But we do not require periodic or exhaustive measurements for all neighbors= -- only as needed for the protocol to work.

=C2=A0

[RJ] May be this is the part i don't get ... You= mentioned "only as needed for the protocol to work" ... Can this= be elaborated?

=

[Remy] Again, it is s= till in the framework of RPL, so the probing is done in the same way as RPL= , i.e. by DIO and DIS, which are controlled by the trickle timer.

[RJ]: N= o. Probing cannot be done the same way. In case of RPL, DIO is sent downstr= eam and the downstream nodes use DIO metrics and messaging signal qualities= to establish upstream path. This is ok in case of RPL because RPL says tha= t it depends upon bidirectional connectivity (not necessarily symmetric but= still bidirectional for e.g. power levels in both direction might vary but= the messaging still works) for it to work.=C2=A0
Now for AODV-RP= L's asymmetric claim to work, the upstream and downstream paths between= the same pair of nodes can be different. For asymmetric links, AODV-RPL ca= nnot depend upon RPL's style of DIO messaging.
=C2=A0
AODV-RPL has different= messages, so it is different style to establish paths

=C2=A0





=

=

<= div>

<= /div>

<= div class=3D"m_167389544047706067m_-6746785207879470708WordSection1">
=


<= /div>

--001a113da9b00797fe05620c55e5-- From nobody Fri Jan 5 12:04:29 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 51F6812D872; Fri, 5 Jan 2018 12:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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 ZTiet1shsxjW; Fri, 5 Jan 2018 12:04:14 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 62EFE12D882; Fri, 5 Jan 2018 12:04:14 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id w125so3806369oie.7; Fri, 05 Jan 2018 12:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=84hq0Py50i8Na8WGqUu/RIl6XsoFDegNPUfGuWqaWR8=; b=XfGDez7LyU72H51HBC02AWmeaDWcWQTJAgMGM0VLpPZZoaffM4ozbsWZnvXhB2jGnJ EYSf12g+UW2hQagBl22Z3GW1p8a0R+zFdX1sfJiLw3NeWRDSpGaZYuO3tM6KjxDqXKn2 ayTLPzpIkM6E+KIbyOvZXZhaGTVIOueIc4besEiayulAXM/Yhzo6ItoI5mmrwuFfmKNy YjWzasbkuvjUIDX79+9npDXerOrUwTf3myMYu1yr4YYvqdxQIHaj4wzrqWr6auq2IdFB Ik2oxAAQH8hrxxQRkb8AIcdyaTsejkVtqojq0T63UF/DjQYRChoCIrV4efc20LMDH+rm J21Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=84hq0Py50i8Na8WGqUu/RIl6XsoFDegNPUfGuWqaWR8=; b=CHYG7MYz9Y2jXyCb1qegK9SbWxyzBsLClxzxySaXsTgVtQ2x6jmabSQMOWtOx4kF67 33qfEZKxgHySaTLlOVzIpQJALSZnVB6ptulahlTiuW2yewU677CY6/fNFNP9hObeQOac ijqdVnsKkmkX2EVCOByvsEGSxN27kPWGbttvOwSVO16rNzZGaheTdGFoRBWKCOQSKiah BQBPpztk5y3CkNeyYC+yF02xP/FbpsZrbZbKPM3q8gN/aP/bz00mh88RVnjUgidEN48s 2EqXhWEJiliItzwGGuO3i3pAXZaYHI/GoP+Il0iXexH3vQpK3ZvmOPzs18YPQiGCpmwa S+1A== X-Gm-Message-State: AKwxytcqhWuFrsXTPofrKiGYQEkVK6Vv4UdZKfxtTjvAk646EcLPxlNh SerQbEy26mW8xX7P5hRew4xDQJU0V1XZYvd0rjVDbg== X-Google-Smtp-Source: ACJfBotezZCb5frO3AP8gmLRnlxj7H5To/Drn3/4h3GvsZ/G6U+pERP/al0nzdFXqmckHGRYtcroQPl/fK7BxI3rO4g= X-Received: by 10.202.66.8 with SMTP id p8mr2032127oia.65.1515182653538; Fri, 05 Jan 2018 12:04:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.26.42 with HTTP; Fri, 5 Jan 2018 12:04:13 -0800 (PST) From: Abdussalam Baryun Date: Fri, 5 Jan 2018 22:04:13 +0200 Message-ID: To: roll , draft-ietf-roll-aodv-rpl@ietf.org Content-Type: multipart/alternative; boundary="001a113dd334d584fa05620cf351" Archived-At: Subject: [Roll] Comments for AODV-RPL protocol 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: Fri, 05 Jan 2018 20:04:22 -0000 --001a113dd334d584fa05620cf351 Content-Type: text/plain; charset="UTF-8" Hi WG, The abstract needs to delete any indication that this is a routing protocol. IMHO, this is a route discovery for the RPL protocol. The discovery of route is part of the routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to mention if this AODV-RPL can work with RPL or not in the same network. IMO, the draft needs to describe the neighbor discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or the draft shows the difference from RFC6650 discovery. Please refer to sections in RFC6550 RPL. AODV-RPL instance are another type of RPL-Instances, so why you write the AODV instance. Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL instances or this AODV-RPL instance defined as RPL instance. Delete the writing words 'AODV routing' from the draft, and delete AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV is already well known. IMO the operation mode is not used correctly, we need to identify the protocol not by the MoP, we will use them all then, it should be reserved for network operations not for protocols. IMHO, the Message format of dio is not correct needs to have type then the length format as shown in the dio format specification rfc6550. IMO, this protocol Sequence number is not different than the sequence number of destination mentioned in RFC6550. You must include the DTSN in this draft. If you thinks I am wrong please mention why here and then it should be clear what is the different than RPL in the draft? Security section needs to include rfc6552/rfc6553 I suggest to delete future work section. Best Regards AB --001a113dd334d584fa05620cf351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi WG,

= The abstract needs to delete any indication that this is a= routing protocol. IMHO, this is a route discovery for the RPL protocol.

The discovery of route is part of th= e routing protocol so we have a different routing which is AODV-RPL routing protocol. The draft needs to me= ntion if this AODV-RPL can work with RPL or not in the same network.=

IMO, the draft needs to describe the neighbo= r discovery combined with AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 18.6 in rfc6550. Or= =C2=A0the draft shows the difference from RFC6650 discovery. Please refer t= o sections in RFC6550 RPL.=C2=A0

<= /span>AODV-RPL instance are another type of RPL-Ins= tances, so why you write the AODV instance. Please note that this will conflict with MANET routing instances. Please delete AODV instance. This draft needs to have only RPL i= nstances or this AODV-RPL instance defined as RPL instance.

Delete the writing words 'AODV routing&#= 39; from the draft, and=C2=A0delete AODV reference as the IPv4-RFC mentione= d (can be confusing). The AODV is already well known.

IMO the operation mode is not used correctly= , we need to identify the protocol=C2=A0not by the MoP, we will use them all then, it should be reser= ved for network operations not for protocols.

IMHO, the Message format of dio is not correct needs to have type then the length format as s= hown in the dio format specification rfc6550.

IMO, this protocol Sequence number is not different than the sequence number of destination mentioned i= n RFC6550. You must include the DTSN in this draft. If you thinks I am= wrong please mention why here and then it should be clear what is the diff= erent than RPL=C2=A0in the draft?

Security section needs to include rfc6552/rf= c6553

I suggest to delete future work section.


Best Regards

<= font color=3D"#000000">AB

--001a113dd334d584fa05620cf351-- From nobody Fri Jan 5 12:43:24 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 20ED2127873 for ; Fri, 5 Jan 2018 12:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 MXo6cuOQws7o for ; Fri, 5 Jan 2018 12:43:21 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 8E3641201F2 for ; Fri, 5 Jan 2018 12:43:21 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id x15so4912632ote.0 for ; Fri, 05 Jan 2018 12:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4rPQIaNlBH1urQNdRJPOY5/1fFJ0Z3BrvLrv5dbOQ1E=; b=YRFBd5uKSPCY1kpM4w99L9ANvB8PyRRSpaF203O2b3p3ur0FXqhyH5k/fzo6sxHBsU u3FFbiXQUcLPjVm8vmAcAh3ltyFn/JWlZbdZhwUxnTrj90IOuDlyK72vGkP8vZqIfn6B gemu5yr88cYfZ0W/5fkU7ZbcfT6BfbV6Fb6IKuT5PFRQiTEZETJzFyuudLMo5XP1IIHl oPiWu3gT6Zz4a1hNjhmICq9Ed2WGUkfBg8UllhkIYdGn911Zc0pmKEpzHCBuzp2tKd/c +Xvoho0WdyxGs68/sKGh9it1yJgFkuzAcDwI9A6zsbeCUU8wsriqOfShQ4Y9m8byytBp qnAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4rPQIaNlBH1urQNdRJPOY5/1fFJ0Z3BrvLrv5dbOQ1E=; b=nxqm4j4Q+K8K6GCv+L/1ZYGHD+MMy+oYjRPHZJcHAbK7NQ+TSAWAXJrlvTd0nksf+O RK1auTtSwUGCmHjwi/8qiUV7FUuMFS+0ggrtjIMi7P1DVMtZW7HX+kTTYZqr491BDQL7 Gd9X5JH/BMnbQ5zcSMuHpkqoxtdGVlzRUXSoVcUU8Kr5vUwhjlx9c35QTXui2qsxYFYk JSdJELtScGYXjFcJQev0jz3rCMW0WVDoTTi75PDES/2+3QOWbwZrq+6px4d8TWX4SHWL aDpU+37O03xxoQy+/D1AeOpedpwp9Kyzueir7hR8fO+Vo1yA7xvYt8M0RrwdCvt+T55U LYPg== X-Gm-Message-State: AKwxytf9US/7P6B0b1J/2XWhby6J+r94Qe43/plGVn6BYrlp3urAhAL8 DkpuSv410/0Np3/8SCGnCy5yUhLcmssMVRxWIx8= X-Google-Smtp-Source: ACJfBouZK2e+LNH5yF6HjduFVm2yauvBaB43I03RVcnwxSrmChjV00yg98MLgLCttLx0fqFkEjCI1OH0nWPCsQ/qnSw= X-Received: by 10.157.10.133 with SMTP id 5mr2498567otq.51.1515185000881; Fri, 05 Jan 2018 12:43:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.26.42 with HTTP; Fri, 5 Jan 2018 12:43:20 -0800 (PST) From: Abdussalam Baryun Date: Fri, 5 Jan 2018 22:43:20 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="94eb2c0352d6bf218105620d7fcb" Archived-At: Subject: [Roll] Is MoP from (0 to 7) enough network operation modes, or is enough? 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: Fri, 05 Jan 2018 20:43:23 -0000 --94eb2c0352d6bf218105620d7fcb Content-Type: text/plain; charset="UTF-8" In my opinion we use this MoP for the network operation not for discovery operations. In RFC6997 registered 4, which is discovery on demand extension for RPL. I think it will not make enough use for more important operations related to networks of LLN requirements. Routing protocols have two parts: route discovery and route operation/maintenance, I think if we change the RPL operation or change the network capability, then use MoP as done for 0, 1, 2, 3 registrations. We need to make sure we look into answering for our LLN use cases (RFC5548, RFC5673, RFC5826) are they covering most of our MoP operations??? AB --94eb2c0352d6bf218105620d7fcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my opinion we use this MoP for the network operati= on not for discovery operations. In RFC6997 registered 4, which is discover= y on demand extension for RPL. I think it will not make enough use for=C2= =A0more important=C2=A0operations related to networks of LLN requirements.<= /div>

Routing protocols have two parts: route discovery = and route operation/maintenance, I think if=C2=A0we change the RPL operatio= n or change the network capability, then use MoP=C2=A0as done for 0, 1, 2, = 3 registrations.

We need to make sure we look int= o answering for our=C2=A0LLN use cases (RFC5548, RFC5673, RFC5826)=C2=A0 ar= e they covering most of our MoP operations???

AB
--94eb2c0352d6bf218105620d7fcb-- From nobody Mon Jan 8 23:14:51 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 7E2FC127201 for ; Mon, 8 Jan 2018 23:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 2q1Fc6KxZdqm for ; Mon, 8 Jan 2018 23:14:48 -0800 (PST) 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 8CFE912421A for ; Mon, 8 Jan 2018 23:14:48 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id B148923836F4 for ; Tue, 9 Jan 2018 07:14:44 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 9 Jan 2018 07:14:45 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Tue, 9 Jan 2018 15:14:38 +0800 From: "Liubing (Remy)" To: "roll@ietf.org" Thread-Topic: Comments on storing mode of AODV-RPL Thread-Index: AdOJFhJXht1pQvGbRbmmF9Muddhsow== Date: Tue, 9 Jan 2018 07:14:38 +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] Comments on storing mode of AODV-RPL 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, 09 Jan 2018 07:14:50 -0000 Hello AODV-RPL authors, I find that the terminology "storing mode" used in the draft is not accurat= e.=20 The storing/non-storing mode is for downward route only, i.e. the route fro= m the DODAG root to leaf nodes. In AODV-RPL, the "downward route" from the = OrigNode to the TargNode is actually built by discovering an "upward route"= in a second DODAG rooted at the TargNode. Therefore, the OrigNode-to-TargN= ode route and the TargNode-to-OrigNode route are both upward routes. Thus t= hey are not storing mode or non-storing mode. I suggest to use "hop-by-hop route" to replace "storing mode" in the draft.= If you plan to develop a mechanism, in which the intermediate routers don'= t build route entries, you can use the terminology ''source routing".=20 Best regards, Remy From nobody Tue Jan 9 06:12:58 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 2C0A512D867 for ; Tue, 9 Jan 2018 06:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 e1ubceqsRRah for ; Tue, 9 Jan 2018 06:12:55 -0800 (PST) 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 A2F41128961 for ; Tue, 9 Jan 2018 06:12:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 636B420091 for ; Tue, 9 Jan 2018 09:17:47 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C110083673 for ; Tue, 9 Jan 2018 09:12:54 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: 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] Comments on storing mode of AODV-RPL 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, 09 Jan 2018 14:12:57 -0000 --=-=-= Content-Type: text/plain Liubing (Remy) wrote: > Hello AODV-RPL authors, > I find that the terminology "storing mode" used in the draft is not accurate. > The storing/non-storing mode is for downward route only, i.e. the route > from the DODAG root to leaf nodes. In AODV-RPL, the "downward route" > from the OrigNode to the TargNode is actually built by discovering an > "upward route" in a second DODAG rooted at the TargNode. Therefore, the > OrigNode-to-TargNode route and the TargNode-to-OrigNode route are both > upward routes. Thus they are not storing mode or non-storing mode. > I suggest to use "hop-by-hop route" to replace "storing mode" in the > draft. If you plan to develop a mechanism, in which the intermediate > routers don't build route entries, you can use the terminology ''source > routing". As a new MODP is assigned by the document, it seems like the document should perhaps create a more descriptive/interesting name for the MODP and to use that term throughout the document. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlpUzeYACgkQgItw+93Q 3WWUcwgAl6h56VczylH7prcjJIs01k0HMw0F7slHAVGrl+EMjvvYH2fLtD7P5Z0M e1KBDUeejpHZPbHtdTFc+bq+wNrq6PxBm1y02iO8dziEcdEb56CgWh7aaO5dipcJ HCVj3Ism1YnngGWqcK7tiOy8pKdAIVCzQYqgnTVvelu2q6hgZP+9a4RqnHJDrScZ XQgO1MzTVwwTYiec3wz2fozaIl6PnYky6/C/QmLDRGUjX9tyTzYlfxCpUj8RDbL+ fmu64mY3UdEnxrpU9xIYvase4S3rdY1uA2a3LH5P2nsIm0R/vyvDX/Qamwel/1Qe Z/WamoZFlllHABzH5p+8fx2u4bSooA== =O1mv -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jan 11 08:59:16 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 764EF12D88C for ; Thu, 11 Jan 2018 08:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 Pd-4s_bzd8Fq for ; Thu, 11 Jan 2018 08:59:12 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A79F12D874 for ; Thu, 11 Jan 2018 08:59:12 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id CB9987B2 for ; Thu, 11 Jan 2018 17:59:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1515689950; bh=N1TrEdH+kpnA1M/gIJNuYqEgVI8riUaif8rQ2CkLRZ0=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=mj8+Dqe2I8act4C0zdn4Ho8xc/fiaSgPC7FQisqWfOMlsVg5i8ilVobAhB3FSxk6A wp3DryY0Z/qRn68arSVzmnXQBj/dlV4F22TUfmZ71CEs0maZ5x3/XfSXvAm28+IEzk oOPAgJWVxKBaihjoeT2NUhxIU9gNdVKkkqhuwSrGV5jQ+LWTZG0GR3QRGGAMfLHo5w QutGuKotZn8q3zSyliqzwo9S04CtJpcQPjumS2NzL8I4bGE6GlCUhjSDH7xAiPTlxl Qo2eqXLtOgsNrE8d0lDwehVQrIHzttLgx/syfbvnZSuvjwn+JvFkv7zJqsEgrdCPb3 u8TYzcsl+u5JA== Received: from mail-qt0-f169.google.com ([209.85.216.169]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Thu, 11 Jan 2018 17:59:05 +0100 (CET) Received: by mail-qt0-f169.google.com with SMTP id g10so2613983qtj.12 for ; Thu, 11 Jan 2018 08:59:05 -0800 (PST) X-Gm-Message-State: AKwxytdadnbi4XUO6R6pOmCJyTcOBdC2VyP/4DSUcCEvpasFhc+AfqZC aW6R5AozdQPceZwlqXgoXrL++Ur81aU2gK8fNcU= X-Google-Smtp-Source: ACJfBou1k4bfKJEa1QJeCDIpKMsRCvf5xB66PCPqlAhCajWglHTxJrIIffxPu4kMBMlP9sVXOXWDpNz8S41aHpzvUrc= X-Received: by 10.237.47.228 with SMTP id m91mr32905911qtd.297.1515689942522; Thu, 11 Jan 2018 08:59:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.150.163 with HTTP; Thu, 11 Jan 2018 08:58:41 -0800 (PST) In-Reply-To: References: From: Remous-Aris Koutsiamanis Date: Thu, 11 Jan 2018 17:59:07 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: "Houjianqiang (Derek)" Cc: "georgios.papadopoulos@imt-atlantique.fr" , roll Content-Type: multipart/alternative; boundary="94eb2c12522a9d3a850562831022" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] About the flags of metric container in draft-pkm-roll-nsa-extension 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, 11 Jan 2018 16:59:15 -0000 --94eb2c12522a9d3a850562831022 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Derek, thank you very much for the nice comments and the pointer. They are very much appreciated. I was away on vacations, hence my delayed response. I will answer inline to your comments. On Fri, Dec 22, 2017 at 10:35 AM, Houjianqiang (Derek) wrote: > Dear Remous-Aris and Georgios, > > > > Thanks for bringing your draft =E2=80=9Cdraft-pkm-roll-nsa-extension=E2= =80=9D into roll > WG. It=E2=80=99s a very interesting work and hope it could be adopted in = this WG. > > > > The recent discussion with Chenyang triggers my interest to read this > draft again. Below are my comments. > > > > It seems that your NSA metric is locally used. I mean one node includes > its potential parents into NSA and sends this NSA down to its potential > children. > Yes, you are correct. We should say this explicitly to avoid confusion. > If this is correct, then it would be good to specify the parameters used > in the Metric Container (P,C, O, R ,A, Prec fields). > You are correct, of course. We intend to do that in a next version. > (PS: there are two =E2=80=98A=E2=80=99 and two =E2=80=98O=E2=80=99 bits i= n Figure 3 of your draft=E2=80=A6) > Yes, it is unfortunate and we need to clarify that. "Figure 3: DAG Metric Container data with Node State and Attribute (NSA) object body and a TLV" has the fields of *both* the DAG MC and the NSA object, an it so happens that both have fields named "A" and "O". Thanks for pointing this out! > I suggest this because I find that to meet the NSA function you want, we > may need to extend the usage of Metric defined in RFC6551. What RFC6551 > bother me are the =E2=80=98R=E2=80=99 flag and =E2=80=98A=E2=80=99 field = in the MC. When NSA is used as a > metric, R=3D1 indicates that the NSA is recorded along the path; R=3D0 > indicates the NSA metric is aggregated (this aggregation could be additiv= e, > multiplicative, reports a maximum or minimum according to the =E2=80=98A= =E2=80=99 field). I > suppose the NSA metric requires to be used locally, not aggregation or > recorded along the path. I guess the =E2=80=98P=E2=80=99 flag may help to= solve this issue > or we may need a new flag in the MC to indicate a locally used metric. > I agree with your interpretation of the semantics of the 'R' and 'A' field; it does not seem to be possible to express a non-aggregated *and* non-recorded-along-the-path metric. For our purposes, we could just use the "Parent Node Set" TLV within the NSA where the NSA is used as a *constraint* instead of as a metric. Aggregation and recording-along-the-path do not apply for constraints per the spec and thus there is no need to interpret the "R" and "A" fields. > > > I am involved in draft =E2=80=9CLoad Balancing Objective Function in RPL= =E2=80=9D and I > have similar concern when setting the flags in the metric container for t= he > proposed Child Node Count (CNC) metric. We also want the CNC to be used > locally, and it seems we need to extend the current metric usage in > RFC6551. > I am aware of your work and I agree that if you want to use the CNC as a metric of we wanted to use the Parent Node Set in the NSA as a metric, then yes, i think the spec does not cover this usage. > The same requirement may appear in Chenyang=E2=80=99s draft =E2=80=9CTraf= fic-aware > Objective Function=E2=80=9D. > Yes, you are correct, there's the same issue there. > > > And one more thing. I find with your proposed NSA that includes parent > address(es), we don=E2=80=99t need to insert the parent address into our = CNC > metric. This greatly simplifies our solution. That=E2=80=99s good! > I'm happy that there seems to be some overlap in our solutions. It will be nice to find a way of separating concerns so that effort is not duplicated. > > > Best regards, > > Derek Jianqiang Hou > > > > Related drafts: > > https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ > > https://datatracker.ietf.org/doc/rfc6551/ > > https://datatracker.ietf.org/doc/draft-qasem-roll-rpl-load-balancing/ > > https://datatracker.ietf.org/doc/draft-ji-roll-traffic- > aware-objective-function/ > Sincerely, Remous-Aris Koutsiamanis --94eb2c12522a9d3a850562831022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Derek,

thank you very much for the= nice comments and the pointer. They are very much appreciated.
I was a= way on vacations, hence my delayed response. I will answer inline to your comments.<= br>

On Fri, Dec 22= , 2017 at 10:35 AM, Houjianqiang (Derek) <houjianqiang@huawei.com> wrote:

Dear Remous-Aris and Georgios,

=C2=A0

Thanks for bringing your draft =E2=80=9Cdraft-pkm-ro= ll-nsa-extension=E2=80=9D into roll WG. It=E2=80=99s a very interesting wor= k and hope it could be adopted in this WG.

=C2=A0

The recent discussion with Chenyang triggers my inte= rest to read this draft again. Below are my comments.

=C2=A0

It seems that your NSA metric is locally used. I mea= n one node includes its potential parents into NSA and sends this NSA down = to its potential children.


Yes, you are correct. We should say this explicitly to avoid confusion.
=C2=A0
<= div lang=3D"EN-US">
=

If this is correct, then it would be good to specify= the parameters used in the Metric Container (P,C, O, R ,A, Prec fields).

<= br>
You are correct, of course. We intend to do that in a next ve= rsion.
=C2=A0

(PS: there are two =E2=80=98A=E2=80=99 and = two =E2=80=98O=E2=80=99 bits in Figure 3 of your draft=E2=80=A6)

=

Yes, it is unfortunate and we need t= o clarify that. "Figure 3: DAG Metric Container data with Node State a= nd Attribute (NSA) object body and a TLV" has the fields of *both* the DAG MC an= d the NSA object, an it so happens that both have fields named "A"= ; and "O". Thanks for pointing this out!
=C2=A0

I suggest this because I find that to meet the NSA function you want, we m= ay need to extend the usage of Metric defined in RFC6551. What RFC6551 both= er me are the =E2=80=98R=E2=80=99 flag and =E2=80=98A=E2=80=99 field in the M= C. When NSA is used as a metric, R=3D1 indicates that the NSA is recorded a= long the path; R=3D0 indicates the NSA metric is aggregated (this aggregati= on could be additive, multiplicative, reports a maximum or minimum accordin= g to the =E2=80=98A=E2=80=99 field). I suppose the NSA metric requires to be= used locally, not aggregation or recorded along the path. I guess the =E2= =80=98P=E2=80=99 flag may help to solve this issue or we may need a new fla= g in the MC to indicate a locally used metric.


I agree with= your interpretation of the semantics of the 'R' and 'A' fi= eld; it does not seem to be possible to express a non-aggregated *and* non-= recorded-along-the-path metric. For our purposes, we could just use the &qu= ot;Parent Node Set" TLV within the NSA where the NSA is used as a *constraint* i= nstead of as a metric. Aggregation and recording-along-the-path do not appl= y for constraints per the spec and thus there is no need to interpret the &= quot;R" and "A" fields.
=C2=A0

=C2=A0

I am involved in draft =E2=80=9CLoad Balancing Objec= tive Function in RPL=E2=80=9D and I have similar concern when setting the f= lags in the metric container for the proposed Child Node Count (CNC) metric= . We also want the CNC to be used locally, and it seems we need to extend the current metric usage in RFC6551.


I am aware of your work and I agree tha= t if you want to use the CNC as a metric of we wanted to use the Parent Node Set in t= he NSA as a metric, then yes, i think the spec does not cover this usage. <= br>
=C2=A0

The same requirement may appear in Chenyang=E2=80= =99s draft =E2=80=9CTraffic-aware Objective Function=E2=80=9D.


Yes, you are correct, ther= e's the same issue there.

=C2=A0

And one more thing. I find with your proposed NSA th= at includes parent address(es), we don=E2=80=99t need to insert the parent = address into our CNC metric. This greatly simplifies our solution. That=E2= =80=99s good!


I'm happy that there seems to be some overlap in our solutions. It wil= l be nice to find a way of separating concerns so that effort is not duplic= ated.
=C2=A0

--94eb2c12522a9d3a850562831022-- From nobody Thu Jan 11 09:13:06 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 6076412D948 for ; Thu, 11 Jan 2018 09:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 1Gb80kB1WMgy for ; Thu, 11 Jan 2018 09:13:02 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C90C12D947 for ; Thu, 11 Jan 2018 09:13:02 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id E688D7B4 for ; Thu, 11 Jan 2018 18:13:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1515690780; bh=Bc4lQ9FbpeAxVYg2mA8Akk6iTSxL4wNfnWVUGQ/UGPI=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=dJDn5na44UO4aZKgQXFdYpxJPqr9TfqbfdhAU2YS/Vi4TjKoLBAfFXuZ6pZBeoQO+ quyE9kZdA12Pnt0R71L2hg7ksK7IhzllgrglODy7AzxBAfS1bkrzL79U24H+UMzsaW fL5eYPmou6RMp7wDsXfFB0Cj85QonChpTqgezWdFx4Y3MoXmJwSOyEaxe2yjJZJ/pQ UvTQmsYMGpQxCwR8INqu8IVoScliTFY35fjFNchRLjYrCcRHaytQaNCEqE9A0vvhmT R9TlrYNPxoukeX9UwUlVcNuoo5dPdxzsprD3SlMoupRoPuK4XxMETI9W/vQa0Fa3VU kFvnhcsyXNL+w== Received: from mail-qt0-f178.google.com ([209.85.216.178]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Thu, 11 Jan 2018 18:12:55 +0100 (CET) Received: by mail-qt0-f178.google.com with SMTP id u10so2666465qtg.2 for ; Thu, 11 Jan 2018 09:12:55 -0800 (PST) X-Gm-Message-State: AKwxytdIgRk9dU08xFIPZJoVcPIfCzqeHXfgpYginuoGzQ4AXVzkilUR Qe6zWpLu80MSS4emFpYkPfYJM4MXuTGMRR3CT9c= X-Google-Smtp-Source: ACJfBosKVTZy+1igGt4almQEMacX/2ddjmbq9kJG4jwt9yIEyu4TNiqY7gMdAuU2Um2DEUw1wXVPALdb+1+N6VwpiAo= X-Received: by 10.237.47.228 with SMTP id m91mr32973012qtd.297.1515690773115; Thu, 11 Jan 2018 09:12:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.150.163 with HTTP; Thu, 11 Jan 2018 09:12:32 -0800 (PST) In-Reply-To: References: From: Remous-Aris Koutsiamanis Date: Thu, 11 Jan 2018 18:12:58 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: "Houjianqiang (Derek)" Cc: "georgios.papadopoulos@imt-atlantique.fr" , roll Content-Type: multipart/alternative; boundary="94eb2c12522a1effb805628342ff" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] About the flags of metric container in draft-pkm-roll-nsa-extension 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, 11 Jan 2018 17:13:04 -0000 --94eb2c12522a1effb805628342ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi again, thanks for another idea. I looked into it and it seems that it allows zero or one parent address (0 is on storing mode, 1 in non-storing mode). So for us this wouldn't do. Also, the "Transit Information" option has so,e specific usage with the "RPL Target" option preceding it, so it might be too complicated to define different behaviours based on whether it is in DIO or DAO. But thanks for the idea anyway. It has gotten me thinking about alternative ways of accomplishing the same thing easier. Best, Remous-Aris On Sat, Dec 23, 2017 at 2:58 AM, Houjianqiang (Derek) < houjianqiang@huawei.com> wrote: > Another idea for your consideration. The =E2=80=9CTransit Information=E2= =80=9D in the DAO > Option contains parent address(es). What about enabling the use of Transi= t > Information in the DIO Option field? > > > > Derek > > > > *From:* Houjianqiang (Derek) > *Sent:* Friday, December 22, 2017 5:35 PM > *To:* 'aris@ariskou.com' ; 'georgios.papadopoulos@imt- > atlantique.fr' > *Cc:* roll > *Subject:* About the flags of metric container in > draft-pkm-roll-nsa-extension > > > > Dear Remous-Aris and Georgios, > > > > Thanks for bringing your draft =E2=80=9Cdraft-pkm-roll-nsa-extension=E2= =80=9D into roll > WG. It=E2=80=99s a very interesting work and hope it could be adopted in = this WG. > > > > The recent discussion with Chenyang triggers my interest to read this > draft again. Below are my comments. > > > > It seems that your NSA metric is locally used. I mean one node includes > its potential parents into NSA and sends this NSA down to its potential > children. If this is correct, then it would be good to specify the > parameters used in the Metric Container (P,C, O, R ,A, Prec fields). (PS: > there are two =E2=80=98A=E2=80=99 and two =E2=80=98O=E2=80=99 bits in Fig= ure 3 of your draft=E2=80=A6) I suggest > this because I find that to meet the NSA function you want, we may need t= o > extend the usage of Metric defined in RFC6551. What RFC6551 bother me are > the =E2=80=98R=E2=80=99 flag and =E2=80=98A=E2=80=99 field in the MC. Whe= n NSA is used as a metric, R=3D1 > indicates that the NSA is recorded along the path; R=3D0 indicates the NS= A > metric is aggregated (this aggregation could be additive, multiplicative, > reports a maximum or minimum according to the =E2=80=98A=E2=80=99 field).= I suppose the NSA > metric requires to be used locally, not aggregation or recorded along the > path. I guess the =E2=80=98P=E2=80=99 flag may help to solve this issue o= r we may need a > new flag in the MC to indicate a locally used metric. > > > > I am involved in draft =E2=80=9CLoad Balancing Objective Function in RPL= =E2=80=9D and I > have similar concern when setting the flags in the metric container for t= he > proposed Child Node Count (CNC) metric. We also want the CNC to be used > locally, and it seems we need to extend the current metric usage in > RFC6551. The same requirement may appear in Chenyang=E2=80=99s draft =E2= =80=9CTraffic-aware > Objective Function=E2=80=9D. > > > > And one more thing. I find with your proposed NSA that includes parent > address(es), we don=E2=80=99t need to insert the parent address into our = CNC > metric. This greatly simplifies our solution. That=E2=80=99s good! > > > > Best regards, > > Derek Jianqiang Hou > > > > Related drafts: > > https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ > > https://datatracker.ietf.org/doc/rfc6551/ > > https://datatracker.ietf.org/doc/draft-qasem-roll-rpl-load-balancing/ > > https://datatracker.ietf.org/doc/draft-ji-roll-traffic- > aware-objective-function/ > > > --94eb2c12522a1effb805628342ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi again,

thanks for= another idea. I looked into it and it seems that it allows zero or one par= ent address (0 is on storing mode, 1 in non-storing mode). So for us this w= ouldn't do.
Also, the "Transit Information" option h= as so,e specific usage with the "RPL Target" option preceding it,= so it might be too complicated to define different behaviours based on whe= ther it is in DIO or DAO.
But thanks for the idea anyway. It has g= otten me thinking about alternative ways of accomplishing the same thing ea= sier.

Best,
Remous-Aris

On Sat, Dec 23, 2017 at 2:58 AM, Houj= ianqiang (Derek) <houjianqiang@huawei.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Another idea for your = consideration. The =E2=80=9CTransit Information=E2=80=9D in the DAO Option = contains parent address(es). What about enabling the use of Transit Informa= tion in the DIO Option field?

=C2=A0

Derek

=C2=A0

From: Houjianqiang (Derek)
Sent: Friday, December 22, 2017 5:35 PM
To: 'aris@= ariskou.com' <aris@ariskou.com>; 'georgios.papadopoulos@imt-atlanti= que.fr' <georgios.papadopoulos@imt-atlantique.fr><= br> Cc: roll <roll= @ietf.org>
Subject: About the flags of metric container in draft-pkm-roll-nsa-e= xtension

=C2=A0

Dear Remous-Aris and Georgios,

=C2=A0

Thanks for bringing your draft =E2=80=9Cdraft-pkm-ro= ll-nsa-extension=E2=80=9D into roll WG. It=E2=80=99s a very interesting wor= k and hope it could be adopted in this WG.

=C2=A0

The recent discussion with Chenyang triggers my inte= rest to read this draft again. Below are my comments.

=C2=A0

It seems that your NSA metric is locally used. I mea= n one node includes its potential parents into NSA and sends this NSA down = to its potential children. If this is correct, then it would be good to spe= cify the parameters used in the Metric Container (P,C, O, R ,A, Prec fields). (PS: there are two =E2=80=98A=E2=80= =99 and two =E2=80=98O=E2=80=99 bits in Figure 3 of your draft=E2=80=A6) I = suggest this because I find that to meet the NSA function you want, we may = need to extend the usage of Metric defined in RFC6551. What RFC6551 bother me are the =E2=80=98R=E2=80=99 flag and =E2=80=98A=E2=80=99 field in the M= C. When NSA is used as a metric, R=3D1 indicates that the NSA is recorded a= long the path; R=3D0 indicates the NSA metric is aggregated (this aggregati= on could be additive, multiplicative, reports a maximum or minimum accordin= g to the =E2=80=98A=E2=80=99 field). I suppose the NSA metric requires to be= used locally, not aggregation or recorded along the path. I guess the =E2= =80=98P=E2=80=99 flag may help to solve this issue or we may need a new fla= g in the MC to indicate a locally used metric.

=C2=A0

I am involved in draft =E2=80=9CLoad Balancing Objec= tive Function in RPL=E2=80=9D and I have similar concern when setting the f= lags in the metric container for the proposed Child Node Count (CNC) metric= . We also want the CNC to be used locally, and it seems we need to extend the current metric usage in RFC6551. The same requ= irement may appear in Chenyang=E2=80=99s draft =E2=80=9CTraffic-aware Objec= tive Function=E2=80=9D.

=C2=A0

And one more thing. I find with your proposed NSA th= at includes parent address(es), we don=E2=80=99t need to insert the parent = address into our CNC metric. This greatly simplifies our solution. That=E2= =80=99s good!

=C2=A0

Best regards,

Derek Jianqiang Hou

=C2=A0

Related drafts:

https://datatracker.ietf.org/= doc/draft-pkm-roll-nsa-extension/

https://datatracker.ietf.org/doc/rfc6551/

https://datatracker.ietf.or= g/doc/draft-qasem-roll-rpl-load-balancing/

https://datatrac= ker.ietf.org/doc/draft-ji-roll-traffic-aware-objective-function/<= /a>

=C2=A0


--94eb2c12522a1effb805628342ff-- From nobody Tue Jan 16 05:11: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 E9438131516 for ; Tue, 16 Jan 2018 05:11:55 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 J1NgniRp1gsk for ; Tue, 16 Jan 2018 05:11:52 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D501D1314F4 for ; Tue, 16 Jan 2018 05:09:38 -0800 (PST) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 2906E42B for ; Tue, 16 Jan 2018 14:09:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1516108176; bh=i+y5YXYwJwiwtTimarNHo1rR5yg/YxIRtp1D75x2hjk=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=E+ZR0Yh5qa0cSkqPjbAhBOZaHeoQBF0oieFghJ9A7mnQzJDUjhIA93x4Rn8YlmAhg UsS9fLfIQfb8bP9feCtxL5fbsPmTGDfKCE3dhemr64f83G8wzdE9YokMK9Vmz1bYkm IRC8UUC5tfT8Hi0AXlIZX4H83rfUBGKKb4mT6jwcfhXO1mL+J8Je57OaDa1Wi1chQ+ xiIAtIouZVHRMAKmpdj3PqWJo7L9UMF5/wygrQgcYl170Sag3WgvWnf1+VY8bBpqC8 1mt2ZfUHr7i4vzKrM0h90M21hQ8Watbru+rxoHNKc5oDl3WLu4GdnYCLpA77Vqn7XH 3yModd4BF025A== Received: from mail-qt0-f182.google.com ([209.85.216.182]) by smtp.mailfence.com (envelope-from ) with ESMTPSA for ; Tue, 16 Jan 2018 14:09:31 +0100 (CET) Received: by mail-qt0-f182.google.com with SMTP id m59so18116836qte.11 for ; Tue, 16 Jan 2018 05:09:30 -0800 (PST) X-Gm-Message-State: AKwxytfkH4HfDyR7A0YWfXTtnAIp/H9QnXQLPr40VZLCiUi27LOHSe6P liC9eQV7fP0u8IRfgMSxPPRosHizEPaXCCRsMfE= X-Google-Smtp-Source: ACJfBovnVY4unlBRvjxGRt8nnZaYSWSlBi5RrcsUQRJDeGE+adH9T5/y4DSlORmnzXnoZ+wqwOvPuSdMfwOVTa5wkWQ= X-Received: by 10.237.60.9 with SMTP id t9mr55929344qte.228.1516108168125; Tue, 16 Jan 2018 05:09:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.150.156 with HTTP; Tue, 16 Jan 2018 05:09:07 -0800 (PST) In-Reply-To: References: <377942561.78028.1513859706249.JavaMail.zimbra@imt-atlantique.net> From: Remous-Aris Koutsiamanis Date: Tue, 16 Jan 2018 14:09:33 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="94eb2c0e610ecd62e50562e470d6" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Suggestions for draft-ji-roll-traffic-aware-objective-function-00 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, 16 Jan 2018 13:11:56 -0000 --94eb2c0e610ecd62e50562e470d6 Content-Type: text/plain; charset="UTF-8" Hello Derek, thank you so much for the extremely helpful discussion. I have a question regarding the aggregation mode. On Fri, Dec 22, 2017 at 3:48 AM, Houjianqiang (Derek) wrote: > Hi Chenyang, > > Regarding your questions, please see my response in line. > > 2. I noticed one weak point of your solution and I have come up with > some possible ways to solve that. Nodes select their preferred parent node > based on the PTRs of their potential parents (if I understand it right). > For the two-hop cases in your draft, it's fine, but for multi-hop cases, > the downstream nodes are unaware of the PTRs of the sink nodes (nodes > connected to the root). For example, in the right pattern of Figure 2 in > your draft, if new nodes come in below C1/C2/D1/D2, then the new nodes will > prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new > node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have PTR = 1pkt/s, then in > this case, PTR_C1 = PTR_C2 = PTR_D1 = 2 pkt/s, PTR_A = 6 pkt/s. This in the > end triggers D1 switches from A to B. So my point is when new nodes join in > the downstream, they strongly influence the upstream connections. This > effect causes an unstable RPL network and should be minimized. One way I > come up with is to use the aggregatio > n mode in the Metric Container so that new nodes are able to know the > whole PTRs along a link to the root and then select based on the whole link > condition. Another possible way is you can define a new "RANK" computation > that includes the PTRs along a link, e.g. RANK_C1 = PTR_A+0.5*PTR_C1. > > [RE] You are right about the weak point,thank you. > About the aggregation mode,if I understand correct that requires node to > inform its direct child about its transmission rate change(new node joins > its subtree,child changes parent etc),that may increase the frequency of > DIO messages? > > >> [Derek] The frequency of sending DIO is determined by Trickle > algorithm, not the aggregation mode. RPL adapts the sending rate of DIO > messages by extending the Trickle algorithm. In a network with stable links > the control messages will be rare whereas an environment in which the > topology changes frequently will cause RPL to send control information more > often. > So, in this draft, the PTR information is sourced directly from the traffic each node has "seen", e.g. if a node has seen 2 packets in the last second, it will report this 2pkts/sec. You have proposed using the aggregation mode in the Metric Container to alter the number reported. As far as I can tell it would work like this: A node measures its own observed PTR: PTR_OWN. However, it also receives DIO messages from other nodes. When it gets a DIO message from its preferred parent it extracts the parent's reported PTR: PTR_PARENT. Before getting a DIO message the default is PTR_PARENT=0. So, when the node needs to broadcast a new DIO of its own, the PTR value it reports is PTR = PTR_OWN + PTR_PARENT. Therefore, in the example on the right in Figure 2, the reported PTRs from the nodes will not be the shown ones but: R: 6, A: 3 + 6 (from R) = 9 B: 3 + 6 (from R) = 9 C1, C2, D1: 1 + 9 (from A) = 10 D2: 3 + 9 (from B) = 12 So when a new node E1 with PTR_OWN=1pkt/sec comes under C1,C2,D1,D2 it will avoid D2 and it will pick one of C1,C2,D1 and report its own PTR via DIO as: E1: 1 + 10 (from say C1) = 11 in the same way: E2: 1 + 10 (from say C2) = 11 E3: 1 + 10 (from say C1) = 11 Is this what you have in mind? > > About rank computation,nodes with larger transmission rate will have > larger rank than its neighbor nodes so there is a possibility it selects > its neighbor as parent and increase the traffic of other subtree. > I don't know if I described it in the right way,I'll send a example if > needed. > > >>[Derek] I guess I have got what you mean. Let's still take the right > pattern in Figure 2 in your draft as an example, are you saying that when > PTR_D2 becomes larger, e.g. 5pkt/s, then PTR_B = 5. If using the "RANK" > equation I suggested above, then RANK_A = 3, RANK_B = 5, RANK_D1 = 3.5, > RANK_D2 = 7.5. In this case node D2 may change its parent from B to D1. If > this is what you mean, definitely we don't want to see this happen. To > avoid this, you should specify when and under what condition the parent > switch will happen. The PARENT_SWITCH_THRESHOLD of D2 should be related to > RANK_B together with PTR_D2. I mean since the downstream nodes influence > the RANK of their upstream parent, then node D2 should compute what RANK_B > will be if without the contribution of D2 itself. > > Regards, > Derek Jianqiang Hou > > -----Original Message----- > From: Chenyang JI [mailto:chenyang.ji@imt-atlantique.net] > Sent: Thursday, December 21, 2017 8:35 PM > To: Houjianqiang (Derek) > Cc: roll > Subject: Re: Suggestions for draft-ji-roll-traffic-aware-ob > jective-function-00 > > Good morning, > > Thank you a lot for the suggestions,they are very helpful. > I added some response below the suggestions after [RE] > > > 1. The format of your PTR metric should be modified in order to be > consistent with current Metric framework as define in RFC6551. Based on my > understanding, you are not requiring IANA to assign a new "DAGMC type" but > rather a new "Routing-MC-Type" inside the DAG Metric Container. There is a > DAG Metric Container Format in RFC6551 you can follow and put your PTR > inside the container as a new metric object. Your co-author Georgios has > given a good example in his draft "draft-pkm-roll-nsa-extension-00". The > metric container gives you many functions, such as combining PTR with other > metrics like ETX (constraint), ChildCount (metric) and HopCount (metric), > which has been mentioned in your draft. > > [RE] I'll make a new figure to clarify that Transmission rate is included > in Metric container. > > > 2. I noticed one weak point of your solution and I have come up with > some possible ways to solve that. Nodes select their preferred parent node > based on the PTRs of their potential parents (if I understand it right). > For the two-hop cases in your draft, it's fine, but for multi-hop cases, > the downstream nodes are unaware of the PTRs of the sink nodes (nodes > connected to the root). For example, in the right pattern of Figure 2 in > your draft, if new nodes come in below C1/C2/D1/D2, then the new nodes will > prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new > node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have PTR = 1pkt/s, then in > this case, PTR_C1 = PTR_C2 = PTR_D1 = 2 pkt/s, PTR_A = 6 pkt/s. This in the > end triggers D1 switches from A to B. So my point is when new nodes join in > the downstream, they strongly influence the upstream connections. This > effect causes an unstable RPL network and should be minimized. One way I > come up with is to use the aggregatio > n mode in the Metric Container so that new nodes are able to know the > whole PTRs along a link to the root and then select based on the whole link > condition. Another possible way is you can define a new "RANK" computation > that includes the PTRs along a link, e.g. RANK_C1 = PTR_A+0.5*PTR_C1. > > [RE] You are right about the weak point,thank you. > About the aggregation mode,if I understand correct that requires node to > inform its direct child about its transmission rate change(new node joins > its subtree,child changes parent etc),that may increase the frequency of > DIO messages? > About rank computation,nodes with larger transmission rate will have > larger rank than its neighbor nodes so there is a possibility it selects > its neighbor as parent and increase the traffic of other subtree. > I don't know if I described it in the right way,I'll send a example if > needed. > > > Regards > Chenyang > > ----- Original Message ----- > From: "Houjianqiang" > To: "Chenyang JI" > Cc: "roll" > Sent: Thursday, December 21, 2017 7:49:08 AM > Subject: Suggestions for draft-ji-roll-traffic-aware-objective-function-00 > > Hi Chenyang, > > Nice to see that you are involved in improving the parent selection in RPL > network, and thanks for bringing the idea "Packet Transmission Rate" into > roll WG. Your solution is very useful, especially when traffic generated > from different nodes is "highly" uneven. I have read through your draft and > provide my comments and suggestions as below. > > > 1. The format of your PTR metric should be modified in order to be > consistent with current Metric framework as define in RFC6551. Based on my > understanding, you are not requiring IANA to assign a new "DAGMC type" but > rather a new "Routing-MC-Type" inside the DAG Metric Container. There is a > DAG Metric Container Format in RFC6551 you can follow and put your PTR > inside the container as a new metric object. Your co-author Georgios has > given a good example in his draft "draft-pkm-roll-nsa-extension-00". The > metric container gives you many functions, such as combining PTR with other > metrics like ETX (constraint), ChildCount (metric) and HopCount (metric), > which has been mentioned in your draft. > > > > 2. I noticed one weak point of your solution and I have come up with > some possible ways to solve that. Nodes select their preferred parent node > based on the PTRs of their potential parents (if I understand it right). > For the two-hop cases in your draft, it's fine, but for multi-hop cases, > the downstream nodes are unaware of the PTRs of the sink nodes (nodes > connected to the root). For example, in the right pattern of Figure 2 in > your draft, if new nodes come in below C1/C2/D1/D2, then the new nodes will > prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let's say new > node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have PTR = 1pkt/s, then in > this case, PTR_C1 = PTR_C2 = PTR_D1 = 2 pkt/s, PTR_A = 6 pkt/s. This in the > end triggers D1 switches from A to B. So my point is when new nodes join in > the downstream, they strongly influence the upstream connections. This > effect causes an unstable RPL network and should be minimized. One way I > come up with is to use the aggregatio > n mode in the Metric Container so that new nodes are able to know the > whole PTRs along a link to the root and then select based on the whole link > condition. Another possible way is you can define a new "RANK" computation > that includes the PTRs along a link, e.g. RANK_C1 = PTR_A+0.5*PTR_C1. > > > > 3. The PTR computation method hasn't been illustrated in your draft. > After thinking a bit more, here is my suggestion. The first method that > came into my mind is to compute base on a time cycle, e.g. count the number > of packet per 10 seconds, but then I denied this method for three reasons: > 1. Nodes may have sleep mode and cannot do this PTR computation when > sleeping; 2. a fixed time cycle may not be accurate to reflect PTR because > nodes may send packets at different rate at different time, e.g. 1pkt/s, > 1pkt/hour, 1pkt/day; 3. frequently computing PTR consumes more energy. I > suggest doing the PTR computation based on the time points when sending > packets. For example, a node send Packet_n-1 at time t_n-1 and send > Packet_n at time t_n, then 1 / (t_n - t_n-1) reflects the packet rate. Then > The PTR at time t_n could be > > PTR_n = alpha * 1 / (t_n - t_n-1) + (1 - alpha) * PTR_n-1, > > where alpha are constant between 0 to 1. In this way, nodes refresh their > PTR when sending packets, and the PTR equation gives a smooth variation > that guarantees the stability of a RPL network. > > Hopefully my suggestions could help to improve the quality of your draft. > > Best regards, > Derek Jianqiang Hou > > Related drafts and RFC: > https://datatracker.ietf.org/doc/draft-ji-roll-traffic-aware > -objective-function/ > https://datatracker.ietf.org/doc/rfc6551/ > https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/ > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > Best, Aris --94eb2c0e610ecd62e50562e470d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Derek,
thank you so much for the = extremely helpful discussion. I have a question regarding the aggregation m= ode.

On = Fri, Dec 22, 2017 at 3:48 AM, Houjianqiang (Derek) <houjianqiang@huawei.com> wrote:=
Hi Chenyang,

Regarding your questions, please see my response in line.

2.=C2=A0 =C2=A0 =C2=A0 I noticed one weak point of your solution and I have= come up with some possible ways to solve that. Nodes select their preferre= d parent node based on the PTRs of their potential parents (if I understand= it right). For the two-hop cases in your draft, it's fine, but for mul= ti-hop cases, the downstream nodes are unaware of the PTRs of the sink node= s (nodes connected to the root). For example, in the right pattern of Figur= e 2 in your draft, if new nodes come in below C1/C2/D1/D2, then the new nod= es will prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let= 9;s say new node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have = PTR =3D 1pkt/s, then in this case, PTR_C1 =3D PTR_C2 =3D PTR_D1 =3D 2 pkt/s= , PTR_A =3D 6 pkt/s. This in the end triggers D1 switches from A to B. So m= y point is when new nodes join in the downstream, they strongly influence t= he upstream connections. This effect causes an unstable RPL network and sho= uld be minimized. One way I come up with is to use the aggregatio
=C2=A0n mode in the Metric Container so that new nodes are able to know the= whole PTRs along a link to the root and then select based on the whole lin= k condition. Another possible way is you can define a new "RANK" = computation that includes the PTRs along a link, e.g. RANK_C1 =3D PTR_A+0.5= *PTR_C1.

[RE] You are right about the weak point,thank you.
About the aggregation mode,if I understand correct that requires node to in= form its direct child about its transmission rate change(new node joins its= subtree,child changes parent etc),that may increase the frequency of DIO m= essages?

>> [Derek] The frequency of sending DIO is determined by Trick= le algorithm, not the aggregation mode. RPL adapts the sending rate of DIO = messages by extending the Trickle algorithm. In a network with stable links= the control messages will be rare whereas an environment in which the topo= logy changes frequently will cause RPL to send control information more oft= en.

So, in this draft, the PTR information is so= urced directly from the traffic each node has "seen", e.g. if a n= ode has seen 2 packets in the last second, it will report this 2pkts/sec. Y= ou have proposed using the aggregation mode in the Metric Container to alte= r the number reported.
As far as I can tell it would work like th= is:
A node measures its own observed PTR: PTR_OWN.
However, it also receive= s DIO mess= ages from other nodes. When it gets a DIO message from its preferred parent it extrac= ts the parent's reported PTR: PTR_PARENT. Before getting a DIO message the default is PTR_PARENT=3D0.
So, when the node needs to broadcast a new DIO of its own, the PTR value it reports is = PTR =3D <= span class=3D"" style=3D"" id=3D":2dr.16" tabindex=3D"-1">PTR_OWN + = PTR_PAREN= T.
Therefore, in the example on the right in Figure 2, the report= ed PTRs f= rom the nodes will not be the shown ones but:
R: 6, A: 3 + 6= (from R) =3D 9
B: 3 + 6 (from R) =3D 9
C1, C2, D1: 1 = + 9 (from A) =3D 10
D2: 3 + 9 (from B) =3D 12

So when a new node E1 with PTR_OWN=3D1pkt/sec comes under C1,C2,D1= ,D2 it will avoid D2 and it will pick one of C1,C2,D1 and report its own PTR via DIO as:
E1: 1 + 10 (from say C1) =3D 11
in the same way:
= E2: 1 + 10 (from say C2) =3D 11
E3: 1 + 10 (from say C1) =3D= 11

Is this what you have in mind?

<= /div>
=C2=A0

About rank computation,nodes with larger transmission rate will have larger= rank than its neighbor nodes so there is a possibility it selects its neig= hbor as parent and increase the traffic of other subtree.
I don't know if I described it in the right way,I'll send a example= if needed.

>>[Derek] I guess I have got what you mean. Let's still ta= ke the right pattern in Figure 2 in your draft as an example, are you sayin= g that when PTR_D2 becomes larger, e.g. 5pkt/s, then PTR_B =3D 5. If using = the "RANK" equation I suggested above, then RANK_A =3D 3, RANK_B = =3D 5, RANK_D1 =3D 3.5, RANK_D2 =3D 7.5. In this case node D2 may change it= s parent from B to D1. If this is what you mean, definitely we don't wa= nt to see this happen. To avoid this, you should specify when and under wha= t condition the parent switch will happen. The PARENT_SWITCH_THRESHOLD of D= 2 should be related to RANK_B together with PTR_D2. I mean since the downst= ream nodes influence the RANK of their upstream parent, then node D2 should= compute what RANK_B will be if without the contribution of D2 itself.

Regards,
Derek Jianqiang Hou

-----Original Message-----
From: Chenyang JI [mailto:chenyang.ji@imt-atlantique.net]
Sent: Thursday, December 21, 2017 8:35 PM
To: Houjianqiang (Derek) <houjianqiang@huawei.com>
Cc: roll <roll@ietf.o= rg>
Subject: Re: Suggestions for draft-ji-roll-traffic-aware-objective-fun= ction-00

Good morning,

Thank you a lot for the suggestions,they are very helpful.
I added some response below the suggestions after [RE]


1.=C2=A0 =C2=A0 =C2=A0 The format=C2=A0 of your PTR metric should be modifi= ed in order to be consistent with current Metric framework as define in RFC= 6551. Based on my understanding, you are not requiring IANA to assign a new= "DAGMC type" but rather a new "Routing-MC-Type" inside= the DAG Metric Container. There is a=C2=A0 DAG Metric Container Format in = RFC6551 you can follow and put your PTR inside the container as a new metri= c object. Your co-author Georgios has given a good example in his draft &qu= ot;draft-pkm-roll-nsa-extension-00". The metric container gives y= ou many functions, such as combining PTR with other metrics like ETX (const= raint), ChildCount (metric) and HopCount (metric), which has been mentioned= in your draft.

[RE] I'll make a new figure to clarify that Transmission rate is includ= ed in Metric container.


2.=C2=A0 =C2=A0 =C2=A0 I noticed one weak point of your solution and I have= come up with some possible ways to solve that. Nodes select their preferre= d parent node based on the PTRs of their potential parents (if I understand= it right). For the two-hop cases in your draft, it's fine, but for mul= ti-hop cases, the downstream nodes are unaware of the PTRs of the sink node= s (nodes connected to the root). For example, in the right pattern of Figur= e 2 in your draft, if new nodes come in below C1/C2/D1/D2, then the new nod= es will prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let= 9;s say new node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have = PTR =3D 1pkt/s, then in this case, PTR_C1 =3D PTR_C2 =3D PTR_D1 =3D 2 pkt/s= , PTR_A =3D 6 pkt/s. This in the end triggers D1 switches from A to B. So m= y point is when new nodes join in the downstream, they strongly influence t= he upstream connections. This effect causes an unstable RPL network and sho= uld be minimized. One way I come up with is to use the aggregatio
=C2=A0n mode in the Metric Container so that new nodes are able to know the= whole PTRs along a link to the root and then select based on the whole lin= k condition. Another possible way is you can define a new "RANK" = computation that includes the PTRs along a link, e.g. RANK_C1 =3D PTR_A+0.5= *PTR_C1.

[RE] You are right about the weak point,thank you.
About the aggregation mode,if I understand correct that requires node to in= form its direct child about its transmission rate change(new node joins its= subtree,child changes parent etc),that may increase the frequency of DIO m= essages?
About rank computation,nodes with larger transmission rate will have larger= rank than its neighbor nodes so there is a possibility it selects its neig= hbor as parent and increase the traffic of other subtree.
I don't know if I described it in the right way,I'll send a example= if needed.


Regards
Chenyang

----- Original Message -----
From: "Houjianqiang" <houjianqiang@huawei.com>
To: "Chenyang JI" <chenyang.ji@imt-atlantique.net>
Cc: "roll" <roll@ietf.org>
Sent: Thursday, December 21, 2017 7:49:08 AM
Subject: Suggestions for draft-ji-roll-traffic-aware-objective-functio= n-00

Hi Chenyang,

Nice to see that you are involved in improving the parent selection in RPL = network, and thanks for bringing the idea "Packet Transmission Rate&qu= ot; into roll WG. Your solution is very useful, especially when traffic gen= erated from different nodes is "highly" uneven. I have read throu= gh your draft and provide my comments and suggestions as below.


1.=C2=A0 =C2=A0 =C2=A0 The format=C2=A0 of your PTR metric should be modifi= ed in order to be consistent with current Metric framework as define in RFC= 6551. Based on my understanding, you are not requiring IANA to assign a new= "DAGMC type" but rather a new "Routing-MC-Type" inside= the DAG Metric Container. There is a=C2=A0 DAG Metric Container Format in = RFC6551 you can follow and put your PTR inside the container as a new metri= c object. Your co-author Georgios has given a good example in his draft &qu= ot;draft-pkm-roll-nsa-extension-00". The metric container gives y= ou many functions, such as combining PTR with other metrics like ETX (const= raint), ChildCount (metric) and HopCount (metric), which has been mentioned= in your draft.



2.=C2=A0 =C2=A0 =C2=A0 I noticed one weak point of your solution and I have= come up with some possible ways to solve that. Nodes select their preferre= d parent node based on the PTRs of their potential parents (if I understand= it right). For the two-hop cases in your draft, it's fine, but for mul= ti-hop cases, the downstream nodes are unaware of the PTRs of the sink node= s (nodes connected to the root). For example, in the right pattern of Figur= e 2 in your draft, if new nodes come in below C1/C2/D1/D2, then the new nod= es will prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is larger). Let= 9;s say new node E1->C1, E2->C2, E3->D1, and assume E1/E2/E3 have = PTR =3D 1pkt/s, then in this case, PTR_C1 =3D PTR_C2 =3D PTR_D1 =3D 2 pkt/s= , PTR_A =3D 6 pkt/s. This in the end triggers D1 switches from A to B. So m= y point is when new nodes join in the downstream, they strongly influence t= he upstream connections. This effect causes an unstable RPL network and sho= uld be minimized. One way I come up with is to use the aggregatio
=C2=A0n mode in the Metric Container so that new nodes are able to know the= whole PTRs along a link to the root and then select based on the whole lin= k condition. Another possible way is you can define a new "RANK" = computation that includes the PTRs along a link, e.g. RANK_C1 =3D PTR_A+0.5= *PTR_C1.



3.=C2=A0 =C2=A0 =C2=A0 The PTR computation method hasn't been illustrat= ed in your draft. After thinking a bit more, here is my suggestion. The fir= st method that came into my mind is to compute base on a time cycle, e.g. c= ount the number of packet per 10 seconds, but then I denied this method for= three reasons: 1. Nodes may have sleep mode and cannot do this PTR computa= tion when sleeping; 2. a fixed time cycle may not be accurate to reflect PT= R because nodes may send packets at different rate at different time, e.g. = 1pkt/s, 1pkt/hour, 1pkt/day; 3. frequently computing PTR consumes more ener= gy. I suggest doing the PTR computation based on the time points when sendi= ng packets. For example, a node send Packet_n-1 at time t_n-1 and send Pack= et_n at time t_n, then 1 / (t_n - t_n-1) reflects the packet rate. Then The= PTR at time t_n could be

PTR_n =3D alpha * 1 / (t_n - t_n-1) + (1 - alpha) * PTR_n-1,

where alpha are constant between 0 to 1. In this way, nodes refresh their P= TR when sending packets, and the PTR equation gives a smooth variation that= guarantees the stability of a RPL network.

Hopefully my suggestions could help to improve the quality of your draft.
Best regards,
Derek Jianqiang Hou

Related drafts and RFC:
https://datatracker.= ietf.org/doc/draft-ji-roll-traffic-aware-objective-function/<= br> https://datatracker.ietf.org/doc/rfc6551/
https://datatracker.ietf.org/doc/= draft-pkm-roll-nsa-extension/
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
<= /div>


Best,
Aris
<= /div>
--94eb2c0e610ecd62e50562e470d6-- From nobody Tue Jan 16 19:27:02 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 63F99128896 for ; Tue, 16 Jan 2018 19:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JZ6ws6EZmHZQ for ; Tue, 16 Jan 2018 19:26:58 -0800 (PST) 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 879071242EA for ; Tue, 16 Jan 2018 19:26:58 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3D7396E65B2F2 for ; Wed, 17 Jan 2018 03:26:55 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 17 Jan 2018 03:26:56 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Wed, 17 Jan 2018 11:26:51 +0800 From: "Houjianqiang (Derek)" To: Remous-Aris Koutsiamanis , "roll@ietf.org" Thread-Topic: [Roll] Suggestions for draft-ji-roll-traffic-aware-objective-function-00 Thread-Index: AdOPN6+ONtR+znsSREip0gLyBwIdqg== Date: Wed, 17 Jan 2018 03:26:51 +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.134.134.224] 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] Suggestions for draft-ji-roll-traffic-aware-objective-function-00 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, 17 Jan 2018 03:27:01 -0000 Hi Aris, Thanks for your question, please see my response in line.=20 > Hello Derek, > thank you so much for the extremely helpful discussion. I have a question > regarding the aggregation mode. >=20 > On Fri, Dec 22, 2017 at 3:48 AM, Houjianqiang (Derek) > wrote: >=20 > > Hi Chenyang, > > > > Regarding your questions, please see my response in line. > > > > 2. I noticed one weak point of your solution and I have come up wi= th > > some possible ways to solve that. Nodes select their preferred parent > > node based on the PTRs of their potential parents (if I understand it r= ight). > > For the two-hop cases in your draft, it's fine, but for multi-hop > > cases, the downstream nodes are unaware of the PTRs of the sink nodes > > (nodes connected to the root). For example, in the right pattern of > > Figure 2 in your draft, if new nodes come in below C1/C2/D1/D2, then > > the new nodes will prefer to choose C1/C2/D1 rather than D2 (PTR_D2 is > > larger). Let's say new node E1->C1, E2->C2, E3->D1, and assume > > E1/E2/E3 have PTR =3D 1pkt/s, then in this case, PTR_C1 =3D PTR_C2 =3D > > PTR_D1 =3D 2 pkt/s, PTR_A =3D 6 pkt/s. This in the end triggers D1 > > switches from A to B. So my point is when new nodes join in the > > downstream, they strongly influence the upstream connections. This > > effect causes an unstable RPL network and should be minimized. One way > > I come up with is to use the aggregatio n mode in the Metric > > Container so that new nodes are able to know the whole PTRs along a > > link to the root and then select based on the whole link condition. > > Another possible way is you can define a new "RANK" computation that > includes the PTRs along a link, e.g. RANK_C1 =3D PTR_A+0.5*PTR_C1. > > > > [RE] You are right about the weak point,thank you. > > About the aggregation mode,if I understand correct that requires node > > to inform its direct child about its transmission rate change(new node > > joins its subtree,child changes parent etc),that may increase the > > frequency of DIO messages? > > > > >> [Derek] The frequency of sending DIO is determined by Trickle > > algorithm, not the aggregation mode. RPL adapts the sending rate of > > DIO messages by extending the Trickle algorithm. In a network with > > stable links the control messages will be rare whereas an environment > > in which the topology changes frequently will cause RPL to send > > control information more often. > > >=20 > So, in this draft, the PTR information is sourced directly from the traff= ic each > node has "seen", e.g. if a node has seen 2 packets in the last second, it= will > report this 2pkts/sec. You have proposed using the aggregation mode in th= e > Metric Container to alter the number reported. > As far as I can tell it would work like this: > A node measures its own observed PTR: PTR_OWN. > However, it also receives DIO messages from other nodes. When it gets a > DIO message from its preferred parent it extracts the parent's reported > PTR: PTR_PARENT. > Before getting a DIO message the default is PTR_PARENT=3D0. > So, when the node needs to broadcast a new DIO of its own, the PTR value = it > reports is PTR =3D PTR_OWN + PTR_PARENT. > Therefore, in the example on the right in Figure 2, the reported PTRs fro= m > the nodes will not be the shown ones but: > R: 6, A: 3 + 6 (from R) =3D 9 > B: 3 + 6 (from R) =3D 9 > C1, C2, D1: 1 + 9 (from A) =3D 10 > D2: 3 + 9 (from B) =3D 12 >=20 > So when a new node E1 with PTR_OWN=3D1pkt/sec comes under C1,C2,D1,D2 > it will avoid D2 and it will pick one of C1,C2,D1 and report its own PTR = via DIO > as: > E1: 1 + 10 (from say C1) =3D 11 > in the same way: > E2: 1 + 10 (from say C2) =3D 11 > E3: 1 + 10 (from say C1) =3D 11 >=20 > Is this what you have in mind? [Jianqiang Hou] Yes, you are right. Thanks for your interpretation, it refl= ects the first method I suggest.=20 And to explain a bit more I have in mind, after I read Ji's draft, what I w= as thinking is what is the main factors in this traffic-aware OF? I think t= he traffic near the route is more important than the traffic on the bottom,= especially for the sink nodes, that's why I suggest new nodes should be aw= are of the traffic along the link. The sample patterns in Ji's draft are qu= ite simple cases, and if I induce a bit variation then you will see the one= -hop PTR is not enough. Based on the current figure we are talking about (F= igure 2. Balanced), if node A and B are far away in distance, C1/C2/D1 are = fixed to A while D2 is fixed to B. Then when PTR_C1 increases, here let's s= ay to 4pkt/s, that results to the pattern shown below (hopefully the font f= ormat does not influence it too much). In this case, when new node E1 joins= , the "one-hop PTR" strategy puts C2/D1 in the first priority as potential = parent, but if considering PTR_A and PTR_B, E1 should connects to D2. And m= oreover, I suppose simple aggregation by adding up PTRs along a link may no= t be the best choice because nodes near the root are more important and sho= uld have higher weight on PTRs, this is the reason I came up with the secon= d method in my suggestion. 9pkt/s (R) ^ | +--------+----------------+ | | + + 6pkt/s (A) 3pkt/s (B) ^ ^ | | +------+------+ +--------+ | | | | + + + + (C1) (C2) (D1) (D2) 4pkt/s 1pkt/s 1pkt/s 3pkt/s Regards, Derek From nobody Thu Jan 18 05:31:32 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 6A177124BFA for ; Thu, 18 Jan 2018 05:31:27 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.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 ZU-KhfVlQPlV for ; Thu, 18 Jan 2018 05:31:25 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039771241F3 for ; Thu, 18 Jan 2018 05:31:24 -0800 (PST) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 91104AB7 for ; Thu, 18 Jan 2018 14:31:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1516282282; bh=ybzmsZ5k86Dikgf+J4+UTfFhbb9b4e98ArHv4yHDK5o=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=XbSfmymdEO7UtmkiZX0+bkLbck7i7dggg742swYHlrdlXoZg2foGT9E2wkWyustq9 nW7BLNdMizwRftAzglcXQkb7Y4voVmxhXreqn6R5E4q/Kl2U8jqSx8HHfodGwak4Yy tNVBEJcI9k0c+VJfaCbL4fXavLN8wE01ec3H7hs+s6A9e3+qMpwJrzlKCeMMGk3orn IU00eEgetSK4RFNmw4HvYB3ulAYFp2WqeakSNAyQvcn04ebrt8p5nfLpeuEjqrJtok d9kI9z1BSG/AIErPugv6nd66Z2cm/NHyn66PdP0LHivUSg/69qCqYNiDSDMKq0TK1d TOtWlPjSTwGeA== Received: from mail-qt0-f177.google.com ([209.85.216.177]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Thu, 18 Jan 2018 14:31:19 +0100 (CET) Received: by mail-qt0-f177.google.com with SMTP id m59so30149483qte.11 for ; Thu, 18 Jan 2018 05:31:19 -0800 (PST) X-Gm-Message-State: AKwxyteh1k/QwbM9lPgRL49npYoWJ/WMk2w8VywAoLcJ1uv1OaMxkZLG eEZlYiQYLyhOZSXARDbx74nYzA+dYSNkOjYRrlM= X-Google-Smtp-Source: ACJfBotixLKff+xtBVQxJ55xpfsVA8koG5IE7tAETb9k6WRj/5PRtiBk6ETgIbht+sEevyEsAG3of8jKHJ/dfdUD+uk= X-Received: by 10.237.60.9 with SMTP id t9mr66803844qte.228.1516282277985; Thu, 18 Jan 2018 05:31:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.150.156 with HTTP; Thu, 18 Jan 2018 05:30:57 -0800 (PST) In-Reply-To: <151621674110.21681.9656495175973825244.idtracker@ietfa.amsl.com> References: <151621674110.21681.9656495175973825244.idtracker@ietfa.amsl.com> From: Remous-Aris Koutsiamanis Date: Thu, 18 Jan 2018 14:31:21 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: roll Cc: Nicolas Montavont , Pascal Thubert , Georgios Papadopoulos Content-Type: multipart/alternative; boundary="94eb2c0e610e8f04c805630cfa65" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] New Version Notification for draft-koutsiamanis-roll-nsa-extension-01.txt 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, 18 Jan 2018 13:31:30 -0000 --94eb2c0e610e8f04c805630cfa65 Content-Type: text/plain; charset="UTF-8" Hello all, We have just updated our draft (*draft-koutsiamanis-roll-nsa-**extension-01* ). We slightly renamed it and added a new Figure "Example Parent Selection mechanism" explaining how parent selection can be performed using the information in the proposed extension. Additionally, taking into account the very helpful discussion with Derek Jianqiang Hou, we have clarified how the extension is to be used and how the DAG Metric Container header fields are used with it. Any comments or feedback will be very welcome. Best, Aris On Wed, Jan 17, 2018 at 8:19 PM, wrote: > > A new version of I-D, draft-koutsiamanis-roll-nsa-extension-01.txt > has been successfully submitted by Remous-Aris Koutsiamanis and posted to > the > IETF repository. > > Name: draft-koutsiamanis-roll-nsa-extension > Revision: 01 > Title: RPL DAG Metric Container (MC) Node State and Attribute > (NSA) object type extension > Document date: 2018-01-17 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-koutsiamanis- > roll-nsa-extension-01.txt > Status: https://datatracker.ietf.org/doc/draft-koutsiamanis-roll- > nsa-extension/ > Htmlized: https://tools.ietf.org/html/draft-koutsiamanis-roll-nsa- > extension-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-koutsiamanis- > roll-nsa-extension-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-koutsiamanis-roll- > nsa-extension-01 > > Abstract: > Implementing 6TiSCH Packet Replication and Elimination from / to the > RPL root requires the ability to forward copies of packets over > different paths via different RPL parents. Selecting the appropriate > parents to achieve ultra-low latency and jitter requires information > about a node's parents. This document details what information needs > to be transmitted and how it is encoded within a packet to enable > this functionality. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --94eb2c0e610e8f04c805630cfa65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

We have just updat= ed our draft (draft-koutsiamanis-roll-nsa-extension-01).=
We slightly renamed it and added a new Figure "Example Parent Selection= =20 mechanism" explaining how parent selection can be performed using the= =20 information in the proposed extension.
Additionally, taking=20 into account the very helpful discussion with Derek Jianqiang Hou, we=20 have clarified how the extension is to be used and how the DAG Metric=20 Container header fields are used with it.

Any comm= ents or feedback will be very welcome.

Best,
Aris

<= div class=3D"gmail_quote">On Wed, Jan 17, 2018 at 8:19 PM, <intern= et-drafts@ietf.org> wrote:
=
A new version of I-D, draft-koutsiamanis-roll-nsa-extension-01.txt
has been successfully submitted by Remous-Aris Koutsiamanis and posted to t= he
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-koutsiamanis-roll-nsa-<= wbr>extension
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RPL DAG Metric Container (MC) Node= State and Attribute (NSA) object type extension
Document date:=C2=A0 2018-01-17
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-= koutsiamanis-roll-nsa-extension-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-koutsiamanis-roll-<= wbr>nsa-extension/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-koutsiamanis-roll-nsa-exten= sion-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-koutsiamanis= -roll-nsa-extension-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-koutsi= amanis-roll-nsa-extension-01

Abstract:
=C2=A0 =C2=A0Implementing 6TiSCH Packet Replication and Elimination from / = to the
=C2=A0 =C2=A0RPL root requires the ability to forward copies of packets ove= r
=C2=A0 =C2=A0different paths via different RPL parents.=C2=A0 Selecting the= appropriate
=C2=A0 =C2=A0parents to achieve ultra-low latency and jitter requires infor= mation
=C2=A0 =C2=A0about a node's parents.=C2=A0 This document details what i= nformation needs
=C2=A0 =C2=A0to be transmitted and how it is encoded within a packet to ena= ble
=C2=A0 =C2=A0this functionality.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--94eb2c0e610e8f04c805630cfa65-- From nobody Mon Jan 22 07:15:17 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 9B85E1200C5; Mon, 22 Jan 2018 07:15:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: roll-chairs@ietf.org, roll@ietf.org, maria.ines.robles@ericsson.com, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151663411559.8157.16323022795278342423.idtracker@ietfa.amsl.com> Date: Mon, 22 Jan 2018 07:15:15 -0800 Archived-At: Subject: [Roll] roll - New Meeting Session Request for IETF 101 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: Mon, 22 Jan 2018 15:15:15 -0000 A new meeting session request has just been submitted by Ines Robles, a Chair of the roll working group. --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: anima manet 6tisch core ace Second Priority: rtgarea 6lo 6man lwig cbor t2trg Third Priority: rtgwg intarea lpwan People who must be present: Michael Richardson Peter Van der Stok Alvaro Retana Ines Robles Resources Requested: Special Requests: Meetecho Support --------------------------------------------------------- From nobody Mon Jan 22 07:38:17 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 4D9F2126CD6 for ; Mon, 22 Jan 2018 07:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 W-sxPx4BqdfM for ; Mon, 22 Jan 2018 07:38:13 -0800 (PST) Received: from lb2-smtp-cloud9.xs4all.net (lb2-smtp-cloud9.xs4all.net [194.109.24.26]) (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 734BE124207 for ; Mon, 22 Jan 2018 07:38:13 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud9.xs4all.net with ESMTPA id deAieeg2u6VzTdeAiejytS; Mon, 22 Jan 2018 16:38:08 +0100 Received: from AMontpellier-654-1-151-23.w90-0.abo.wanadoo.fr ([90.0.222.23]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 22 Jan 2018 16:38:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 22 Jan 2018 16:38:08 +0100 From: peter van der Stok To: Roll Cc: Alvaro Retana , Alvaro Retana Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfB6StINd8/8ZqDbY1DJfHHMHSARbplUdedfQQ++hEzsxWQtb/HPtfaGyDGGH2J3SkMLW3ReW5SZLw1MqSOHYHTm+EWPaFbmWBpqIWRU14XjhtXpomIat RvygxWSHdwFgQ06NBqvOBQrDzEfPJG3FN7gxpxCnFnWkG62leNcPHhsT+iIN1D+e/8+buQLVikxazIrGmxyetFeeMQzWv1BHHUje6MChk7hPGZ+2LvB8QXUd FSfT8V/+tlB0b4xgxrA2i2ZoQX9N5ZQcxl5xS0nMsANY7CMMYkOS58AGXCr73bvI Archived-At: Subject: [Roll] 2 Roll sessions at 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, 22 Jan 2018 15:38:16 -0000 Hi roll WG, During ietf100 we identified two topics which needed more discussion than can be handled in 15 minutes. Therefore, we asked for two sessions of 2 hours during the ietf101 meeting. - One session for the two topics - One session for regular ROLL operations: F2F discussions of drafts. To remind you the two topics are (in my terminology): - Using several versions of BIER approach and bloom filters for unicast and multicast - unified metrics for DODAG construction and routes Greetings, 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 Tue Jan 23 06:43:05 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 8B80E126BF0 for ; Tue, 23 Jan 2018 06:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5GbG-54IvSRC for ; Tue, 23 Jan 2018 06:43:02 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2DA1205D3 for ; Tue, 23 Jan 2018 06:43:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2156; q=dns/txt; s=iport; t=1516718582; x=1517928182; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=s1E5vZ6aNJb/SdLE53GJMI2FXia3vhpnWCohn/LWI+g=; b=BZblCjhVmNFJt4sfRlnZguOT5au7NpGQHHHrq/McFV0p3zortkfYcY64 r4xFL+nVwLkkd3AHqqqdXpBEaYqBpE32/ZI+/tNRvF+mh5nGmDzhFy1MN 2eHoxhsCTcnVYzXFxszflKpRGaBj+qb5RYZICktlfxq2vNYwbTQrj7zCs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABBAAGSWda/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQng12ZCYFbJ5lVChgLhRgCGoRcWBQBAQEBAQEBAQJrKIU?= =?us-ascii?q?kAQEDAQEBIREVJRALAgEIGgIjAwICAiULFAEQAgQTii0IELF7gieKMwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BD4M7ghWBV4FoKQyCeYMvAQECggaDADGCNAWjfgK?= =?us-ascii?q?VW4IbijaHUpcjAhEZAYE7ATYigToOCHAVPSoBgX8JhE0BeIpzAQEB?= X-IronPort-AV: E=Sophos;i="5.46,401,1511827200"; d="scan'208";a="60595796" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 14:43:01 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0NEh1oF020677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jan 2018 14:43:01 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Jan 2018 08:43:00 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Tue, 23 Jan 2018 08:43:00 -0600 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] 2 Roll sessions at ietf101 Thread-Index: AQHTk5cagQKS7R02fkCm7IDOuBmQFqOB7k+A Date: Tue, 23 Jan 2018 14:43:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <49AEF4A510EFF04A85DB93CED7462447@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] 2 Roll sessions at 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, 23 Jan 2018 14:43:05 -0000 SWYgSSByZWFkIHlvdSB3ZWxsIHllcyBpdCBpcyBhcyBzaW1wbGUgYXMgdGhhdC4NClRoYXQgd29y a3MgYmVjYXVzZSB0aGUgYWRkaXRpb24gaXMgb25seSBwZXJmb3JtZWQgb24gREFPcyB3aGljaCBh cmUgZXF1aXZhbGVudCB0byBOIFRJRS4gVGhlIGluZm9ybWF0aW9uIGNvdWxkIGJlIGV4Y2hhbmdl ZCBFLVcgYnV0IFJQTCBkb2VzIG5vdCBoYXZlIHRoYXQgZmVhdHVyZSwgbm9yIGRvZXMgRlQgZm9y IHRoZSBtYXR0ZXIuDQoNClRoaW5rIHdoYXQgaGFwcGVucyB3aGVuIGEgbmV3IGVudHJ5IGlzIGFk ZGVkIHRvIGEgZGIgdXNpbmcgQmxvb20gYXMgYSBmcm9udCBlbmQgdG8gZmlndXJlIGlmIHRoZSBl bnRyeSBtYXkgZXhpc3QuIFRoZSBiaXRzIGZvciB0aGF0IGVudHJ5IGFyZSBzaW1wbHkgT1JlZCBp bnRvIHRoZSBmaWx0ZXIuDQoNCg0KVGhlcmUgYXJlIHNsaWRlcyBvbiBpdCBpbiBteSBSUEwgc2hv cnQgY291cnNlIA0KaHR0cHM6Ly93d3cuc2xpZGVzaGFyZS5uZXQvcGFzY2FsdGh1YmVydC9ycGwy MDE4IDsgdGhleSBvbmx5IHNob3cgQklFUiBidXQgSSBkbyBub3Qgc2VlIHdoeSB0aGUgaGFuZGxp bmcgc2hvdWxkIGJlIGFueSBkaWZmZXJlbnQuLi4NCg0KDQpSZWdhcmRzLA0KDQpQYXNjYWwNCg0K PiBMZSAyMiBqYW52LiAyMDE4IMOgIDE2OjM4LCBwZXRlciB2YW4gZGVyIFN0b2sgPHN0b2tjb25z QHhzNGFsbC5ubD4gYSDDqWNyaXQgOg0KPiANCj4gSGkgcm9sbCBXRywNCj4gDQo+IER1cmluZyBp ZXRmMTAwIHdlIGlkZW50aWZpZWQgdHdvIHRvcGljcyB3aGljaCBuZWVkZWQgbW9yZSBkaXNjdXNz aW9uIHRoYW4gY2FuIGJlIGhhbmRsZWQgaW4gMTUgbWludXRlcy4NCj4gVGhlcmVmb3JlLCB3ZSBh c2tlZCBmb3IgdHdvIHNlc3Npb25zIG9mIDIgaG91cnMgZHVyaW5nIHRoZSBpZXRmMTAxIG1lZXRp bmcuDQo+IC0gT25lIHNlc3Npb24gZm9yIHRoZSB0d28gdG9waWNzDQo+IC0gT25lIHNlc3Npb24g Zm9yIHJlZ3VsYXIgUk9MTCBvcGVyYXRpb25zOiBGMkYgZGlzY3Vzc2lvbnMgb2YgZHJhZnRzLg0K PiANCj4gVG8gcmVtaW5kIHlvdSB0aGUgdHdvIHRvcGljcyBhcmUgKGluIG15IHRlcm1pbm9sb2d5 KToNCj4gLSBVc2luZyBzZXZlcmFsIHZlcnNpb25zIG9mIEJJRVIgYXBwcm9hY2ggYW5kIGJsb29t IGZpbHRlcnMgZm9yIHVuaWNhc3QgYW5kIG11bHRpY2FzdA0KPiAtIHVuaWZpZWQgbWV0cmljcyBm b3IgRE9EQUcgY29uc3RydWN0aW9uIGFuZCByb3V0ZXMNCj4gDQo+IEdyZWV0aW5ncywNCj4gDQo+ IFBldGVyDQo+IA0KPiAtLSANCj4gUGV0ZXIgdmFuIGRlciBTdG9rDQo+IHZhbmRlcnN0b2sgY29u c3VsdGFuY3kNCj4gbWFpbHRvOiBjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZw0KPiB3d3c6IHd3 dy52YW5kZXJzdG9rLm9yZw0KPiB0ZWwgTkw6ICszMSgwKTQ5MjQ3NDY3MyAgICAgRjogKzMzKDAp OTY2MDE1MjQ4DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Mon Jan 29 06:55:25 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 524A312EBCA; Mon, 29 Jan 2018 06:55:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151723771828.2974.4196870701520026922@ietfa.amsl.com> Date: Mon, 29 Jan 2018 06:55:18 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-20.txt 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: Mon, 29 Jan 2018 14:55:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : When to use RFC 6553, 6554 and IPv6-in-IPv6 Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-20.txt Pages : 46 Date : 2018-01-29 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required. This analysis provides the basis on which to design efficient compression of these headers. Additionally, this document updates the RFC 6553 adding a change to the RPL Option Type and the RFC 6550 to indicate about this change. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-20 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 29 07:02:47 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 E7DCF1317C6 for ; Mon, 29 Jan 2018 07:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 oqGjEjvtuPFe for ; Mon, 29 Jan 2018 07:02:44 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 A2ECA12EC30 for ; Mon, 29 Jan 2018 07:01:46 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id k131so8643499ith.4 for ; Mon, 29 Jan 2018 07:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKIaIXotWMG0xmq8DWzuoso46TmcHmNF1oAps7SulVs=; b=RN7e+1piyVnSGXD3WplYP/x/LoGMe9ZNMVplxo1nPSByRSFrdXLpsOWaQ4uEJjIrA8 rBCy3EOJjbCmGJ/mxUr4p+6WIHg8SE8vvuUbsiS1stTDtebn3h0A5aZRu9BBIdu4enFS cLSaY3LoB5RDYMieyFbfzfeBWzHB2YW1x4qz7V4U8rdlz2+nvKEUOS4/QJb7JHXJXIHY MR3rkpZrIPn+ZeWjXOzl9b+TxqTm3C/2k3e4SIdgV+i5G6i0YL5jKnct3AbaLM9YdRXN lMkMlhjVawgxadVzD9VhNllK6R/p0wkiLTHwWXarPTxLXI8fvMYfV0RuPQWddQ8eheFq v8KQ== 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:cc; bh=DKIaIXotWMG0xmq8DWzuoso46TmcHmNF1oAps7SulVs=; b=TOxe7pPCprBOVzzz2h0nkriXSTOugQGs9zrRg+eTj3clpNH2Xxnao9Q8e/ApOBDc29 PxjoSyR7OdcHux/Vyw/9BZjO7Zxx0dd4T5LkRnPJn8T3k17V6PEW4gOx8AemD6TFh8mK mOYu3pEEcVimGDmPrYe8AeKjmIaVJwE3V6C4Sshg3idFrz3bkqdy01VxYYxiCg1+CXXo VYsQfMKqdDHxddUR+MoXzmBzJEZH8cnkxDpjd/A04D7OkH13cmonYbLcy47lto/YeaI6 Sw/yORWpqQaiyuDOLOhUD1KYa4sDuAt/KBvePrQQuF0xpjXfjF5Fq/SiDZVuvxAROeGt a4Xw== X-Gm-Message-State: AKwxyteLjpurP2n3mURTYmlK9MCmBLou5FCv2PRb96oWIt9plpG/oqby +cZ1oAA4J2tzHrGgCcZ3X2GRwl7mhsLBUamf8hA= X-Google-Smtp-Source: AH8x226v+LqdvNmCPSPhhlPyWaKK6zz5jvYHxhDIj8oKkv6atao0jPIMGULLY1xeS2DhheZxQskIP29WrhpnZpoXvVI= X-Received: by 10.36.253.140 with SMTP id m134mr9737330ith.85.1517238105613; Mon, 29 Jan 2018 07:01:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.207.7 with HTTP; Mon, 29 Jan 2018 07:01:44 -0800 (PST) In-Reply-To: <21137.1512395590@obiwan.sandelman.ca> References: <71EA7FB9-8BDA-4371-98F5-591803AC6450@gmail.com> <13976.1511987564@obiwan.sandelman.ca> <982B626E107E334DBE601D979F31785C5DB7E556@BLREML503-MBX.china.huawei.com> <21137.1512395590@obiwan.sandelman.ca> From: Ines Robles Date: Mon, 29 Jan 2018 17:01:44 +0200 Message-ID: To: Michael Richardson Cc: Routing Over Low power and Lossy networks , Rahul Jadhav Content-Type: multipart/alternative; boundary="94eb2c11c8a85334ea0563eb8612" Archived-At: Subject: Re: [Roll] Fwd: Review of useofrplinfo-19 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, 29 Jan 2018 15:02:46 -0000 --94eb2c11c8a85334ea0563eb8612 Content-Type: text/plain; charset="UTF-8" Dear all, The new version addresses the depicted issues. Thank you and waiting for your comments. Cheers, The authors. 2017-12-04 15:53 GMT+02:00 Michael Richardson : > > Rahul Arvind Jadhav wrote: > > Point is, there seems no (very less in one case) impact even if > > identification for Raf goes wrong. Or am I missing something very > basic > > here? > > I think that I agree, there is little that breaks. Some extra encapsulation > may occur, as the heuristic breaks for some senders. > > The DODAG root will know the correct information by DAOs in non-storing > mode, > and additionally any 6LRs above the node with the non-PIO address will know > that it's in the DODAG. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --94eb2c11c8a85334ea0563eb8612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

The new version =C2=A0address= es the depicted issues.

Thank you and waiting for = your comments.

Cheers,

Th= e authors.


2017-12-04 15:53 GMT+02:00 Michael Richardson = <mcr+ietf@sandelman.ca>:

Rahul Arvind Jadhav <rahul.ja= dhav@huawei.com> wrote:
=C2=A0 =C2=A0 > Point is, there seems no (very less in one case) impact = even if
=C2=A0 =C2=A0 > identification for Raf goes wrong. Or am I missing somet= hing very basic
=C2=A0 =C2=A0 > here?

I think that I agree, there is little that breaks. Some extra encaps= ulation
may occur, as the heuristic breaks for some senders.

The DODAG root will know the correct information by DAOs in non-storing mod= e,
and additionally any 6LRs above the node with the non-PIO address will know=
that it's in the DODAG.

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




--94eb2c11c8a85334ea0563eb8612--