Jianlin> To repair DODAG, a node multicast a repair request (REQ) Jianlin> message. Upon receiving a REQ message, a neighboring node Jianlin> generates a repair response (REP) message if it has a In a P2MP situation, I think that an end-node won't generate any traffic, so it won't know that the DODAG is broken. How can the end-node know that it should effect repair?

A node=A0should not forward to prefe= red next-hop towice, or it should never forward (while it doesn't know = the path to destination) to a node which already send the packet to it.

----------------

section 5>A new mode of operation (MOP) = that allows a node to choose either
=A0=A0 to implement the storing or n= on-storing features, or both.=A0 The
=A0=A0 changes below are made compa= red to the original storing and non-
=A0=A0 storing modes.

=A0

you may add, that there are a= lot of LLN possibility of it nodes non-store and store modes, as destinatio= ns maybe store or/and non-store and the root also maybe store and/or non-st= ore. IMO, this section is still not complete to cover all possibilities.

=A0

--------------------------------------------------------= -----------------------------------------------------------------------
=
In my work [*] I name this operation mode you refer,=A0as node ability.= The node will choose the mode depending on the ability metric. However, yo= ur draft is interesting because this pathology function will be within the = routing RPL function and depending on OF.

=A0

[*] http://tools.ietf.org/id/draft-baryun-roll-nap-00.txt

=A0

Best Regards

=A0

Abdussalam Baryun=

University of Glamorgan, UK

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--bcaec5016207f3b4e104c776a808-- From jeonggil.ko@gmail.com Fri Aug 17 07:17:23 2012 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 7095411E809C for ; Fri, 17 Aug 2012 07:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prwm9DjAOoea for ; Fri, 17 Aug 2012 07:17:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B96B221F845E for ; Fri, 17 Aug 2012 07:17:22 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3502468pbb.31 for ; Fri, 17 Aug 2012 07:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uCZN8gRRup9sQTzKCCWtbjbKsskNzTZyBPT32Ut2i0Q=; b=zRSnlRQCc9pTZHDN4uVTBtQj+U9Lq8bArIe6P26NahELjt1lZB1Q+Y0kZ+Oa2D3kDG jekR+0O9w8W6W51Lcia2rIaYq7nOXiMm+pPcXA97vftdcbHVorRj15xg0kTuPSLdBdsg 5yTivER3IDHCYpUyGwhZVZzoFCPTka/UZSzhEE9PnpA02jSftp+MVX3JQKkkYX3F8PKT tvlFWohqwsFnSeKhiDcgGqYVRK2zUyedKnRC5PDRERZMo/qxw0ZC1O16wEDlMuputyHT C4tIFXQan3TkUdH7hzePcX8xy/UxCcXghGZpBrEHxztf7pXmfDzRqFmKuQeu1NBGyTpK v/6w== Received: by 10.68.136.40 with SMTP id px8mr11739566pbb.153.1345213042368; Fri, 17 Aug 2012 07:17:22 -0700 (PDT) Received: from [10.211.8.161] ([129.254.38.231]) by mx.google.com with ESMTPS id vh7sm5013964pbc.22.2012.08.17.07.17.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 07:17:21 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: JeongGil Ko In-Reply-To: Date: Fri, 17 Aug 2012 23:17:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: roll Subject: Re: [Roll] New Version Notification for draft-ko-roll-mix-network-pathology-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 14:17:23 -0000 Hi Abdussalam, Thanks for your quick comments :) My comments in-line. On Aug 17, 2012, at 11:06 PM, Abdussalam Baryun wrote: > Hi John, > =20 > I like the work, as I always beleive that LLN is has mixed nodes of = different capabilities, > the work I am doing has in the routing aspects similar which is about = node ability NAP [*]. However, I support your work as well, > =20 > Comments on your draft 00: > = --------------------------------------------------------------------------= -------------------------------------------------- > section 4>N is operating in non-storing mode so without a source = routing > header, it will forward the packet back to S. Thus the packet bounces > between N and S. > =20 > A node should not forward to prefered next-hop towice, or it should = never forward (while it doesn't know the path to destination) to a node = which already send the packet to it. I can improve the text in -01 so that eventually an ICMPv6 error message = is initiated. > ---------------- > section 5>A new mode of operation (MOP) that allows a node to choose = either > to implement the storing or non-storing features, or both. The > changes below are made compared to the original storing and non- > storing modes. > =20 > you may add, that there are alot of LLN possibility of it nodes = non-store and store modes, as destinations maybe store or/and non-store = and the root also maybe store and/or non-store. IMO, this section is = still not complete to cover all possibilities. I see your point (partially). We need to add to the draft that the root = of the DODAG in a MOP 5 operation should have route storing = capabilities. What's really important, as the draft indicates is if the = next hop has route storing capabilities or not. With this determined, if = the next hop is a route storing node the sender can just transmit the = packet right away. On the other hand if the next hop does not have this = capability, a SRH needs to be attached.=20 > =20 > = --------------------------------------------------------------------------= ----------------------------------------------------- >=20 > In my work [*] I name this operation mode you refer, as node ability. = The node will choose the mode depending on the ability metric. However, = your draft is interesting because this pathology function will be within = the routing RPL function and depending on OF. > =20 Not sure here but for sure the proposed draft does not require a = specific OF (if this is what you are implying). As long as there is a = DODAG (constructed with any OF) the proposal is a small addition to the = original storing and non-storing mode implementations.=20 Thanks! -John > [*] http://tools.ietf.org/id/draft-baryun-roll-nap-00.txt > =20 > Best Regards > =20 > Abdussalam Baryun > University of Glamorgan, UK > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Fri Aug 17 07:29:43 2012 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 A4C1E11E8099 for ; Fri, 17 Aug 2012 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF+WKevKiHuw for ; Fri, 17 Aug 2012 07:29:42 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9121F852C for ; Fri, 17 Aug 2012 07:29:42 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4445912ghb.31 for ; Fri, 17 Aug 2012 07:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LfoNRSWofPmfIceq3ELd2fkFWkBTfXaUs+aV9LiGyhs=; b=shUlew6IeeP1y+BWrGdUn2ZAr2Rh5INjVi36MRw8T4h5SzTAEMxBpbLcV6ZUdqTeIO C+kOsfVUH32fiwhaF/v1EWKxoTy0KYrNS2ospCeovuyRu6oc9CG3x2lBevYPpXwtgYN+ MbzemyKolI5ynL4QwT/lQ63Q4Qe9CYvlC/ips1NmTUp2Lx3Ug0xUtC+UQ7+OKlPIVxMO Mumxh4aou3ilbUs+999dJtnUyGzErcVM6EusCzK+FraKaS6MpwVIzkLGIBH9RdryfNFL mUCQL2IprxQD74xmpfD/m9KzIf/gr9zpldEQUNXGVcCD3zfM38vV9UBIO6XKZrDvTpU0 UlEA== MIME-Version: 1.0 Received: by 10.220.119.198 with SMTP id a6mr2748074vcr.23.1345213781887; Fri, 17 Aug 2012 07:29:41 -0700 (PDT) Received: by 10.220.62.77 with HTTP; Fri, 17 Aug 2012 07:29:41 -0700 (PDT) In-Reply-To: References:

Date: Fri, 17 Aug 2012 15:29:41 +0100 Message-ID: From: Abdussalam Baryun To: JeongGil Ko Content-Type: multipart/alternative; boundary=bcaec54fb6249dcba504c776fdd5 Cc: roll Subject: Re: [Roll] New Version Notification for draft-ko-roll-mix-network-pathology-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 17 Aug 2012 14:29:43 -0000 --bcaec54fb6249dcba504c776fdd5 Content-Type: text/plain; charset=ISO-8859-1 Hi John, Thanks, also I want to see more examples of pathology advantages. I just have read quickly through, but happy to discuss the draft in more details when I get more time. AB === On Fri, Aug 17, 2012 at 3:17 PM, JeongGil Ko wrote: > Hi Abdussalam, > > Thanks for your quick comments :) > > My comments in-line. > > On Aug 17, 2012, at 11:06 PM, Abdussalam Baryun wrote: > > > Hi John, > > > > I like the work, as I always beleive that LLN is has mixed nodes of > different capabilities, > > the work I am doing has in the routing aspects similar which is about > node ability NAP [*]. However, I support your work as well, > > > > Comments on your draft 00: > > > ---------------------------------------------------------------------------------------------------------------------------- > > section 4>N is operating in non-storing mode so without a source routing > > header, it will forward the packet back to S. Thus the packet bounces > > between N and S. > > > > A node should not forward to prefered next-hop towice, or it should > never forward (while it doesn't know the path to destination) to a node > which already send the packet to it. > > I can improve the text in -01 so that eventually an ICMPv6 error message > is initiated. > > > ---------------- > > section 5>A new mode of operation (MOP) that allows a node to choose > either > > to implement the storing or non-storing features, or both. The > > changes below are made compared to the original storing and non- > > storing modes. > > > > you may add, that there are alot of LLN possibility of it nodes > non-store and store modes, as destinations maybe store or/and non-store and > the root also maybe store and/or non-store. IMO, this section is still not > complete to cover all possibilities. > > I see your point (partially). We need to add to the draft that the root of > the DODAG in a MOP 5 operation should have route storing capabilities. > What's really important, as the draft indicates is if the next hop has > route storing capabilities or not. With this determined, if the next hop is > a route storing node the sender can just transmit the packet right away. On > the other hand if the next hop does not have this capability, a SRH needs > to be attached. > > > > > > ------------------------------------------------------------------------------------------------------------------------------- > > > > In my work [*] I name this operation mode you refer, as node ability. > The node will choose the mode depending on the ability metric. However, > your draft is interesting because this pathology function will be within > the routing RPL function and depending on OF. > > > > Not sure here but for sure the proposed draft does not require a specific > OF (if this is what you are implying). As long as there is a DODAG > (constructed with any OF) the proposal is a small addition to the original > storing and non-storing mode implementations. > > Thanks! > > -John > > > [*] http://tools.ietf.org/id/draft-baryun-roll-nap-00.txt > > > > Best Regards > > > > Abdussalam Baryun > > University of Glamorgan, UK > > ====================== > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > --bcaec54fb6249dcba504c776fdd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi John,

=A0

Thanks, also I want to see more examp= les of pathology advantages. I just have read quickly through, but happy to= discuss the draft in more details when I get more time.

=A0

=3D=3D=3D

On Fri,= Aug 17, 2012 at 3:17 PM, JeongGil Ko <jeonggil.ko@etri.re.kr>= wrote:

Hi Abdussalam,

Thanks for your quick comments :)

My comments in-line.

On Aug 17, 2012, at 11:06 PM, Abdussalam Baryun wrote:

> Hi John,
>
> I like the work, as I always beleive that LLN is has mixed nodes of di= fferent =A0capabilities,
> the work I am doing has in the routing aspects similar which is about = node ability NAP [*]. However, I support your work as well,
>
> Comments on your draft 00:
> ----------------------------------------------------------------------= ------------------------------------------------------
> section 4>N is operating in non-storing mode so without a source ro= uting
> header, it will forward the packet back to S. Thus the packet bounces<= br> > between N and S.
>
> A node should not forward to prefered next-hop towice, or it should ne= ver forward (while it doesn't know the path to destination) to a node w= hich already send the packet to it.

I can improve the text in -01 so that eventually an ICMPv6 error mess= age is initiated.

> ----------------
> section 5>A new mode of operation (MOP) that allows a node to choos= e either
> =A0 =A0to implement the storing or non-storing features, or both. =A0T= he
> =A0 =A0changes below are made compared to the original storing and non= -
> =A0 =A0storing modes.
>
> you may add, that there are alot of LLN possibility of it nodes non-st= ore and store modes, as destinations maybe store or/and non-store and the r= oot also maybe store and/or non-store. IMO, this section is still not compl= ete to cover all possibilities.

I see your point (partially). We need to add to the draft that the ro= ot of the DODAG in a MOP 5 operation should have route storing capabilities= . What's really important, as the draft indicates is if the next hop ha= s route storing capabilities or not. With this determined, if the next hop = is a route storing node the sender can just transmit the packet right away.= On the other hand if the next hop does not have this capability, a SRH nee= ds to be attached.

>
> ----------------------------------------------------------------------= ---------------------------------------------------------
>
> In my work [*] I name this operation mode you refer, as node ability. = The node will choose the mode depending on the ability metric. However, you= r draft is interesting because this pathology function will be within the r= outing RPL function and depending on OF.
>

Not sure here but for sure the proposed draft does not require a spec= ific OF (if this is what you are implying). As long as there is a DODAG (co= nstructed with any OF) the proposal is a small addition to the original sto= ring and non-storing mode implementations.

Thanks!

-John

> [*] http://tools.ietf.org/id/draft-baryun-roll-nap-00.txt=
>
> Best Regards
>
> Abdussalam Baryun
> University of Glamorgan, UK
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

--bcaec54fb6249dcba504c776fdd5-- From abdussalambaryun@gmail.com Fri Aug 17 23:42:16 2012 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 9DD5A11E80A6 for ; Fri, 17 Aug 2012 23:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r47DeC6nBreh for ; Fri, 17 Aug 2012 23:42:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 821B821F84D7 for ; Fri, 17 Aug 2012 23:42:15 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4163363vcb.31 for ; Fri, 17 Aug 2012 23:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QbcaXqnE6uLWsviGrZOTDVqb2JJuqgmARdxBBySk0/E=; b=Dtzj6RLE0I1E3w5LhBGjNjw9iiod8QBGyTGzB2eCgWj/UeU8urig6wqxPtRAaU9JPU eMf3vizZvm8T8VqXlHsQgOW0p63QzmmtzaKHqOSlLvS9Se32zKIPfdWxjiXBulAFNmTe Qx+zmOy7b0BwIFKa7sFml27ty4eDFGqfLVusPTVBFNR+geWTXgdSJbDTctrkgzBwr46Y JMG8nUauSUiyJEOVF1nZXpPWtFOf2OQVfChISFNAPNgQiZ/K27IqBXY66blZMmuVNzQJ /1cJh6qK0xPXRaPPMkHcD9zZ4I25UAbhQ91EnpGxYARNzh1dPqxfIV4P3OrjbjpyoDQM UXVQ== MIME-Version: 1.0 Received: by 10.58.247.138 with SMTP id ye10mr5040900vec.20.1345272134917; Fri, 17 Aug 2012 23:42:14 -0700 (PDT) Received: by 10.220.62.77 with HTTP; Fri, 17 Aug 2012 23:42:14 -0700 (PDT) In-Reply-To: <088001cd793b$5376ac10$fa640430$@olddog.co.uk> References: <088001cd793b$5376ac10$fa640430$@olddog.co.uk> Date: Sat, 18 Aug 2012 08:42:14 +0200 Message-ID: From: Abdussalam Baryun To: roll Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 06:42:16 -0000 For the progress of this work, I was waiting for a respond from IESG's discuss position members (two positions comments was on draft-05) regarding the new I-D version 07, but still no comments/discuss known. Also waiting for the respond to the return from the WG. The only respond to the IETF-WG's draft-07 is that the document is returned without a reply comments of IESG's discuss position members. However, I will respond to this, that I disagree to return the document until a respond to draft-07 can be tracked, so the WG can decide for progress. AB ----- On 8/13/12, Adrian Farrel wrote: > Yeah, hi. > > I think the thing you are missing is that it had become "impossible" to > resolve > the final Discuss. Of course, as described in the references you cite, > Discusses > must be "resolvable", but the work to resolve this Discuss is considerable > and > results in a significant set of documents being produced. > > The issue was as follows: > > - During processing of draft-ietf-roll-rpl there was a Discuss that said > (approximately) "You haven't done enough security work". > The response was: "Don't worry, it will show up in the security > framework" > - However, the security framework (this draft) simply passes the > buck to other future drafts. > - The Discuss says "show me the security work" > > There was an option to keep this document hanging on while that security > work > was done, or to put in place the plan (as explained by Michael) to run a > series > of documents that will together comprise the security details for RPL. In > that > plan, this document is reworked to be a Threat Analysis simply be removing > some > of the text, and polishing a little. It will then be re-issued, run through > the > WG and completed. > > The I-D did not expire until I marked it "Dead" in the data tracker. That > action > was in agreement with the chairs and as part of the plan for the set of > security > documents. > > Thanks, > Adrian > From adrian@olddog.co.uk Sat Aug 18 12:05:41 2012 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 B08F221F84C9 for ; Sat, 18 Aug 2012 12:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACTLQrX9Tw99 for ; Sat, 18 Aug 2012 12:05:40 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21321F84C8 for ; Sat, 18 Aug 2012 12:05:40 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7IJ5cWe008827; Sat, 18 Aug 2012 20:05:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7IJ5bIV008819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 Aug 2012 20:05:38 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'roll'" Date: Sat, 18 Aug 2012 20:05:33 +0100 Message-ID: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac19dG/XUI2v8VYZTWuRKKRHIlALbQ== Content-Language: en-gb Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 19:05:41 -0000 I don't think Discusses work like that. You don't get to throw new revisions at the IESG and ask them to determine whether the new revision addresses their concerns. The way it works is first you Discuss. Then you agree what changes are going to be made (if any). Then you update the document (if necessary). At this point the AD with the Discuss will be happy to clear. So to turn it around, the AD (who has been patiently holding this Discuss for so long, and who inherited it from his predecessor) is waiting for the working group authors / shepherd to enter into discussion and propose updates. I think I failed on this document when I agreed to the publication request: I should have spotted exactly the issue that the Security ADs complained about. Had I spotted it, I would have returned the I-D to the WG before IESG evaluation. But, look, where is this going? The right thing to do is to publish documents with the right content. As Michael said, the problem with the Security Framework document is that it does not answer the *how* and *why* of what security to apply in what places. While it does an *AWESOME* job of identify threats it doesn't tell us which protocol mechanisms deal with what threats. What we need to do is develop and publish text to address all of these things. There were, thus, two options for this document: 1) Add substantial text to answer the how and why 2) Re-shape it as just a Security Threat Analysis Note that both of these options require the document to be returned to the working group. A third option was rejected in discussions between the WG chair, sponsoring AD, and Discussing AD because both of the ADs agree with the Discuss. 3) Debate and reject the Discuss The authors, chairs, and AD consider option 2) to be more productive. It will result in this document being turned around quickly and re-submitted for publication under a slightly different name with most of its text intact, but with some sections pruned. It will require the new and substantive text to be developed and published in new I-Ds. In sanctioning this approach, the Discussing AD is committing to not re-enter the same Discuss when the Threat Analysis comes before him for evaluation. And he is trusting the WG to do the work on the new drafts. Thanks, Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 18 August 2012 07:42 > To: roll > Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. > > For the progress of this work, I was waiting for a respond from IESG's > discuss position members (two positions comments was on draft-05) > regarding the new I-D version 07, but still no comments/discuss known. > Also waiting for the respond to the return from the WG. The only > respond to the IETF-WG's draft-07 is that the document is returned > without a reply comments of IESG's discuss position members. However, > I will respond to this, that I disagree to return the document until a > respond to draft-07 can be tracked, so the WG can decide for progress. > > AB > ----- > > On 8/13/12, Adrian Farrel wrote: > > Yeah, hi. > > > > I think the thing you are missing is that it had become "impossible" to > > resolve > > the final Discuss. Of course, as described in the references you cite, > > Discusses > > must be "resolvable", but the work to resolve this Discuss is considerable > > and > > results in a significant set of documents being produced. > > > > The issue was as follows: > > > > - During processing of draft-ietf-roll-rpl there was a Discuss that said > > (approximately) "You haven't done enough security work". > > The response was: "Don't worry, it will show up in the security > > framework" > > - However, the security framework (this draft) simply passes the > > buck to other future drafts. > > - The Discuss says "show me the security work" > > > > There was an option to keep this document hanging on while that security > > work > > was done, or to put in place the plan (as explained by Michael) to run a > > series > > of documents that will together comprise the security details for RPL. In > > that > > plan, this document is reworked to be a Threat Analysis simply be removing > > some > > of the text, and polishing a little. It will then be re-issued, run through > > the > > WG and completed. > > > > The I-D did not expire until I marked it "Dead" in the data tracker. That > > action > > was in agreement with the chairs and as part of the plan for the set of > > security > > documents. > > > > Thanks, > > Adrian > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Sun Aug 19 03:37:41 2012 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 1B71821F84F8 for ; Sun, 19 Aug 2012 03:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-NiZCyWR9Yz for ; Sun, 19 Aug 2012 03:37:40 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA6C21F84DD for ; Sun, 19 Aug 2012 03:37:39 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4829194vcb.31 for ; Sun, 19 Aug 2012 03:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7TZAGZ69rJ8VuPePyblAhMR57/zRHa3tggnia4bsv2I=; b=vX9aJuooKoSsdtU1a9KtIujPH5t1OWU6XrUxTejnAqvlZsm/WRoEJVOHr7bXrpjy6V PT/i8pQ5kI7dmiDgRKav029iqFpCw+9jjurgKvC8eK8bv4ruBL4vuzOSt4q+RYbWoRQ0 SkEzwDGIhH8c+MRWT0nGM6il2Gim9rboA7hoyqybJUUj8TllI5SWOzX9L+zytiATAKfr taO0UzaELRUYkzc0fIEEwrMdIMy/FrbIeV6GUjRnrc6sSY+5oOd4asPhso8EJOaI8e6P 3F0Pf1ackvVQLAO+zY1yreVQflv0qd/Lyy90NLehsSCWdV3gzI8rPTODSOrKQBeSLf0/ W+rA== MIME-Version: 1.0 Received: by 10.52.240.230 with SMTP id wd6mr6222009vdc.20.1345372658698; Sun, 19 Aug 2012 03:37:38 -0700 (PDT) Received: by 10.220.62.77 with HTTP; Sun, 19 Aug 2012 03:37:38 -0700 (PDT) In-Reply-To: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> References: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> Date: Sun, 19 Aug 2012 11:37:38 +0100 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf307d00726987b404c79bfb43 Cc: roll Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 19 Aug 2012 10:37:41 -0000 --20cf307d00726987b404c79bfb43 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, I thank you very much, I will do my best in future so this return issue will not happen again. I understand now *how* the discuss process works, thanking you, Best Regards AB ------ On Sat, Aug 18, 2012 at 8:05 PM, Adrian Farrel wrote: > I don't think Discusses work like that. > You don't get to throw new revisions at the IESG and ask them to determine > whether the new revision addresses their concerns. > > The way it works is first you Discuss. Then you agree what changes are > going to > be made (if any). Then you update the document (if necessary). At this > point the > AD with the Discuss will be happy to clear. > > So to turn it around, the AD (who has been patiently holding this Discuss > for so > long, and who inherited it from his predecessor) is waiting for the working > group authors / shepherd to enter into discussion and propose updates. > > I think I failed on this document when I agreed to the publication > request: I > should have spotted exactly the issue that the Security ADs complained > about. > Had I spotted it, I would have returned the I-D to the WG before IESG > evaluation. > > But, look, where is this going? > > The right thing to do is to publish documents with the right content. As > Michael > said, the problem with the Security Framework document is that it does not > answer the *how* and *why* of what security to apply in what places. While > it > does an *AWESOME* job of identify threats it doesn't tell us which protocol > mechanisms deal with what threats. > > What we need to do is develop and publish text to address all of these > things. > There were, thus, two options for this document: > 1) Add substantial text to answer the how and why > 2) Re-shape it as just a Security Threat Analysis > > Note that both of these options require the document to be returned to the > working group. > A third option was rejected in discussions between the WG chair, > sponsoring AD, > and Discussing AD because both of the ADs agree with the Discuss. > 3) Debate and reject the Discuss > > The authors, chairs, and AD consider option 2) to be more productive. It > will > result in this document being turned around quickly and re-submitted for > publication under a slightly different name with most of its text intact, > but > with some sections pruned. It will require the new and substantive text to > be > developed and published in new I-Ds. > > In sanctioning this approach, the Discussing AD is committing to not > re-enter > the same Discuss when the Threat Analysis comes before him for evaluation. > And > he is trusting the WG to do the work on the new drafts. > > Thanks, > Adrian > > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > > Abdussalam Baryun > > Sent: 18 August 2012 07:42 > > To: roll > > Subject: Re: [Roll] draft-ietf-roll-security-framework returned to > working > group. > > > > For the progress of this work, I was waiting for a respond from IESG's > > discuss position members (two positions comments was on draft-05) > > regarding the new I-D version 07, but still no comments/discuss known. > > Also waiting for the respond to the return from the WG. The only > > respond to the IETF-WG's draft-07 is that the document is returned > > without a reply comments of IESG's discuss position members. However, > > I will respond to this, that I disagree to return the document until a > > respond to draft-07 can be tracked, so the WG can decide for progress. > > > > AB > > ----- > > > > On 8/13/12, Adrian Farrel wrote: > > > Yeah, hi. > > > > > > I think the thing you are missing is that it had become "impossible" to > > > resolve > > > the final Discuss. Of course, as described in the references you cite, > > > Discusses > > > must be "resolvable", but the work to resolve this Discuss is > considerable > > > and > > > results in a significant set of documents being produced. > > > > > > The issue was as follows: > > > > > > - During processing of draft-ietf-roll-rpl there was a Discuss that > said > > > (approximately) "You haven't done enough security work". > > > The response was: "Don't worry, it will show up in the security > > > framework" > > > - However, the security framework (this draft) simply passes the > > > buck to other future drafts. > > > - The Discuss says "show me the security work" > > > > > > There was an option to keep this document hanging on while that > security > > > work > > > was done, or to put in place the plan (as explained by Michael) to run > a > > > series > > > of documents that will together comprise the security details for RPL. > In > > > that > > > plan, this document is reworked to be a Threat Analysis simply be > removing > > > some > > > of the text, and polishing a little. It will then be re-issued, run > through > > > the > > > WG and completed. > > > > > > The I-D did not expire until I marked it "Dead" in the data tracker. > That > > > action > > > was in agreement with the chairs and as part of the plan for the set of > > > security > > > documents. > > > > > > Thanks, > > > Adrian > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > --20cf307d00726987b404c79bfb43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Adrian,

=A0

I thank you very=A0 much, I will do= my best in future so this return=A0issue will not happen again. I=A0unders= tand now *how* the discuss process works, thanking you,

=A0

Best Regards

=A0

AB
------

On Sat,= Aug 18, 2012 at 8:05 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

I don't think Discusses work like that.
You don't get to throw new revisions at the IESG and ask them to determ= ine
whether the new revision addresses their concerns.

The way it works is first you Discuss. Then you agree what changes are goin= g to
be made (if any). Then you update the document (if necessary). At this poin= t the
AD with the Discuss will be happy to clear.

So to turn it around, the AD (who has been patiently holding this Discuss f= or so
long, and who inherited it from his predecessor) is waiting for the working=
group =A0authors / shepherd to enter into discussion and propose updates.
I think I failed on this document when I agreed to the publication request:= I
should have spotted exactly the issue that the Security ADs complained abou= t.
Had I spotted it, I would have returned the I-D to the WG before IESG
evaluation.

But, look, where is this going?

The right thing to do is to publish documents with the right content. As Mi= chael
said, the problem with the Security Framework document is that it does not<= br> answer the *how* and *why* of what security to apply in what places. While = it
does an *AWESOME* job of identify threats it doesn't tell us which prot= ocol
mechanisms deal with what threats.

What we need to do is develop and publish text to address all of these thin= gs.
There were, thus, two options for this document:
1) Add substantial text to answer the how and why
2) Re-shape it as just a Security Threat Analysis

Note that both of these options require the document to be returned to the<= br> working group.
A third option was rejected in discussions between the WG chair, sponsoring= AD,
and Discussing AD because both of the ADs agree with the Discuss.
3) Debate and reject the Discuss

The authors, chairs, and AD consider option 2) to be more productive. It wi= ll
result in this document being turned around quickly and re-submitted for publication under a slightly different name with most of its text intact, b= ut
with some sections pruned. It will require the new and substantive text to = be
developed and published in new I-Ds.

In sanctioning this approach, the Discussing AD is committing to not re-ent= er
the same Discuss when the Threat Analysis comes before him for evaluation. = And
he is trusting the WG to do the work on the new drafts.

Thanks,
Adrian

> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Abdussalam Baryun

> Sent: 18 August 2012 07:42
> To: roll
> Subject: Re: [Roll] draft-ietf-roll-security-framework returned to wor= king
group.
>

> For the progress of this= work, I was waiting for a respond from IESG's
> discuss position members (two positions comments was on draft-05)
> regarding the new I-D version 07, but still no comments/discuss known.=
> Also waiting for the respond to the return from the WG. The only
> respond to the IETF-WG's draft-07 is that the document is returned=
> without a reply comments of IESG's discuss position members. Howev= er,
> I will respond to this, that I disagree to return the document until a=
> respond to draft-07 can be tracked, so the WG can decide for progress.=
>
> AB
> -----
>
> On 8/13/12, Adrian Farrel <a= drian@olddog.co.uk> wrote:
> > Yeah, hi.
> >
> > I think the thing you are missing is that it had become "imp= ossible" to
> > resolve
> > the final Discuss. Of course, as described in the references you = cite,
> > Discusses
> > must be "resolvable", but the work to resolve this Disc= uss is considerable
> > and
> > results in a significant set of documents being produced.
> >
> > The issue was as follows:
> >
> > - During processing of draft-ietf-roll-rpl there was a Discuss th= at said
> > =A0 =A0(approximately) "You haven't done enough security= work".
> > =A0 =A0The response was: "Don't worry, it will show up i= n the security
> > =A0 =A0framework"
> > - However, the security framework (this draft) simply passes the<= br> > > =A0 =A0buck to other future drafts.
> > - The Discuss says "show me the security work"
> >
> > There was an option to keep this document hanging on while that s= ecurity
> > work
> > was done, or to put in place the plan (as explained by Michael) t= o run a
> > series
> > of documents that will together comprise the security details for= RPL. In
> > that
> > plan, this document is reworked to be a Threat Analysis simply be= removing
> > some
> > of the text, and polishing a little. It will then be re-issued, r= un through
> > the
> > WG and completed.
> >
> > The I-D did not expire until I marked it "Dead" in the = data tracker. That
> > action
> > was in agreement with the chairs and as part of the plan for the = set of
> > security
> > documents.
> >
> > Thanks,
> > Adrian
> >

> __________________= _____________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

--20cf307d00726987b404c79bfb43-- From abdussalambaryun@gmail.com Sun Aug 19 04:18:09 2012 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 94FE321F84FA for ; Sun, 19 Aug 2012 04:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VTVOhEky7st for ; Sun, 19 Aug 2012 04:18:06 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8366A21F84F8 for ; Sun, 19 Aug 2012 04:18:06 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4844118vcb.31 for ; Sun, 19 Aug 2012 04:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=f7tZ3P8h/V9QbVAQ2ummWKT7eiNartUjpqMJhUgl6BM=; b=DY9MYtM6n6E7E0oRla4aXMkYHtxg4Z5U89Q9cb5/QVui+VCaxkS3lZfutg64Q7/Gux aJqW9mdGDSYyNesc/Xg9WU8Zi8650kMmUQ95LNIfCZVa5sMPLttmMyOTBNU1OCRQBJnr WfDEZeXEopAgdJEJFLk6++IBhgE9EZOgOM/bwiC3K4bzvpYK4mfWaX3oQRV5h6ABweU6 GJpzpJTEcHg2ZTsr8whdB/lOR1Njd8PLk88rxU38u6Ng4k1ZTE2gLW3x93Hafp6Vb1q1 1JmGf6LwzwDsR4czjZJriwJYqdkRNfsndyU3ki2Wrao8pgEIs0QfpxlDcF0/yqmLEqIw EIQA== MIME-Version: 1.0 Received: by 10.52.24.201 with SMTP id w9mr6160259vdf.125.1345375085895; Sun, 19 Aug 2012 04:18:05 -0700 (PDT) Received: by 10.220.62.77 with HTTP; Sun, 19 Aug 2012 04:18:05 -0700 (PDT) In-Reply-To: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> References: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> Date: Sun, 19 Aug 2012 12:18:05 +0100 Message-ID: From: Abdussalam Baryun To: roll Content-Type: multipart/alternative; boundary=bcaec501620715a0d904c79c8cd2 Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 19 Aug 2012 11:18:09 -0000 --bcaec501620715a0d904c79c8cd2 Content-Type: text/plain; charset=ISO-8859-1 > > > The right thing to do is to publish documents with the right content. As > Michael > said, the problem with the Security Framework document is that it does not > answer the *how* and *why* of what security to apply in what places. While > it > does an *AWESOME* job of identify threats it doesn't tell us which protocol > mechanisms deal with what threats. I think the document did n't have to explain *how* and *why*, because this document is an informational framework not a standard/Best-Practice framework. The job of the document was intended to give information of identifying threats. I don't like a documet that has pages more than 50, so I think this document can change its title and scope to clarify its use (threats identification informational I-D), and a future standard I-D of security framwork can have the *how* and *why* related to protocol/mechanism. AB --bcaec501620715a0d904c79c8cd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The right thing to do is to publish documents with the right content. As Mi= chael
said, the problem with the Security Framework document is that it does not<= br> answer the *how* and *why* of what security to apply in what places. While = it
does an *AWESOME* job of identify threats it doesn't tell us which prot= ocol
mechanisms deal with what threats.

=A0

=A0I thin= k the document did n't have to explain *how* and *why*, because this do= cument is an informational framework not a standard/Best-Practice framework= . The job of the document was intended to give information of identifying t= hreats. I don't like a documet that has pages more than 50, so I think = this document can change its title and scope to clarify its use (threats id= entification informational I-D), and a future standard I-D of security fram= work can have the *how* and *why* related to protocol/mechanism.

=A0

--bcaec501620715a0d904c79c8cd2-- From mcr@sandelman.ca Mon Aug 20 07:09:47 2012 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 A057621F8681 for ; Mon, 20 Aug 2012 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMYuc2mIPrgY for ; Mon, 20 Aug 2012 07:09:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6C421F8629 for ; Mon, 20 Aug 2012 07:09:41 -0700 (PDT) Received: from sandelman.ca (24-139-16-154.eastlink.ca [24.139.16.154]) by relay.sandelman.ca (Postfix) with ESMTPS id 0EFE88655; Mon, 20 Aug 2012 10:04:33 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4481ACA0C7; Sun, 19 Aug 2012 14:54:36 -0400 (EDT) From: Michael Richardson To: Abdussalam Baryun In-reply-to: References: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> Comments: In-reply-to Abdussalam Baryun message dated "Sun, 19 Aug 2012 12:18:05 +0100." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) Date: Sun, 19 Aug 2012 14:54:36 -0400 Message-ID: <27653.1345402476@sandelman.ca> Sender: mcr@sandelman.ca Cc: roll Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 14:09:47 -0000 <#part sign=pgpmime> >>>>> "Abdussalam" == Abdussalam Baryun writes: Abdussalam> I think the document did n't have to explain *how* and Abdussalam> *why*, because this document is an informational Abdussalam> framework not a standard/Best-Practice framework. The Some document, somewhere has to specify. This document was conceived of as going to do that. That it was presented as Informational was perhaps a mistake. -- Michael Richardson -at the cottage- From abdussalambaryun@gmail.com Mon Aug 20 08:47:53 2012 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 DA84121F84A1 for ; Mon, 20 Aug 2012 08:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRi+o0vCalXP for ; Mon, 20 Aug 2012 08:47:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 164BE21F8498 for ; Mon, 20 Aug 2012 08:47:53 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6322576vbb.31 for ; Mon, 20 Aug 2012 08:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oeCItH3SfMXTI66zTOlbn3lyM+f7V7laEH06OFWshFw=; b=DDeS5pLepUE91QXIeXvQtsJtwh4t7l+Ib6G7z/7D70zIx2YnFx07aD/v42BaicB/Ii V/Icff0BqQM8gQa+HN08tdsYwbNn7hR5llCwy6wbH9qlQ5oIFqF8qgjHJvstXq14TVan /WV4VYHy81dxWy6V08Mr37pm5CBvO4rxvEYU+2O//dyQ2gabyRyHIBUGg0QkTGnbP4hT CI73GSAdriA8+6Ujvke1oA26BpGtyOFBfmbEwi1smWjgcM33TptPTJsvjYZzdhD6iH6P 3g8GLXKHrIWEtbFvpQDaj4TBcO2xxV+0MBPB1ZzoYUf5dU2a04mrifasKainAhy8wGgY ZO8w== MIME-Version: 1.0 Received: by 10.58.247.138 with SMTP id ye10mr11698718vec.20.1345477672480; Mon, 20 Aug 2012 08:47:52 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Mon, 20 Aug 2012 08:47:52 -0700 (PDT) In-Reply-To: <27653.1345402476@sandelman.ca> References: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> <27653.1345402476@sandelman.ca> Date: Mon, 20 Aug 2012 16:47:52 +0100 Message-ID: From: Abdussalam Baryun To: roll Content-Type: multipart/alternative; boundary=047d7bea44bab8b01404c7b46e8d Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 20 Aug 2012 15:47:54 -0000 --047d7bea44bab8b01404c7b46e8d Content-Type: text/plain; charset=ISO-8859-1 I do not know why the direction is to have a security framework draft in our working-stage in the first place, while we still have some issues related to RPL and applicability, but it was ok to have an informational of LLN routing threats without *why* and *how* of securing, as the way the authors focused on threats. Until we complete applicability and RPL performance (obtain large scale evaluiation results), then we may look into security techniques related to RPL (documents only need security considerations section not details), because we do routings (security functions is done in IETF Security Area). >That it was presented as Informational was perhaps a mistake. If not having an informational framework, then I suggest to make the new produced document attached to a mechanim or protocol (as MANET WG do), for example: RPL-SEC, RPL.P2P-SEC, etc. without having a new document for threat analysis. I ask the WG to discuss this issue, Regards AB ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I maybe wrong and maybe right but it does not matter if we work as a group. IETF WGs are always right. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --------------------------- On Sun, Aug 19, 2012 at 7:54 PM, Michael Richardson wrote: > <#part sign=pgpmime> > > >>>>> "Abdussalam" == Abdussalam Baryun > writes: > Abdussalam> I think the document did n't have to explain *how* and > Abdussalam> *why*, because this document is an informational > Abdussalam> framework not a standard/Best-Practice framework. The > > Some document, somewhere has to specify. > This document was conceived of as going to do that. > That it was presented as Informational was perhaps a mistake. > > -- > Michael Richardson > -at the cottage- > --047d7bea44bab8b01404c7b46e8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I do not know why the direction is to have a security framework draft in= our working-stage in the first place, while we still have some issues rela= ted to RPL and applicability, but it was ok to have an informational of LLN= routing threats without *why* and *how* of securing, as the way the author= s=A0focused on threats. Until we complete applicability and RPL performance= (obtain large scale evaluiation results), then we may look into security t= echniques related to RPL=A0(documents only need security considerations sec= tion not details), because we do routings (security functions=A0is done in = IETF Security Area).

>That it was presented as Informational was perhaps a mistake.

If not having an informational framework, then I suggest to make the new = produced document attached to a mechanim or protocol (as MANET WG do), for = example: RPL-SEC, RPL.P2P-SEC, etc. without having a new=A0document for thr= eat analysis.

=A0

I ask the WG to discuss this issue,

Regards

<= div>AB

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=

I maybe wrong and maybe right but it does not matter if we work = as a group.

IETF WGs are always right.

+++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++

---------------------------
On S= un, Aug 19, 2012 at 7:54 PM, Michael Richardson <mcr+ietf@sandelman.ca= > wrote:

<#part sign=3Dpgpmime&= gt;

>>>>> "Abdussalam" =3D=3D Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; writes:
=A0 =A0 Abdussalam> =A0I think the document did n't have to explain = *how* and
=A0 =A0 Abdussalam> *why*, because this document is an informational
=A0 =A0 Abdussalam> framework not a standard/Best-Practice framework. Th= e

Some document, somewhere has to specify.
This document was conceived of as going to do that.
That it was presented as Informational was perhaps a mistake.

--
Michael Richardson
-at the cottage-

--047d7bea44bab8b01404c7b46e8d-- From jreddy@ti.com Mon Aug 20 17:09:40 2012 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 497B421F8567 for ; Mon, 20 Aug 2012 17:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq7h6uX0z2a1 for ; Mon, 20 Aug 2012 17:09:39 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCBF21F852C for ; Mon, 20 Aug 2012 17:09:39 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q7L09cv6002507 for ; Mon, 20 Aug 2012 19:09:38 -0500 Received: from DFLE73.ent.ti.com (dfle73.ent.ti.com [128.247.5.110]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q7L09chO016837 for ; Mon, 20 Aug 2012 19:09:38 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE73.ent.ti.com ([fe80::86e:fab6:cd95:e158%28]) with mapi id 14.01.0323.003; Mon, 20 Aug 2012 19:09:38 -0500 From: "Reddy, Joseph" To: "roll@ietf.org" Thread-Topic: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) Thread-Index: Ac1/LcJP4zD50EKARum3ByfgDIkDcg== Date: Tue, 21 Aug 2012 00:09:37 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA7669C@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.247.5.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 00:09:40 -0000 Hi Jonathan, Richard, I reviewed the proposed changes in your draft and agree with them. I would = like to see them in a revised WG draft with these changes so we can make pr= ogress on this. We have also implemented this protocol (in proactive propag= ation mode) and successfully tested against a few other implementations.=20 A few comments on the proposed text: Section 2: The term "MPL forwarder" is not very clear as MPL is restricted to transmit= packets on the same interface that it receives, so it is not a typical rou= ter. Suggest using a different term or update terminology to describe that = it is limited to forwarding on a single interface. =20 Section 4.1 The previous draft had an 'M' bit to indicate which set of trickle paramete= rs to use and that is missing now (actually, it is reused for a different p= urpose). I believe that is a useful flag to include as it allows control of= the latency/reliability tradeoff in a LLN network. I suggest adding that b= ack in.=20 Section 4.1 Include an explicit (2-bit?) version number in the MPL option.=20 The remaining rsv bits should have the description modified so they can "se= t to zero for outgoing messages and ignored upon reception for incoming mes= sages" -Regards, Joseph -----Original Message----- Date: Fri, 3 Aug 2012 17:48:11 +0000 From: "Jonathan Hui (johui)" To: "roll@ietf.org" Subject: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) Message-ID: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> Content-Type: text/plain; charset=3D"us-ascii" We've been working on an update to draft-ietf-roll-trickle-mcast. I've att= ached a draft of the proposed text. Note that we will *not* be presenting = this draft at the ROLL WG meeting. In a prior mail, I noted some deficiencies with the initial draft that was = posted. We will discuss some of these deficiencies at the ROLL WG meeting = today. The purpose of this mail is to give you some insight into solving t= hose deficiencies as well as incorporating suggestions that were brought up= on the list. If you get a chance to glance through before the WG meeting,= great. In either case, let's continue the discussion on the list. Always looking for your feedback, especially from implementors. Thanks! -- Jonathan Hui -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-ietf-roll-trickle-mcast-new.txt URL: ------------------------------ From gnawali@cs.uh.edu Tue Aug 21 09:32:03 2012 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 3373621F87B6 for ; Tue, 21 Aug 2012 09:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.806 X-Spam-Level: X-Spam-Status: No, score=-5.806 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GEKFDnSIQuQ for ; Tue, 21 Aug 2012 09:32:02 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4248C21F87B7 for ; Tue, 21 Aug 2012 09:32:02 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id CCBFB23CA84 for ; Tue, 21 Aug 2012 11:31:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp5Nf3Y1t9N1 for ; Tue, 21 Aug 2012 11:31:54 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 5D82923CA8A for ; Tue, 21 Aug 2012 11:31:54 -0500 (CDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by it.cs.uh.edu (Postfix) with ESMTP id 911392A2807B for ; Tue, 21 Aug 2012 11:35:09 -0500 (CDT) Received: by qcac10 with SMTP id c10so5911329qca.31 for ; Tue, 21 Aug 2012 09:31:58 -0700 (PDT) Received: by 10.58.201.195 with SMTP id kc3mr15306997vec.12.1345566718314; Tue, 21 Aug 2012 09:31:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.41 with HTTP; Tue, 21 Aug 2012 09:31:38 -0700 (PDT) From: Omprakash Gnawali Date: Tue, 21 Aug 2012 09:31:38 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 16:32:03 -0000 Dear ROLL WG, John Ko posted a draft a few days ago about how we might accommodate a mixture of storing and non-storing nodes in a network more efficiently than making one of them leaf nodes. Searching through the ROLL mail archives, it was clear at the time that there was no use case for having a network that has a mixture of storing and non-storing nodes. I wonder if this is necessarily true if there are devices from multiple vendors. At the time, it was also speculated that the mixture could also introduce unknown problems and no one seems to have a working solution. The draft describes one of the problems that could occur if we try to form a multi-hop network with storing and non-storing nodes. That is a concrete first step towards getting a handle on the challenge of having nodes with different capabilities in a network. Your guidance on whether this is an important problem worth working on or the work is heading in a wrong direction would help evolve or stop the work. Thanks. - om_p From abdussalambaryun@gmail.com Tue Aug 21 11:16:57 2012 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 2141A21F869C for ; Tue, 21 Aug 2012 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx43Q+1TSMMM for ; Tue, 21 Aug 2012 11:16:56 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8C21F8608 for ; Tue, 21 Aug 2012 11:16:56 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so112383vcb.31 for ; Tue, 21 Aug 2012 11:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=x/ZIvPZGeHS8Vfd+Xd4YKtw3gH+tznwp3aaLPcncnU0=; b=SXy8T2/YVRoXrpYCEHRm+9IWI7hjRCjfllIOzSVolA0BJZg8t+uYJ5B6Urb5njpi/R 24x1K1zVsiO10jnJNg3lZzxuHZeKw3SHHtCHspyJg6v8MfSOQuEBZnd/+9QXqrCBUPhg q3EiZJENHTsgEeicDD8/f8X+OJlLq264IhWuDhvbkBBKaaP7H/vXXPeg5e/8fl2MXxoN kuJGwTwq2cfnB3DKtAMiQEchLDyD5KTL2q2XsZMctg6onQq6W8juM1BBDOJ1H1tiZpme JfsQoOcXtca6/tb7WGyC5fhW3SS0p/fmfy4oNyztAZXaPPigeAWilE7o2S/gedL1Fuce mwAg== MIME-Version: 1.0 Received: by 10.52.240.230 with SMTP id wd6mr12176268vdc.20.1345573015855; Tue, 21 Aug 2012 11:16:55 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Tue, 21 Aug 2012 11:16:55 -0700 (PDT) Date: Tue, 21 Aug 2012 19:16:55 +0100 Message-ID: From: Abdussalam Baryun To: gnawali@cs.uh.edu Content-Type: multipart/alternative; boundary=20cf307d0072a1229f04c7caa1fe Cc: roll Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 18:16:57 -0000 --20cf307d0072a1229f04c7caa1fe Content-Type: text/plain; charset=ISO-8859-1 Hi Omprakash, I agree with you that it is important for LLNs, but I already am working on the solution in my draft NAP, which I believe can help and needs more modification, I hope you can comment on the work or advise me how to make it solve the problem. http://www.ietf.org/id/draft-baryun-roll-nap-00.txt Best Regards Abdussalam ----------------------------------------------------------------- Dear ROLL WG, John Ko posted a draft a few days ago about how we might accommodate a mixture of storing and non-storing nodes in a network more efficiently than making one of them leaf nodes. Searching through the ROLL mail archives, it was clear at the time that there was no use case for having a network that has a mixture of storing and non-storing nodes. I wonder if this is necessarily true if there are devices from multiple vendors. At the time, it was also speculated that the mixture could also introduce unknown problems and no one seems to have a working solution. The draft describes one of the problems that could occur if we try to form a multi-hop network with storing and non-storing nodes. That is a concrete first step towards getting a handle on the challenge of having nodes with different capabilities in a network. Your guidance on whether this is an important problem worth working on or the work is heading in a wrong direction would help evolve or stop the work. Thanks. - om_p --20cf307d0072a1229f04c7caa1fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Omprakash,

=A0

I agree with you that it is impo= rtant for LLNs, but I already am working on the solution in my draft NAP, w= hich I believe can help and needs more modification, I hope you can comment= on the work or advise me how to make it solve the problem.

=A0

http://www.ietf.org/id/draft-baryun-roll-nap-00.txt

= =A0

Best Regards

Abdussalam

=A0

---= --------------------------------------------------------------

Dear ROLL WG,

John Ko posted a draft a few days ago about how w= e might accommodate a
mixture of storing and non-storing nodes in a netw= ork more efficiently
than making one of them leaf nodes. Searching throu= gh the ROLL mail
archives, it was clear at the time that there was no use case for
having= a network that has a mixture of storing and non-storing nodes.
I wonder= if this is necessarily true if there are devices from
multiple vendors.= At the time, it was also speculated that the mixture
could also introduce unknown problems and no one seems to have a
working= solution. The draft describes one of the problems that could
occur if w= e try to form a multi-hop network with storing and
non-storing nodes. Th= at is a concrete first step towards getting a
handle on the challenge of having nodes with different capabilities in
a= network.

Your guidance on whether this is an important problem wort= h working on
or the work is heading in a wrong direction would help evol= ve or stop
the work.

Thanks.

- om_p

--20cf307d0072a1229f04c7caa1fe-- From abdussalambaryun@gmail.com Tue Aug 21 11:33:22 2012 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 DEFFF21F8597 for ; Tue, 21 Aug 2012 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8dHCAWd56Rv for ; Tue, 21 Aug 2012 11:33:22 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFF521F84A0 for ; Tue, 21 Aug 2012 11:33:21 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so131410vcb.31 for ; Tue, 21 Aug 2012 11:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UJs6QfT21ibWFXoOCzz+qrSvyyvqfRjAzrRt3UBiC2w=; b=KaH6WzwFZ9ma6LtDwqPxiQ6skH1D0MBo3C3Dm0HPRTt3nOExZXNThg4/3T/7oN3X2e v8yF44Po8Ycl4zwnFxZy5b2Hgy9DeuUaK1sSw58kKOSxBtKyNp2maKWLZqXPU2gzFfYL G9DNLMdtAXfOwkmfJbrveFHXuoCev2daUAIUzA6mVUFJ6wrgvehjZmlRt2cdLkmEtXca aNZOq9FRzl875eyNLqBvJf5bMOYnZMEbsB3XG0fQNLBPuMNkfM/JQMNXBXb1vvqgPEIY Y4p8Ky7t1U7FwaIznLNzQ2RNQOQTyWerFOI51iO/KmjNdBHWMkad3ILj6tDiJCVPKW66 8VMQ== MIME-Version: 1.0 Received: by 10.52.240.230 with SMTP id wd6mr12209876vdc.20.1345574001277; Tue, 21 Aug 2012 11:33:21 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Tue, 21 Aug 2012 11:33:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Aug 2012 19:33:21 +0100 Message-ID: From: Abdussalam Baryun To: gnawali@cs.uh.edu Content-Type: multipart/alternative; boundary=20cf307d00725d7c5f04c7cadc94 Cc: roll Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 18:33:23 -0000 --20cf307d00725d7c5f04c7cadc94 Content-Type: text/plain; charset=ISO-8859-1 Hi Omprakash >The draft describes one of the problems that could occur if we try to form a multi-hop network with storing and non-storing nodes. That is a concrete first step towards getting a handle on the challenge of having nodes with different capabilities in a network. Please not that NAP draft is a first step to handle different capabilities, you may missed it when I described the problem in june and posted the draft in first august. However, I like that we share the importance of the *mixture abilities* idea now and that we can work together to solve the problem. AB ----- On Tue, Aug 21, 2012 at 7:16 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Omprakash, > > I agree with you that it is important for LLNs, but I already am working > on the solution in my draft NAP, which I believe can help and needs more > modification, I hope you can comment on the work or advise me how to make > it solve the problem. > > http://www.ietf.org/id/draft-baryun-roll-nap-00.txt > > Best Regards > Abdussalam > > ----------------------------------------------------------------- > Dear ROLL WG, > > John Ko posted a draft a few days ago about how we might accommodate a > mixture of storing and non-storing nodes in a network more efficiently > than making one of them leaf nodes. Searching through the ROLL mail > archives, it was clear at the time that there was no use case for > having a network that has a mixture of storing and non-storing nodes. > I wonder if this is necessarily true if there are devices from > multiple vendors. At the time, it was also speculated that the mixture > could also introduce unknown problems and no one seems to have a > working solution. The draft describes one of the problems that could > occur if we try to form a multi-hop network with storing and > non-storing nodes. That is a concrete first step towards getting a > handle on the challenge of having nodes with different capabilities in > a network. > > Your guidance on whether this is an important problem worth working on > or the work is heading in a wrong direction would help evolve or stop > the work. > > Thanks. > > - om_p > --20cf307d00725d7c5f04c7cadc94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Omprakash

=A0

>The draft describes one of th= e problems that could
occur if we try to form a multi-hop network with s= toring and
non-storing nodes. That is a concrete first step towards gett= ing a
handle on the challenge of having nodes with different capabilities in
a= network.

Please not that NAP draft is=A0a first step to hand= le different capabilities, you may missed it when I described the problem i= n june and posted the draft in first august. However, I like that we share = the importance of the *mixture abilities* idea now and that we can work tog= ether to solve the problem.

=A0

AB
-----

On Tue, = Aug 21, 2012 at 7:16 PM, Abdussalam Baryun <abdussalambaryun@gmai= l.com> wrote:

Hi Omprakash,
=A0
I agree with yo= u that it is important for LLNs, but I already am working on the solution i= n my draft NAP, which I believe can help and needs more modification, I hop= e you can comment on the work or advise me how to make it solve the problem= .

=A0
http://www.ietf.org/id/draft-baryun-roll-nap-00.t= xt
=A0
Best Regards
Abdussalam
= =A0

-----------------------------------------------------------------
Dear ROLL WG,

John Ko posted a draft a few days ago about how w= e might accommodate a
mixture of storing and non-storing nodes in a netw= ork more efficiently
than making one of them leaf nodes. Searching throu= gh the ROLL mail
archives, it was clear at the time that there was no use case for
having= a network that has a mixture of storing and non-storing nodes.
I wonder= if this is necessarily true if there are devices from
multiple vendors.= At the time, it was also speculated that the mixture
could also introduce unknown problems and no one seems to have a
working= solution. The draft describes one of the problems that could
occur if w= e try to form a multi-hop network with storing and
non-storing nodes. Th= at is a concrete first step towards getting a
handle on the challenge of having nodes with different capabilities in
a= network.

Your guidance on whether this is an important problem wort= h working on
or the work is heading in a wrong direction would help evol= ve or stop
the work.

Thanks.

- om_p

--20cf307d00725d7c5f04c7cadc94-- From gnawali@cs.uh.edu Tue Aug 21 11:59:08 2012 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 61C7421F86C7 for ; Tue, 21 Aug 2012 11:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+W3XJxRY-PN for ; Tue, 21 Aug 2012 11:59:08 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id E506221F86B3 for ; Tue, 21 Aug 2012 11:59:07 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 9FE6A23CA8A for ; Tue, 21 Aug 2012 13:59:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUMtqZ8bHwPf for ; Tue, 21 Aug 2012 13:59:00 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A336223CA8E for ; Tue, 21 Aug 2012 13:59:00 -0500 (CDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by it.cs.uh.edu (Postfix) with ESMTP id 523872A280C4 for ; Tue, 21 Aug 2012 14:02:16 -0500 (CDT) Received: by vcbfo14 with SMTP id fo14so162088vcb.31 for ; Tue, 21 Aug 2012 11:59:04 -0700 (PDT) Received: by 10.52.178.106 with SMTP id cx10mr5168155vdc.55.1345575544595; Tue, 21 Aug 2012 11:59:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.41 with HTTP; Tue, 21 Aug 2012 11:58:44 -0700 (PDT) In-Reply-To: References: From: Omprakash Gnawali Date: Tue, 21 Aug 2012 11:58:44 -0700 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 21 Aug 2012 18:59:08 -0000 On Tue, Aug 21, 2012 at 11:33 AM, Abdussalam Baryun wrote: > Hi Omprakash > >>The draft describes one of the problems that could > occur if we try to form a multi-hop network with storing and > non-storing nodes. That is a concrete first step towards getting a > handle on the challenge of having nodes with different capabilities in > a network. > Please not that NAP draft is a first step to handle different capabilities, > you may missed it when I described the problem in june and posted the draft > in first august. However, I like that we share the importance of the > *mixture abilities* idea now and that we can work together to solve the > problem. Did you get a sense from the WG that this is an important problem? We can find many ways to extend and enhance every protocol but choose to work on a subset that is most relevant to those who are building devices and deploying networks. Ko's draft talks about how to do multi-hop routing with storing and non-storing nodes. Your draft talks about discovering if nodes are able to participate due to various constraints. They seem different to me but are not mutually exclusive. - om_p From jsjeong@etri.re.kr Tue Aug 21 17:39:51 2012 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 266D021F8559 for ; Tue, 21 Aug 2012 17:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.896 X-Spam-Level: X-Spam-Status: No, score=-94.896 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Przr5G7FCNBp for ; Tue, 21 Aug 2012 17:39:50 -0700 (PDT) Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9A21F8555 for ; Tue, 21 Aug 2012 17:39:50 -0700 (PDT) Received: from SMTPEG2.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id q7M0dhwF021664; Wed, 22 Aug 2012 09:39:44 +0900 Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 22 Aug 2012 09:39:46 +0900 Received: from SMTP4.etri.info ([169.254.3.84]) by SMTP3.etri.info ([169.254.4.38]) with mapi id 14.01.0355.002; Wed, 22 Aug 2012 09:39:40 +0900 From: =?euc-kr?B?waTBvrz2?= To: Abdussalam Baryun Thread-Topic: [Roll] mixture of storing and non-storing nodes Thread-Index: AQHNf8kla3ul5GjnHEWCevy5tyL565dkAG+AgAAHFwCAAF9BgA== Date: Wed, 22 Aug 2012 00:39:40 +0000 Message-ID: <8033D2D3-CCC0-4F1E-B1D1-A9510DA75BAF@etri.re.kr> References:

In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.192.201] Content-Type: text/plain; charset="euc-kr" Content-ID: <4463FE6FAA42D8438F3576DAE47C3604@etri.re.kr> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: roll Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2012 00:39:51 -0000 SGkgQUIsDQoNCkkgYWxzbyBhZ3JlZSB3aXRoIE9tcHJha2FzaC4gS28ncyBkcmFmdCBkZXNjcmli ZXMgYSBuZXcgUlBMIG9wZXJhdGlvbiBtb2RlIHdoaWxlIHlvdXIgZHJhZnQgZGVzY3JpYmVzIG5v ZGVzJyBhYmlsaXR5IChmdW5jdGlvbnMgYW5kIHJlc291cmNlcykgYWR2ZXJ0aXNlbWVudC9kaXNj b3ZlcnkgaW4gYSBnaXZlbiBvcGVyYXRpb24gbW9kZS4NCg0KLUpvbmdzb28NCg0KMjAxMi4gOC4g MjIuLCC/wMD8IDM6NTgsIE9tcHJha2FzaCBHbmF3YWxpIDxnbmF3YWxpQGNzLnVoLmVkdT4NCiDA 27y6Og0KDQo+IA0KPiBPbiBUdWUsIEF1ZyAyMSwgMjAxMiBhdCAxMTozMyBBTSwgQWJkdXNzYWxh bSBCYXJ5dW4NCj4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPiB3cm90ZToNCj4+IEhpIE9t cHJha2FzaA0KPj4gDQo+Pj4gVGhlIGRyYWZ0IGRlc2NyaWJlcyBvbmUgb2YgdGhlIHByb2JsZW1z IHRoYXQgY291bGQNCj4+IG9jY3VyIGlmIHdlIHRyeSB0byBmb3JtIGEgbXVsdGktaG9wIG5ldHdv cmsgd2l0aCBzdG9yaW5nIGFuZA0KPj4gbm9uLXN0b3Jpbmcgbm9kZXMuIFRoYXQgaXMgYSBjb25j cmV0ZSBmaXJzdCBzdGVwIHRvd2FyZHMgZ2V0dGluZyBhDQo+PiBoYW5kbGUgb24gdGhlIGNoYWxs ZW5nZSBvZiBoYXZpbmcgbm9kZXMgd2l0aCBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzIGluDQo+PiBh IG5ldHdvcmsuDQo+PiBQbGVhc2Ugbm90IHRoYXQgTkFQIGRyYWZ0IGlzIGEgZmlyc3Qgc3RlcCB0 byBoYW5kbGUgZGlmZmVyZW50IGNhcGFiaWxpdGllcywNCj4+IHlvdSBtYXkgbWlzc2VkIGl0IHdo ZW4gSSBkZXNjcmliZWQgdGhlIHByb2JsZW0gaW4ganVuZSBhbmQgcG9zdGVkIHRoZSBkcmFmdA0K Pj4gaW4gZmlyc3QgYXVndXN0LiBIb3dldmVyLCBJIGxpa2UgdGhhdCB3ZSBzaGFyZSB0aGUgaW1w b3J0YW5jZSBvZiB0aGUNCj4+ICptaXh0dXJlIGFiaWxpdGllcyogaWRlYSBub3cgYW5kIHRoYXQg d2UgY2FuIHdvcmsgdG9nZXRoZXIgdG8gc29sdmUgdGhlDQo+PiBwcm9ibGVtLg0KPiANCj4gRGlk IHlvdSBnZXQgYSBzZW5zZSBmcm9tIHRoZSBXRyB0aGF0IHRoaXMgaXMgYW4gaW1wb3J0YW50IHBy b2JsZW0/IFdlDQo+IGNhbiBmaW5kIG1hbnkgd2F5cyB0byBleHRlbmQgYW5kIGVuaGFuY2UgZXZl cnkgcHJvdG9jb2wgYnV0IGNob29zZSB0bw0KPiB3b3JrIG9uIGEgc3Vic2V0IHRoYXQgaXMgbW9z dCByZWxldmFudCB0byB0aG9zZSB3aG8gYXJlIGJ1aWxkaW5nDQo+IGRldmljZXMgYW5kIGRlcGxv eWluZyBuZXR3b3Jrcy4NCj4gDQo+IEtvJ3MgZHJhZnQgdGFsa3MgYWJvdXQgaG93IHRvIGRvIG11 bHRpLWhvcCByb3V0aW5nIHdpdGggc3RvcmluZyBhbmQNCj4gbm9uLXN0b3Jpbmcgbm9kZXMuIFlv dXIgZHJhZnQgdGFsa3MgYWJvdXQgZGlzY292ZXJpbmcgaWYgbm9kZXMgYXJlDQo+IGFibGUgdG8g cGFydGljaXBhdGUgZHVlIHRvIHZhcmlvdXMgY29uc3RyYWludHMuIFRoZXkgc2VlbSBkaWZmZXJl bnQgdG8NCj4gbWUgYnV0IGFyZSBub3QgbXV0dWFsbHkgZXhjbHVzaXZlLg0KPiANCj4gLSBvbV9w DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJv bGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsDQoNCg== From jvasseur@cisco.com Tue Aug 21 23:15:10 2012 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 A5E9E11E80DB for ; Tue, 21 Aug 2012 23:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcYftzPb3mgg for ; Tue, 21 Aug 2012 23:15:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0C11E80D5 for ; Tue, 21 Aug 2012 23:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1645; q=dns/txt; s=iport; t=1345616106; x=1346825706; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=k0/PYEFh5IQh7Z+BgT2pCFZ4R7S68539xo3ECTT+g+A=; b=PnXHqr/1yJQRLkj/esDgRzW7laeyBz7VHVeMyY75LOHIAC98Kr8P2QTy siVvtWSuOyOJfcmiZnfWTvBUx1VbBrddv/o2JFVCvGT51fqhWmu+S/jza CZFK2WWTxv4QYe5F/TgJDT9jiddGJUn+W4JKaYvHQ0Qp29IgZl9vg9BNe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPh3NFCtJV2d/2dsb2JhbABFDrpUgQeCIAEBAQMBAQEBDwEnNBALAgEINhAnCyUCBAESGweHZQYLmSCgOQSLCBqGImADlVKOLYFmgic6gWE X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="114079520" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 22 Aug 2012 06:15:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7M6F5fZ014371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 06:15:05 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.209]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 01:15:05 -0500 From: "JP Vasseur (jvasseur)" To: roll WG , Omprakash Gnawali Thread-Topic: [Roll] mixture of storing and non-storing nodes Thread-Index: AQHNgC14aerYJYORe0Sa2/SEM2k1rg== Date: Wed, 22 Aug 2012 06:15:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.95.148] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.004 x-tm-as-result: No--42.329900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2012 06:15:10 -0000 Hi, On Aug 21, 2012, at 6:31 PM, Omprakash Gnawali wrote: > Dear ROLL WG, >=20 > John Ko posted a draft a few days ago about how we might accommodate a > mixture of storing and non-storing nodes in a network more efficiently > than making one of them leaf nodes. Searching through the ROLL mail > archives, it was clear at the time that there was no use case for > having a network that has a mixture of storing and non-storing nodes. > I wonder if this is necessarily true if there are devices from > multiple vendors. At the time, it was also speculated that the mixture > could also introduce unknown problems and no one seems to have a > working solution. The draft describes one of the problems that could > occur if we try to form a multi-hop network with storing and > non-storing nodes. That is a concrete first step towards getting a > handle on the challenge of having nodes with different capabilities in > a network. >=20 > Your guidance on whether this is an important problem worth working on > or the work is heading in a wrong direction would help evolve or stop > the work. >=20 JP> I cannot agree more - actually we even have a partial to the problem du= ring the initial design phase and the WG collectively decided not to mix storing and non-storing in light of = the added complexity. I would also appreciate the feedback of the WG on this, and not add complexity unless th= is becomes a strong requirement. Thanks. JP. > Thanks. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Wed Aug 22 03:53:59 2012 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 4B63221F861C for ; Wed, 22 Aug 2012 03:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=-1.273, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU1gYdcDb0QG for ; Wed, 22 Aug 2012 03:53:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1648521F84B5 for ; Wed, 22 Aug 2012 03:53:54 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so955464vcb.31 for ; Wed, 22 Aug 2012 03:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Yma0TReP6VMsWzpkyDuGF2uJXvEXPAUu2PhmYOcH4HU=; b=UV2NYaJuUHTHVW4HlCbzIsZSD2ULmNHJtDsOBQ5QIOmWxfESbpberp3YxITZ3t3n5s qJgMxM8yC8BBp4QMMV1Uxat5iECxdNnhPwokEo5bfeUgpghAXpV/ssdqe7KNuG1IQ5aQ hc/n3dJ/1bX42vy5jlpV9hm217y7tafzEpdRXbhS+ohwJeJJZkaorkE9bjne2+qPykzD kGMffK5w2KXhB7yP5GTM7enLliQDMgLo95c7kASWOh5hjwhJSUqdAZT9DEkyMaXfql0K 8Ael5uBC0bTFSKHv0+VZsGptQvkNaKOtSJrIXyHzTxe0crUx2vBVHtYaC/pLewpJUFlk OA1Q== MIME-Version: 1.0 Received: by 10.221.10.13 with SMTP id oy13mr16405670vcb.14.1345632834367; Wed, 22 Aug 2012 03:53:54 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Wed, 22 Aug 2012 03:53:54 -0700 (PDT) In-Reply-To: <8033D2D3-CCC0-4F1E-B1D1-A9510DA75BAF@etri.re.kr> References:

<8033D2D3-CCC0-4F1E-B1D1-A9510DA75BAF@etri.re.kr> Date: Wed, 22 Aug 2012 12:53:54 +0200 Message-ID: From: Abdussalam Baryun To: =?UTF-8?B?7KCV7KKF7IiY?= Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Cc: roll Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2012 10:53:59 -0000 Hi Jongsoo, I already commented on the draft and supported it. There are always different ways of solving an identified problem case. I mentioned that the mix capabilities issue of both drafts was similar and solution approach is different. IMO, efficient routings cannot be done without good discovery, AB --------- On 8/22/12, =C1=A4=C1=BE=BC=F6 wrote: > Hi AB, > > I also agree with Omprakash. Ko's draft describes a new RPL operation mod= e > while your draft describes nodes' ability (functions and resources) > advertisement/discovery in a given operation mode. > > -Jongsoo > > 2012. 8. 22., =BF=C0=C0=FC 3:58, Omprakash Gnawali > =C0=DB=BC=BA: > >> >> On Tue, Aug 21, 2012 at 11:33 AM, Abdussalam Baryun >> wrote: >>> Hi Omprakash >>> >>>> The draft describes one of the problems that could >>> occur if we try to form a multi-hop network with storing and >>> non-storing nodes. That is a concrete first step towards getting a >>> handle on the challenge of having nodes with different capabilities in >>> a network. >>> Please not that NAP draft is a first step to handle different >>> capabilities, >>> you may missed it when I described the problem in june and posted the >>> draft >>> in first august. However, I like that we share the importance of the >>> *mixture abilities* idea now and that we can work together to solve the >>> problem. >> >> Did you get a sense from the WG that this is an important problem? We >> can find many ways to extend and enhance every protocol but choose to >> work on a subset that is most relevant to those who are building >> devices and deploying networks. >> >> Ko's draft talks about how to do multi-hop routing with storing and >> non-storing nodes. Your draft talks about discovering if nodes are >> able to participate due to various constraints. They seem different to >> me but are not mutually exclusive. >> >> - om_p >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From jeonggil.ko@gmail.com Wed Aug 22 07:35:41 2012 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 4C8F321F85EA for ; Wed, 22 Aug 2012 07:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01PrB2IE1bLu for ; Wed, 22 Aug 2012 07:35:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4971A21F849C for ; Wed, 22 Aug 2012 07:35:37 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1512469pbb.31 for ; Wed, 22 Aug 2012 07:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2AgJlvSywnKwB4y6usM1kHIJBd+6+guuyDeTGOSz7a4=; b=zteaJLnxTNlGRwdW1F2KqARNis6raEa0AlgW1rJqPoSQwly8RKQOEXQ+WIdE/mbSBb NGKAy/+1Ug+ur+9mLYcyefYyUuyogD9eYQ/u8AxGZEmtwIiIQjuXH/G4c7vdVJBTRvA0 UXswEr+TVS5cV0Ihf+hspoVI2MoMawu0h7gUcWHnOOkRA2T1gCqD/JOfY7dJwBnJokYD QSZUY+pj/l47IHAnd1Pq87pqXD8fDNNHnY6gLhhp8Te5hxIXSt2pCIUJeyD4hO3gvZXJ Otj8CUy+7Ui7kKCHJcbARtRvZ7AhlHoXRJpb35LKVFoEnEUIjjnkqCwhC058+4FwmJpE c1uQ== Received: by 10.66.83.129 with SMTP id q1mr46671198pay.4.1345646136284; Wed, 22 Aug 2012 07:35:36 -0700 (PDT) Received: from [192.168.123.193] ([125.138.63.113]) by mx.google.com with ESMTPS id nk3sm3829547pbc.27.2012.08.22.07.35.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Aug 2012 07:35:35 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JeongGil Ko In-Reply-To: Date: Wed, 22 Aug 2012 23:35:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References:

To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1278) Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 22 Aug 2012 14:35:41 -0000 JP, Thanks for your input! I fully agree that the added complexity should be = minimal. We have a poster at this year's SenSys indicating that the = overhead of supporting the 'mixed' mode only requires minimal additional = complexity. One of the design goals in designing the scheme was to = minimize the additional overhead on non-route storing devices since, in = most cases, these are the devices that will actually operate with strict = memory/complexity requirements. Nevertheless the additional memory = required to implement the scheme for both types of devices, storing and = non-storing, (which we've done experimentally with TinyOS and NanoQplus = implementations) is minimal. To think about it, things get more complicated if we try to define an = entirely new mode for hybrid operations, but, storing mode and = non-storing mode both have their own benefits. Since the draft talks = about a case where we can still preserve the nature of the two modes AND = allow them to interoperate, I believe that this is a meaningful draft = for the WG. Thanks! -John ------ JeongGil Ko, Ph.D. Researcher Electronics and Telecommunications Research Institute (ETRI) http://sites.google.com/site/jeonggilko/ On Aug 22, 2012, at 3:15 PM, JP Vasseur (jvasseur) wrote: > Hi, >=20 > On Aug 21, 2012, at 6:31 PM, Omprakash Gnawali wrote: >=20 >> Dear ROLL WG, >>=20 >> John Ko posted a draft a few days ago about how we might accommodate = a >> mixture of storing and non-storing nodes in a network more = efficiently >> than making one of them leaf nodes. Searching through the ROLL mail >> archives, it was clear at the time that there was no use case for >> having a network that has a mixture of storing and non-storing nodes. >> I wonder if this is necessarily true if there are devices from >> multiple vendors. At the time, it was also speculated that the = mixture >> could also introduce unknown problems and no one seems to have a >> working solution. The draft describes one of the problems that could >> occur if we try to form a multi-hop network with storing and >> non-storing nodes. That is a concrete first step towards getting a >> handle on the challenge of having nodes with different capabilities = in >> a network. >>=20 >> Your guidance on whether this is an important problem worth working = on >> or the work is heading in a wrong direction would help evolve or stop >> the work. >>=20 >=20 > JP> I cannot agree more - actually we even have a partial to the = problem during the initial design phase and > the WG collectively decided not to mix storing and non-storing in = light of the added complexity. I would also > appreciate the feedback of the WG on this, and not add complexity = unless this becomes a strong requirement. >=20 > Thanks. >=20 > JP. >=20 >> Thanks. >>=20 >> - om_p >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Thu Aug 23 00:53:02 2012 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 E88D521F84A1; Thu, 23 Aug 2012 00:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzejpgyoRCsM; Thu, 23 Aug 2012 00:53:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 486C921F854C; Thu, 23 Aug 2012 00:53:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so534076vbb.31 for ; Thu, 23 Aug 2012 00:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DVMPzZ04l7bJgbmRALkuV5GUvEFavdwg95BJAX2vZ6o=; b=vs7at4FZMjvfqblv6vNnMvzikYxc6N7iBjhOAXcw9lbHkUdGzA/Mmrl2wtBnkkLhGh oi1yWtFGLiBidizSGQ17oLtLMve/8bS5agbYPUIh/j7rnKv8yYPLH6y4Jq9RO1Psfofe zd+rkFcjEYfIpU1Ny01TPjMV9O0cwXIJsuJkR4BVuiHMFCMKf5MJdb5g2QfMx3tkWf60 EXFdEsapcdnJXJ6GRtDqoyLHiLuArFrdhIr1A2g5nP1/615gtFkiv0k05ErllkMpftOd nFrpjlMzfRrCE9InUq7COisNWWoH/Jq7OhJo7FO0RQBezKyQFKI1Fk63j8gGv+RMYUwp Or/w== MIME-Version: 1.0 Received: by 10.220.37.194 with SMTP id y2mr491686vcd.44.1345708381716; Thu, 23 Aug 2012 00:53:01 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Thu, 23 Aug 2012 00:53:01 -0700 (PDT) In-Reply-To: References: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> <27653.1345402476@sandelman.ca> Date: Thu, 23 Aug 2012 09:53:01 +0200 Message-ID: From: Abdussalam Baryun To: roll Content-Type: text/plain; charset=ISO-8859-1 Cc: "iesg@ietf.org" Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2012 07:53:03 -0000 The last comments on this return ======================== IESG Discuss> 20-01-2011> I think this is a really good document, and support its publication. I am specifically concerned about punting the details on public key distribution, then finding they are not covered here either. Did I get the wrong document? Where are those issues going to be addressed? I agree that it provide good information as long we don't relate it to another document or another purpose, and happy that you support publication. I agree that it has not covered that security technique purpose, but I think this draft can be base for future specification/standard that will cover the issue refered to. I recommend thoes issues are going to be addressed in a RPL-Security standard I-D. Please not that there is no harm in passing this draft, but it will encourage progress/efforts. If there was a harm in passing the draft please reply. IESG Discuss>05-05-2011> I believe that the core of AD's discuss is that there is no specification for how the authenticated mode of roll-rpl is to be done, and specifically using public key based mechanisms for key distribution. If there was a harm in passing the draft please inform. This draft is an *informational* not a standard track that may be why it does not specify RPL authentication. This draft is a good introduction to a future standard I-D. IESG Discuss> 05-05-2011> I'd be happy to clear were there to be a good specification of how to do e.g. a signature based authenticated mode, or a public key based way to distribute keys for an authenticated mode, or even a kerberos-like way to distribute secret keys for an authenticated mode. While this will all be optional to implement, its absence is really not consistent with bcp107. I recommend a work either to be doing above request in an I-D (standard) within Security Area (not in Routing Area) or in an I-D (standard) that relates totally to RPL as RPL-Sec (standard) in this WG. Best Regards AB From adrian@olddog.co.uk Thu Aug 23 05:37:19 2012 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 0DEAC21F85F4; Thu, 23 Aug 2012 05:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvbIyyA9lNkm; Thu, 23 Aug 2012 05:37:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3783E21F85F3; Thu, 23 Aug 2012 05:37:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7NCbEZV029753; Thu, 23 Aug 2012 13:37:14 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7NCbC3k029737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Aug 2012 13:37:13 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'roll'" References: <110101cd7d74$71d47600$557d6200$@olddog.co.uk> <27653.1345402476@sandelman.ca>

In-Reply-To: Date: Thu, 23 Aug 2012 13:37:10 +0100 Message-ID: <173101cd812c$0447a240$0cd6e6c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGhmlwNC0MJjJlvXZ7i6OGiMNDWlQGwh13XArzPRKUCOvo7bAK1xi0dl3Qxe/A= Content-Language: en-gb Cc: iesg@ietf.org Subject: Re: [Roll] draft-ietf-roll-security-framework returned to working group. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 12:37:19 -0000 Hi again Abdussalam, > The last comments on this return That's good to hear :-) I think you should be happy with the outcome. This I-D will be re-born with a large amount of the text in place. Because this will be a significant change in the content of the document, it will need renewed working group consensus and so return to the WG is necessary. However, I expect this I-D to go forward quite soon. The other security work, which you appear to support, is currently planned and being hatched in the RPL working group. So everything is good, the flowers are blooming, and the bunnies are hopping around happily. Cheers, Adrian > ======================== > IESG Discuss> 20-01-2011> I think this is a really good document, and > support its publication. I am specifically concerned about punting the > details on public key > distribution, then finding they are not covered here either. Did I get > the wrong document? Where are those issues going to be addressed? > > I agree that it provide good information as long we don't relate it to > another document or another purpose, and happy that you support > publication. I agree that it has not covered that security technique > purpose, but I think this draft can be base for future > specification/standard that will cover the issue refered to. I > recommend thoes issues are going to be addressed in a RPL-Security > standard I-D. Please not that there is no harm in passing this draft, > but it will encourage progress/efforts. If there was a harm in passing > the draft please reply. > > IESG Discuss>05-05-2011> I believe that the core of AD's discuss is > that there is no specification for how the authenticated mode of > roll-rpl is to > be done, and specifically using public key based mechanisms > for key distribution. > > If there was a harm in passing the draft please inform. This draft is > an *informational* not a standard track that may be why it does not > specify RPL authentication. This draft is a good introduction to a > future standard I-D. > > IESG Discuss> 05-05-2011> I'd be happy to clear were there to be a > good specification of how to do e.g. a signature based authenticated > mode, or > a public key based way to distribute keys for an > authenticated mode, or even a kerberos-like way to > distribute secret keys for an authenticated mode. While this > will all be optional to implement, its absence is really > not consistent with bcp107. > > I recommend a work either to be doing above request in an I-D > (standard) within Security Area (not in Routing Area) or in an I-D > (standard) that relates totally to RPL as RPL-Sec (standard) in this > WG. > > Best Regards > AB > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Aug 23 22:06:24 2012 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 BDABF21F854D for ; Thu, 23 Aug 2012 22:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id citwwC8I0CuK for ; Thu, 23 Aug 2012 22:06:17 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA421F854B for ; Thu, 23 Aug 2012 22:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3708; q=dns/txt; s=iport; t=1345784777; x=1346994377; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rQsCpH/4DRRXpI8ve0u6k322HgXJB+IObotniWXBV+8=; b=A0zSrdkydVhjuLFa8/iFWnnF3S9kP++uzy6wfZnxD80ECBAyQh1zFbJF 1zZZ/5agR5MlkfzN869lXYR5OhYLbmL2as+TWZdGzO+N/EyLC6X506Zcp C1NfCXOqKkl/izmZHJBzCqfiQ0x13eovnGmvy6NBTizm3OTefPfBRp1gl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIkKN1CtJXHB/2dsb2JhbABFulKBB4IgAQEBAwEBAQEPASc0CwULAgEIGB4QJwslAgQOBRsHh2UGC5k+oCGLCBqGF2ADlVSBFI0ZgWeCY4Fh X-IronPort-AV: E=Sophos;i="4.80,302,1344211200"; d="scan'208";a="111820211" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 24 Aug 2012 05:06:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7O56Eqm010889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Aug 2012 05:06:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.209]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 24 Aug 2012 00:06:14 -0500 From: "JP Vasseur (jvasseur)" To: JeongGil Ko Thread-Topic: [Roll] mixture of storing and non-storing nodes Thread-Index: AQHNgC14aerYJYORe0Sa2/SEM2k1rg== Date: Fri, 24 Aug 2012 05:06:14 +0000 Message-ID: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.232] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19134.004 x-tm-as-result: No--47.977800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <8EAF607596456E4CBAC8575B10AFD524@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 05:06:24 -0000 Hi, On Aug 22, 2012, at 4:35 PM, JeongGil Ko wrote: > JP, >=20 > Thanks for your input! I fully agree that the added complexity should be = minimal. We have a poster at this year's SenSys indicating that the overhea= d of supporting the 'mixed' mode only requires minimal additional complexit= y. One of the design goals in designing the scheme was to minimize the addi= tional overhead on non-route storing devices since, in most cases, these ar= e the devices that will actually operate with strict memory/complexity requ= irements. Nevertheless the additional memory required to implement the sche= me for both types of devices, storing and non-storing, (which we've done ex= perimentally with TinyOS and NanoQplus implementations) is minimal. >=20 > To think about it, things get more complicated if we try to define an ent= irely new mode for hybrid operations, but, storing mode and non-storing mod= e both have their own benefits. Since the draft talks about a case where we= can still preserve the nature of the two modes AND allow them to interoper= ate, I believe that this is a meaningful draft for the WG. Many Thanks for your feed-back, great discussion. If we have sufficient req= uirements for such a case (let's see what the WG says) and minimal changes required to meet the requirements, why not, but I just = wanted to raise the concern. Thanks. JP. >=20 > Thanks! >=20 > -John >=20 > ------ > JeongGil Ko, Ph.D. > Researcher > Electronics and Telecommunications Research Institute (ETRI) > http://sites.google.com/site/jeonggilko/ >=20 > On Aug 22, 2012, at 3:15 PM, JP Vasseur (jvasseur) wrote: >=20 >> Hi, >>=20 >> On Aug 21, 2012, at 6:31 PM, Omprakash Gnawali wrote: >>=20 >>> Dear ROLL WG, >>>=20 >>> John Ko posted a draft a few days ago about how we might accommodate a >>> mixture of storing and non-storing nodes in a network more efficiently >>> than making one of them leaf nodes. Searching through the ROLL mail >>> archives, it was clear at the time that there was no use case for >>> having a network that has a mixture of storing and non-storing nodes. >>> I wonder if this is necessarily true if there are devices from >>> multiple vendors. At the time, it was also speculated that the mixture >>> could also introduce unknown problems and no one seems to have a >>> working solution. The draft describes one of the problems that could >>> occur if we try to form a multi-hop network with storing and >>> non-storing nodes. That is a concrete first step towards getting a >>> handle on the challenge of having nodes with different capabilities in >>> a network. >>>=20 >>> Your guidance on whether this is an important problem worth working on >>> or the work is heading in a wrong direction would help evolve or stop >>> the work. >>>=20 >>=20 >> JP> I cannot agree more - actually we even have a partial to the problem= during the initial design phase and >> the WG collectively decided not to mix storing and non-storing in light = of the added complexity. I would also >> appreciate the feedback of the WG on this, and not add complexity unless= this becomes a strong requirement. >>=20 >> Thanks. >>=20 >> JP. >>=20 >>> Thanks. >>>=20 >>> - om_p >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Fri Aug 24 12:23:08 2012 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 B371421F84C5 for ; Fri, 24 Aug 2012 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFOjsDCctCZv for ; Fri, 24 Aug 2012 12:23:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E4BCA21F84A7 for ; Fri, 24 Aug 2012 12:23:04 -0700 (PDT) Received: from sandelman.ca (74-115-197-225.eng.wind.ca [74.115.197.225]) by relay.sandelman.ca (Postfix) with ESMTPS id 9E4038656 for ; Fri, 24 Aug 2012 15:17:51 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 56680CA0D2 for ; Fri, 24 Aug 2012 14:32:33 -0400 (EDT) From: Michael Richardson To: roll WG In-reply-to: References:

Comments: In-reply-to "JP Vasseur (jvasseur)" message dated "Wed, 22 Aug 2012 06:15:05 -0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 24 Aug 2012 14:32:33 -0400 Message-ID: <30393.1345833153@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 19:23:08 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable OG> John Ko posted a draft a few days ago about how we might accommodat= e a OG> mixture of storing and non-storing nodes in a network more efficien= tly OG> than making one of them leaf nodes. Searching through the ROLL mail OG> archives, it was clear at the time that there was no use case for OG> having a network that has a mixture of storing and non-storing OG> nodes. JP> I cannot agree more - actually we even have a partial to the JP> problem during the initial design phase and the WG collectively JP> decided not to mix storing and non-storing in light of the added JP> complexity. I would also appreciate the feedback of the WG on JP> this, and not add complexity unless this becomes a strong JP> requirement.=20 I believe that use cases for storing and non-storing nodes would appear as optimizations (particularly in the p2p heavy LLNs) if we could figure out how to make it work. I think that the major problem was that nodes below the root needed to know if there downstreams nodes were storing or not, and thus non-storing nodes wound up picking up significant resource impact, when those nodes were supposed to be lighter weight. =2D-=20 Michael Richardson =2Dat the cottage- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQN8i/AAoJEKD0KQ7Gj3P2HU0IAKJgW69fzEDmV3rd1kS/iAIh ZH7RwHanqxoV996pYfQBcEs8Dkk51t9axz3frsIS8eLZcBdGKWK1n3RMikewkr8q u1iYTQ+bdqom8vbhkbD8XV0fR5mHBdrei9X7byQ6a6urpzg8zNQ0Z3Z6A+6iiGuJ 0RRcWrr+m12Dxi2EfBVUoMGaTZU1VtW4Fhk9fdplGc4wqQ5J8zcaMS/T0cXedK7O wFeDOAbpST+TRJTHdL8N22bSKJZh6iG+Gjuaoi6CfnabnIC5v01IyBcoHA2xxLfN P7YTOtvF5V9LkeQ046ewAV4hCCNw2MIvAQ8/geU85O/k0+/0Q9PY+zrerYs/xIs= =zSII -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Aug 24 12:23:14 2012 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 A137B21F8613; Fri, 24 Aug 2012 12:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOaiDskgvYH3; Fri, 24 Aug 2012 12:23:14 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0566821F8596; Fri, 24 Aug 2012 12:23:14 -0700 (PDT) Received: from sandelman.ca (74-115-197-225.eng.wind.ca [74.115.197.225]) by relay.sandelman.ca (Postfix) with ESMTPS id 684B68657; Fri, 24 Aug 2012 15:18:00 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38B65CA0D3; Fri, 24 Aug 2012 14:52:38 -0400 (EDT) From: Michael Richardson To: roll WG , 6lowpan@ietf.org In-reply-to: <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> References: <18113.1339529290@marajade.sandelman.ca>

<87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> Comments: In-reply-to Carsten Bormann message dated "Thu, 14 Jun 2012 12:19:13 +0200." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 24 Aug 2012 14:52:38 -0400 Message-ID: <31218.1345834358@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] [6lowpan] draft-bormann-ghc X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 24 Aug 2012 19:23:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Carsten" =3D=3D Carsten Bormann writes: Carsten> Changing to WG chair mode for a moment: Carsten> The 6LoWPAN WG is alive and well and is in the process of Carsten> closing its remaining two work items (6LoWPAN-ND, 6LoWPAN Carsten> for BTLE).=20 Carsten> However, you are right in that the 6LoWPAN WG no longer takes = new work on. Carsten> The chairs, with the ADs and the chairs of other WGs, will Carsten> ensure that interesting work finds an appropriate home. ...? where will GHC go? =2D-=20 Michael Richardson =2Dat the cottage- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQN811AAoJEKD0KQ7Gj3P2ecAIALHzIzWyv2ynXip/Jw6kePTN Ab24TyF8UIa6BpCjbJuB3JNJlCdGsZL6Yo/AzO7lVmZvmrvlgtODkuKnbIMnPSrS VRSMdki67ZzeMQdXatNtf3HtOVKJRnY/jk3POrvmNAHILMjjAf19JtzN1njVDt07 xp7FS+Ig+yqeRJpLwlPTincgd8ZynC0ZiSjAYrbZpYyXDpre5YwFkrqb4B4oB5V6 6kxtqWbsBsrbXxAxRgjmcgFZW6iT4U9Y//rvbfO9665mcKjlOKCud20AFwF2tAHS l4seNroduK7119pktdZYtdIOpOhJUmbRD42IKiulrARLV1Nmqeisbn8OSekib78= =djn9 -----END PGP SIGNATURE----- --=-=-=-- From jsjeong@etri.re.kr Fri Aug 24 17:33:12 2012 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 276D621F856F for ; Fri, 24 Aug 2012 17:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.896 X-Spam-Level: X-Spam-Status: No, score=-94.896 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reKIqk7Y6VQ3 for ; Fri, 24 Aug 2012 17:33:11 -0700 (PDT) Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4321F856C for ; Fri, 24 Aug 2012 17:33:11 -0700 (PDT) Received: from SMTPEG2.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id q7P0X8cl029536; Sat, 25 Aug 2012 09:33:08 +0900 Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 25 Aug 2012 09:33:11 +0900 Received: from SMTP4.etri.info ([169.254.3.84]) by SMTP2.etri.info ([169.254.2.205]) with mapi id 14.01.0355.002; Sat, 25 Aug 2012 09:33:07 +0900 From: =?euc-kr?B?waTBvrz2?= To: Michael Richardson Thread-Topic: [Roll] mixture of storing and non-storing nodes Thread-Index: AQHNf7qCa3ul5GjnHEWCevy5tyL565dkxJyAgAPytYCAAPueTg== Date: Sat, 25 Aug 2012 00:33:07 +0000 Message-ID: <4CBBFD41-130A-4FD8-ABBA-B515C3B5CFB0@etri.re.kr> References:

, <30393.1345833153@sandelman.ca> In-Reply-To: <30393.1345833153@sandelman.ca> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 00:33:12 -0000 SGkgTWljaGFlbC4NCg0KMjAxMi4gOC4gMjUuIL/AwPwgNDoyMyAiTWljaGFlbCBSaWNoYXJkc29u IiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiDA27y6Og0KDQo+IA0KPiAgIE9HPiBKb2huIEtvIHBv c3RlZCBhIGRyYWZ0IGEgZmV3IGRheXMgYWdvIGFib3V0IGhvdyB3ZSBtaWdodCBhY2NvbW1vZGF0 ZSBhDQo+ICAgT0c+IG1peHR1cmUgb2Ygc3RvcmluZyBhbmQgbm9uLXN0b3Jpbmcgbm9kZXMgaW4g YSBuZXR3b3JrIG1vcmUgZWZmaWNpZW50bHkNCj4gICBPRz4gdGhhbiBtYWtpbmcgb25lIG9mIHRo ZW0gbGVhZiBub2Rlcy4gU2VhcmNoaW5nIHRocm91Z2ggdGhlIFJPTEwgbWFpbA0KPiAgIE9HPiBh cmNoaXZlcywgaXQgd2FzIGNsZWFyIGF0IHRoZSB0aW1lIHRoYXQgdGhlcmUgd2FzIG5vIHVzZSBj YXNlIGZvcg0KPiAgIE9HPiBoYXZpbmcgYSBuZXR3b3JrIHRoYXQgaGFzIGEgbWl4dHVyZSBvZiBz dG9yaW5nIGFuZCBub24tc3RvcmluZw0KPiAgIE9HPiBub2Rlcy4NCj4gDQo+ICAgSlA+IEkgY2Fu bm90IGFncmVlIG1vcmUgLSBhY3R1YWxseSB3ZSBldmVuIGhhdmUgYSBwYXJ0aWFsIHRvIHRoZQ0K PiAgIEpQPiBwcm9ibGVtIGR1cmluZyB0aGUgaW5pdGlhbCBkZXNpZ24gcGhhc2UgYW5kIHRoZSBX RyBjb2xsZWN0aXZlbHkNCj4gICBKUD4gZGVjaWRlZCBub3QgdG8gbWl4IHN0b3JpbmcgYW5kIG5v bi1zdG9yaW5nIGluIGxpZ2h0IG9mIHRoZSBhZGRlZA0KPiAgIEpQPiBjb21wbGV4aXR5LiBJIHdv dWxkIGFsc28gYXBwcmVjaWF0ZSB0aGUgZmVlZGJhY2sgb2YgdGhlIFdHIG9uDQo+ICAgSlA+IHRo aXMsIGFuZCBub3QgYWRkIGNvbXBsZXhpdHkgdW5sZXNzIHRoaXMgYmVjb21lcyBhIHN0cm9uZw0K PiAgIEpQPiByZXF1aXJlbWVudC4gDQo+IA0KPiBJIGJlbGlldmUgdGhhdCB1c2UgY2FzZXMgZm9y IHN0b3JpbmcgYW5kIG5vbi1zdG9yaW5nIG5vZGVzIHdvdWxkIGFwcGVhcg0KPiBhcyBvcHRpbWl6 YXRpb25zIChwYXJ0aWN1bGFybHkgaW4gdGhlIHAycCBoZWF2eSBMTE5zKSBpZiB3ZSBjb3VsZCBm aWd1cmUNCj4gb3V0IGhvdyB0byBtYWtlIGl0IHdvcmsuDQo+IA0KDQpZb3UncmUgcmlnaHQuIEFk ZGl0aW9uYWxseSwgbWl4dHVyZSBvZiBzdG9yaW5nIGFuZCBub24tc3RvcmluZyBub2RlcyBjYW4g Y2F1c2UgaW5lZmZpY2llbnQgdXB3YXJkcyByb3V0aW5nIGluIHRoZSBjdXJyZW50IFJQTC4gQmVj YXVzZSBub2RlcyB0aGF0IGNhbiBzdXBwb3J0IG9ubHkgZGlmZmVyZW50IE1PUCBmcm9tIHRoZSBy b290J3MgTU9QIHNob3VsZCBhY3QgYXMgYSBsZWFmIG5vZGUuIEZ1cnRoZXJtb3JlLCBpZiB0aGUg bGVhZiBub2RlIGlzIGFuIG9ubHkgbm9kZSB0aGF0IGlzIGF0IGludGVybWVkaWF0ZSBwbGFjZSBw aHlzaWNhbGx5IHRvIGZvcndhcmQgdXBzdHJlYW0gdHJhZmZpYywgbm90IG9ubHkgZG93bndhcmRz IGJ1dCBhbHNvIHVwd2FyZHMgcm91dGluZyB3aWxsIG5vdCB3b3JrIGZyb20gdGhpcyBwb2ludC4N Cg0KPiBJIHRoaW5rIHRoYXQgdGhlIG1ham9yIHByb2JsZW0gd2FzIHRoYXQgbm9kZXMgYmVsb3cg dGhlIHJvb3QgbmVlZGVkIHRvDQo+IGtub3cgaWYgdGhlcmUgZG93bnN0cmVhbXMgbm9kZXMgd2Vy ZSBzdG9yaW5nIG9yIG5vdCwgYW5kIHRodXMNCj4gbm9uLXN0b3Jpbmcgbm9kZXMgd291bmQgdXAg cGlja2luZyB1cCBzaWduaWZpY2FudCByZXNvdXJjZSBpbXBhY3QsIHdoZW4NCj4gdGhvc2Ugbm9k ZXMgd2VyZSBzdXBwb3NlZCB0byBiZSBsaWdodGVyIHdlaWdodC4NCj4gDQo+IC0tIA0KPiBNaWNo YWVsIFJpY2hhcmRzb24NCj4gLWF0IHRoZSBjb3R0YWdlLQ0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xs QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K DQpUaGFuayB5b3UuDQotSm9uZ3Nvbw== From jeonggil.ko@gmail.com Fri Aug 24 19:14:30 2012 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 3121821F859F for ; Fri, 24 Aug 2012 19:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTCcBWb6pZnO for ; Fri, 24 Aug 2012 19:14:29 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0021F8564 for ; Fri, 24 Aug 2012 19:14:29 -0700 (PDT) Received: by dadf8 with SMTP id f8so1239455dad.31 for ; Fri, 24 Aug 2012 19:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tHpuITQe/lsjl9zNStN6zeXqeSBSpVBSyqLS8IXT8Nw=; b=CLIUNRgF83kl7KyXPGoMaT8AKjx+eCNtJLLCY3gFUHUt2KDc+sHGZtMKJMxj88ZAp9 ALZA62oQSesvzlzWnd4PP+yDtvjK30sO7571IMpD8LLFtdRVEbsDMwsVe+cMApP/+YYc ciqVUpipRUcg2Fjql7tQm4w4jTm3N4stUDw+5J43AGDdHoWOcNBufecVDXzqVGMPyi1w 7nUHG7+2D1qyqQsZpWydGkyLu9j96aIl2NXZtMl1nUWVnzCaWN9bYEYSbnth7lwo7Rho tPnb+YpDxQBNcFeCSZaP8mhidVIxTqCo+cGyPyxMSYBVXzsutatNlIEo4GI0H2Q2+YcT tYPA== Received: by 10.66.81.66 with SMTP id y2mr5871441pax.62.1345860865303; Fri, 24 Aug 2012 19:14:25 -0700 (PDT) Received: from [192.168.123.193] ([125.138.63.113]) by mx.google.com with ESMTPS id rz10sm9481265pbc.32.2012.08.24.19.14.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Aug 2012 19:14:24 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: JeongGil Ko In-Reply-To: <4CBBFD41-130A-4FD8-ABBA-B515C3B5CFB0@etri.re.kr> Date: Sat, 25 Aug 2012 11:14:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References:

, <30393.1345833153@sandelman.ca> <4CBBFD41-130A-4FD8-ABBA-B515C3B5CFB0@etri.re.kr> To: Michael Richardson X-Mailer: Apple Mail (2.1278) Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 02:14:30 -0000 Hi! A bit more comments in-line ;) On Aug 25, 2012, at 9:33 AM, =EC=A0=95=EC=A2=85=EC=88=98 wrote: > Hi Michael. >=20 > 2012. 8. 25. =EC=98=A4=EC=A0=84 4:23 "Michael Richardson" = =EC=9E=91=EC=84=B1: >=20 >>=20 >> OG> John Ko posted a draft a few days ago about how we might = accommodate a >> OG> mixture of storing and non-storing nodes in a network more = efficiently >> OG> than making one of them leaf nodes. Searching through the ROLL = mail >> OG> archives, it was clear at the time that there was no use case = for >> OG> having a network that has a mixture of storing and non-storing >> OG> nodes. >>=20 >> JP> I cannot agree more - actually we even have a partial to the >> JP> problem during the initial design phase and the WG collectively >> JP> decided not to mix storing and non-storing in light of the added >> JP> complexity. I would also appreciate the feedback of the WG on >> JP> this, and not add complexity unless this becomes a strong >> JP> requirement.=20 >>=20 >> I believe that use cases for storing and non-storing nodes would = appear >> as optimizations (particularly in the p2p heavy LLNs) if we could = figure >> out how to make it work. >>=20 >=20 > You're right. Additionally, mixture of storing and non-storing nodes = can cause inefficient upwards routing in the current RPL. Because nodes = that can support only different MOP from the root's MOP should act as a = leaf node. Furthermore, if the leaf node is an only node that is at = intermediate place physically to forward upstream traffic, not only = downwards but also upwards routing will not work from this point. >=20 >> I think that the major problem was that nodes below the root needed = to >> know if there downstreams nodes were storing or not, and thus >> non-storing nodes wound up picking up significant resource impact, = when >> those nodes were supposed to be lighter weight. >>=20 Resource is by far one of the most important factors. One of the = characteristics of this draft is to allow both modes to be possible. If = you have the resources, then be a storing mode! If not, you always have = the option of being a non-storing mode... its just that with the draft, = we can mix these two modes together. The two modes have their own = benefits so let's keep them and allow them to mix together so that we = can perform, as mentioned above, optimizations to the RPL network. Thanks for your feed back! -John >> --=20 >> Michael Richardson >> -at the cottage- >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > Thank you. > -Jongsoo > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Fri Aug 24 21:58:19 2012 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 5945D21F859B; Fri, 24 Aug 2012 21:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoZXJ-GQUO6P; Fri, 24 Aug 2012 21:58:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 146A721F8598; Fri, 24 Aug 2012 21:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q7P4w9q8013280; Sat, 25 Aug 2012 06:58:09 +0200 (CEST) Received: from [10.5.51.181] (unknown [80.233.164.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E134C85B; Sat, 25 Aug 2012 06:58:08 +0200 (CEST) References: <18113.1339529290@marajade.sandelman.ca>

<87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> In-Reply-To: <31218.1345834358@sandelman.ca> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> Content-Transfer-Encoding: quoted-printable X-Mailer: iPod Mail (9B206) From: Carsten Bormann Date: Sat, 25 Aug 2012 07:58:07 +0300 To: Michael Richardson Cc: roll WG , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-bormann-ghc X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 04:58:19 -0000 I don't know -- it could be handled as AD sponsored. I'm confident we'll fi= nd a way. More interesting is *when* it should go. I'm in the process of obtaining re= search results that might improve the performance with DTLS packets a bit (w= ith minimal implementation impact). We could rush GHC before that is complet= e, wait a couple of months for these results, or even try to get more input.= What is the best timing? We need input from implementers to decide this. Sent from Mobile On 24.08.2012, at 21:52, Michael Richardson wrote: >=20 >>>>>> "Carsten" =3D=3D Carsten Bormann writes: > Carsten> Changing to WG chair mode for a moment: >=20 > Carsten> The 6LoWPAN WG is alive and well and is in the process of > Carsten> closing its remaining two work items (6LoWPAN-ND, 6LoWPAN > Carsten> for BTLE).=20 >=20 > Carsten> However, you are right in that the 6LoWPAN WG no longer takes n= ew work on. > Carsten> The chairs, with the ADs and the chairs of other WGs, will > Carsten> ensure that interesting work finds an appropriate home. >=20 > ...? where will GHC go? >=20 > --=20 > Michael Richardson > -at the cottage- > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From stokcons@xs4all.nl Sat Aug 25 04:41:59 2012 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 EC3FD21F84DC for ; Sat, 25 Aug 2012 04:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VqMsJEgtYLo for ; Sat, 25 Aug 2012 04:41:59 -0700 (PDT) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0421F84FB for ; Sat, 25 Aug 2012 04:41:52 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id q7PBfKoQ075888 for ; Sat, 25 Aug 2012 13:41:20 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 25 Aug 2012 13:41:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 25 Aug 2012 13:41:20 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> References: <18113.1339529290@marajade.sandelman.ca>

<87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> Message-ID: <26808a929674c2b96850f40a9d7cd686@xs4all.nl> X-Sender: stokcons@xs4all.nl (hMYePJuP31nIcZfBk9WCUJHx+6tFJFGL) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] [6lowpan] draft-bormann-ghc X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 11:42:00 -0000 Carsten, GHC applied to DTLS encrypted messages is interesting indeed. It may represent an important number of messages to transmit. I would concentrate on getting the GHC on DTLS results known and then start pushing ghc draft. greetings, peter Carsten Bormann schreef op 2012-08-25 06:58: > I don't know -- it could be handled as AD sponsored. I'm confident > we'll find a way. > > More interesting is *when* it should go. I'm in the process of > obtaining research results that might improve the performance with > DTLS packets a bit (with minimal implementation impact). We could > rush > GHC before that is complete, wait a couple of months for these > results, or even try to get more input. What is the best timing? We > need input from implementers to decide this. > > Sent from Mobile > > On 24.08.2012, at 21:52, Michael Richardson > wrote: > >> >>>>>>> "Carsten" == Carsten Bormann writes: >> Carsten> Changing to WG chair mode for a moment: >> >> Carsten> The 6LoWPAN WG is alive and well and is in the process >> of >> Carsten> closing its remaining two work items (6LoWPAN-ND, >> 6LoWPAN >> Carsten> for BTLE). >> >> Carsten> However, you are right in that the 6LoWPAN WG no longer >> takes new work on. >> Carsten> The chairs, with the ADs and the chairs of other WGs, >> will >> Carsten> ensure that interesting work finds an appropriate home. >> >> ...? where will GHC go? >> >> -- >> Michael Richardson >> -at the cottage- >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From esko.dijk@philips.com Mon Aug 27 06:46:51 2012 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 7BE2321F8645 for ; Mon, 27 Aug 2012 06:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.925 X-Spam-Level: X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=1.674, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+H5ZgnE8bMd for ; Mon, 27 Aug 2012 06:46:50 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6A40321F8630 for ; Mon, 27 Aug 2012 06:46:49 -0700 (PDT) Received: from mail20-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 27 Aug 2012 13:46:49 +0000 Received: from mail20-tx2 (localhost [127.0.0.1]) by mail20-tx2-R.bigfish.com (Postfix) with ESMTP id 06A133A030B; Mon, 27 Aug 2012 13:46:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -41 X-BigFish: VPS-41(zz217bL15d6O9251J103dK542Mzz1202hzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah) Received: from mail20-tx2 (localhost.localdomain [127.0.0.1]) by mail20-tx2 (MessageSwitch) id 1346075207351822_31429; Mon, 27 Aug 2012 13:46:47 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.235]) by mail20-tx2.bigfish.com (Postfix) with ESMTP id 4909F22013C; Mon, 27 Aug 2012 13:46:47 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 27 Aug 2012 13:46:46 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-004.MGDPHG.emi.philips.com (10.128.28.54) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 27 Aug 2012 14:45:44 +0100 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.216]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0309.003; Mon, 27 Aug 2012 14:45:43 +0100 From: "Dijk, Esko" To: "Jonathan Hui (johui)" , "roll@ietf.org" Thread-Topic: draft-ietf-roll-trickle-mcast-02 (proposed text) Thread-Index: AQHNcaAmVDiypUQcCEeYvwAemcuHJ5dtsRIg Date: Mon, 27 Aug 2012 13:45:42 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AE0766@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> In-Reply-To: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 27 Aug 2012 13:46:51 -0000 Hello Jonathan, great to see that this draft includes many improvements. However the added = overhead of the newly introduced IPv6-in-IPv6 encapsulation and the removal= of the 0-byte "seed-id=3D=3DIPv6-source-address" option is worrying. For e= xample in a typical use in a 6LoWPAN 802.15.4 network, an extra 6LoWPAN IPH= C header is included (+4 bytes) and a seed-id (+16 bytes) field compared to= the same situation using the 'old' Trickle Multicast. That's 20 bytes more overhead and space is already scarce. (With 2-byte see= d-ids we can get this 20 down to 6 bytes, but that implies some seed-id ass= ignment process is needed which was not needed in Trickle Multicast.) The reason is given as follows: > IPv6-in-IPv6 encapsulation is necessary to support Path MTU discovery whe= n the MPL > forwarder is not the source of the original multicast packet. IPv6- > in-IPv6 encapsulation also allows an MPL forwarder to remove the MPL > Option when forwarding the original multicast packet over a link that > does not support MPL. Why is Path MTU discovery necessary here? (Isn't it optional?) Sensible app= lications would stay far, far away from the MTU size e.g. 1280 bytes in 6Lo= WPAN, especially for multicast. And why is encapsulation needed to support it? (Maybe there is a reference = that explains this?) Is it possible to 'fix' the problem and use the compactness of the 'old' (v= 00) packet format in the new draft? best regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon= athan Hui (johui) Sent: Friday 3 August 2012 19:48 To: roll@ietf.org Subject: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) We've been working on an update to draft-ietf-roll-trickle-mcast. I've att= ached a draft of the proposed text. Note that we will *not* be presenting = this draft at the ROLL WG meeting. In a prior mail, I noted some deficiencies with the initial draft that was = posted. We will discuss some of these deficiencies at the ROLL WG meeting = today. The purpose of this mail is to give you some insight into solving t= hose deficiencies as well as incorporating suggestions that were brought up= on the list. If you get a chance to glance through before the WG meeting,= great. In either case, let's continue the discussion on the list. Always looking for your feedback, especially from implementors. Thanks! -- Jonathan Hui ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From dat@exegin.com Fri Aug 31 07:41:17 2012 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 0E92421F8634 for ; Fri, 31 Aug 2012 07:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px3ZvH30+WQK for ; Fri, 31 Aug 2012 07:41:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26FBE21F846C for ; Fri, 31 Aug 2012 07:41:16 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4753745pbb.31 for ; Fri, 31 Aug 2012 07:41:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qNKgqxH2wa+Ih0oBhXbO129FiKbVtCwgLNPrOVuexzI=; b=bvY09JvSwKzRjPFF9O6Yd5v5aI4noJYrKSNUkw1OSvulvuoW4NrtKxI8K2aOgnFTQa je4tPF6i47w/6x7ZnIhAHRthJ7ENDGJ9wwWwkroVH2bUve9/PB5at0gv0TN4u/jZ49AG eG/WSFQGWpkB1c2gGJpVMOvHekVF3wcw8yzvUBNHl/yo8B3Uur8HCaQv+tOiGMnWeUSq 8DmbjZi49cPYg2/r9rx3Wqz7d7/E2NlfYvmTu083A+QL5KVAgH18l4+vvUvov5vGoZDN 9FcSOwsuMHVfrxqmq3wnghpt1czUPHoiK4xPz8k6jmYRWrYk8W0ev8yzHAXclaBVPiMR axNw== Received: by 10.66.75.167 with SMTP id d7mr6964288paw.76.1346424075733; Fri, 31 Aug 2012 07:41:15 -0700 (PDT) Received: from [192.168.10.103] (S01060014d146ff29.vf.shawcable.net. [70.68.56.13]) by mx.google.com with ESMTPS id rz10sm3566324pbc.32.2012.08.31.07.41.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 07:41:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Dario Tedeschi In-Reply-To: <031DD135F9160444ABBE3B0C36CED618AE0766@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Fri, 31 Aug 2012 07:41:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <607772EC-5636-4C7C-9DF1-1DCDF9EF4E85@exegin.com> References: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> <031DD135F9160444ABBE3B0C36CED618AE0766@011-DB3MPN2-081.MGDPHG.emi.philips.com> To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQljCppnzvR0D4AqXhq2tTRK39rLwU3IgP3cndmfzXMa6fAhoPPUiNaHBrC9rxhmhvNh8GYj Cc: "roll@ietf.org" , "Jonathan Hui $johui$" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 14:41:17 -0000 The IPv6-in-IPv6 is needed so that the Trickle Multicast hop-by-hop = option can be removed or inserted when a site-local (or higher) scoped = multicast datagram leaves or enters a RPL domain. If a device doesn't = require or expect highly scoped multicasts to leave the RPL domain it = could choose to originate a multicast datagram with a Trickle Multicast = option and need not encapsulate. However, in the interest of = consistency, it would be better if all nodes handled multicasts in the = same way. Otherwise you end up with routers having to support both = tunnelled and non-tunneled multicasts, which gets a bit complicated. Secondly, IPv6-in-IPv6 should compress quite well using 6LoWPAN, = because the IPv6 addresses in the inner packet are elided from the IPv6 = addresses in the outer header. -Dario On 2012-08-27, at 6:45 , Dijk, Esko wrote: > Hello Jonathan, >=20 > great to see that this draft includes many improvements. However the = added overhead of the newly introduced IPv6-in-IPv6 encapsulation and = the removal of the 0-byte "seed-id=3D=3DIPv6-source-address" option is = worrying. For example in a typical use in a 6LoWPAN 802.15.4 network, an = extra 6LoWPAN IPHC header is included (+4 bytes) and a seed-id (+16 = bytes) field compared to the same situation using the 'old' Trickle = Multicast. >=20 > That's 20 bytes more overhead and space is already scarce. (With = 2-byte seed-ids we can get this 20 down to 6 bytes, but that implies = some seed-id assignment process is needed which was not needed in = Trickle Multicast.) >=20 > The reason is given as follows: >> IPv6-in-IPv6 encapsulation is necessary to support Path MTU discovery = when the MPL >> forwarder is not the source of the original multicast packet. = IPv6- >> in-IPv6 encapsulation also allows an MPL forwarder to remove the = MPL >> Option when forwarding the original multicast packet over a link = that >> does not support MPL. > Why is Path MTU discovery necessary here? (Isn't it optional?) = Sensible applications would stay far, far away from the MTU size e.g. = 1280 bytes in 6LoWPAN, especially for multicast. > And why is encapsulation needed to support it? (Maybe there is a = reference that explains this?) >=20 > Is it possible to 'fix' the problem and use the compactness of the = 'old' (v00) packet format in the new draft? >=20 > best regards, > Esko >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Jonathan Hui (johui) > Sent: Friday 3 August 2012 19:48 > To: roll@ietf.org > Subject: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) >=20 >=20 > We've been working on an update to draft-ietf-roll-trickle-mcast. = I've attached a draft of the proposed text. Note that we will *not* be = presenting this draft at the ROLL WG meeting. >=20 > In a prior mail, I noted some deficiencies with the initial draft that = was posted. We will discuss some of these deficiencies at the ROLL WG = meeting today. The purpose of this mail is to give you some insight = into solving those deficiencies as well as incorporating suggestions = that were brought up on the list. If you get a chance to glance through = before the WG meeting, great. In either case, let's continue the = discussion on the list. >=20 > Always looking for your feedback, especially from implementors. >=20 > Thanks! >=20 > -- > Jonathan Hui >=20 >=20 > ________________________________ > The information contained in this message may be confidential and = legally protected under applicable law. The message is intended solely = for the addressee(s). If you are not the intended recipient, you are = hereby notified that any use, forwarding, dissemination, or reproduction = of this message is strictly prohibited and may be unlawful. If you are = not the intended recipient, please contact the sender by return e-mail = and destroy all copies of the original message. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From dat@exegin.com Fri Aug 31 10:38:07 2012 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 3A04521F8495 for ; Fri, 31 Aug 2012 10:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D26sdWaihj0z for ; Fri, 31 Aug 2012 10:38:06 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 811AF21F8487 for ; Fri, 31 Aug 2012 10:38:06 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4995045pbb.31 for ; Fri, 31 Aug 2012 10:38:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=xStwTVirkas2c0bBb8SJBSV4g4t+OUReiyQU8kc2lD8=; b=mluSC6uIfAF07gVItcASTtwoABcuJsZt9BImdaIHyw9Q1wsbov5kVxBdpWcT8BvcY+ hbAKoX8+ad3OE1V6NoRseSqjRf62f2hrLsREofHj7lQpvpw9gNAOBqAMLvcKpDwpT23p QFR8V+804dAc4wjCOWxd9wOduD/JNLAVvEgmLawvYeG2+848EKtLOtl3uWJZ7cOKA4nG VJHdvHq905uJ54KN/OG1GdrlhrJskJvXIMIE/8DLLTgSKaIu+2RpDZQSjTVsMMBqgBr7 XQn2NE96cIQ3fR08w3pyIVxHReleBmhH44b7dzDdROrCnIR7JNWXpp6zxyHdlLbK3lew qz0Q== Received: by 10.68.228.98 with SMTP id sh2mr18475315pbc.95.1346434686132; Fri, 31 Aug 2012 10:38:06 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id b4sm3849745pbw.28.2012.08.31.10.38.04 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 10:38:05 -0700 (PDT) Message-ID: <5040F676.4030305@exegin.com> Date: Fri, 31 Aug 2012 10:37:58 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "Jonathan Hui (johui)" References: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> In-Reply-To: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> Content-Type: multipart/alternative; boundary="------------040800080007070308090807" X-Gm-Message-State: ALoCoQlpG0oa0EWluAUz0o4XmpoC0sykrqioIU4Fhw5/Am6Cn9wRHpSI1AN8mud9HXeRk1s0wlBT Cc: "roll@ietf.org" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 31 Aug 2012 17:38:07 -0000 This is a multi-part message in MIME format. --------------040800080007070308090807 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have several comments listed below: 1. Why is the S field needed when the seed's length can be determined by the Opt Data Len field? 2. Nodes that do not understand the Trickle Multicast option should *not* process the packet further. This is to ensure those nodes do not cause packet storms or pass multiple copies of the same multicast datagram to higher layers. 3. Consider setting the two high order bits in the option type to b01 (discard the packet). This would be consistent with RFC 6553 and satisfy my comment 2. 4. Using the source IPv6 address as the seed won't work for hop-by-hop "tunneling", because the outer source address changes at each hop. 5. Exactly how is consistency/inconsistency used in the proactive mode? It doesn't seem to be explained anywhere. 6. For consistency, interoperability and implementation simplicity consider stipulating one scope used for the outer header (i.e. link-local scope). 7. Ideally, a link-local multicast group assigned to MPL should be used in the outer destination to ensure that only MPL aware nodes receive MPL encapsulated datagrams. An MPL multicast group would clearly define the boundaries of an MPL domain. - Dario On 03/08/2012 10:48 AM, Jonathan Hui (johui) wrote: > We've been working on an update to draft-ietf-roll-trickle-mcast. I've attached a draft of the proposed text. Note that we will *not* be presenting this draft at the ROLL WG meeting. > > In a prior mail, I noted some deficiencies with the initial draft that was posted. We will discuss some of these deficiencies at the ROLL WG meeting today. The purpose of this mail is to give you some insight into solving those deficiencies as well as incorporating suggestions that were brought up on the list. If you get a chance to glance through before the WG meeting, great. In either case, let's continue the discussion on the list. > > Always looking for your feedback, especially from implementors. > > Thanks! > > -- > Jonathan Hui > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------040800080007070308090807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit I have several comments listed below:

1. Why is the S field needed when the seed's length can be determined by the Opt Data Len field?

2. Nodes that do not understand the Trickle Multicast option should *not* process the packet further. This is to ensure those nodes do not cause packet storms or pass multiple copies of the same multicast datagram to higher layers.

3. Consider setting the two high order bits in the option type to b01 (discard the packet). This would be consistent with RFC 6553 and satisfy my comment 2.

4. Using the source IPv6 address as the seed won't work for hop-by-hop "tunneling", because the outer source address changes at each hop.

5. Exactly how is consistency/inconsistency used in the proactive mode? It doesn't seem to be explained anywhere.

6. For consistency, interoperability and implementation simplicity consider stipulating one scope used for the outer header (i.e. link-local scope).

7. Ideally, a link-local multicast group assigned to MPL should be used in the outer destination to ensure that only MPL aware nodes receive MPL encapsulated datagrams. An MPL multicast group would clearly define the boundaries of an MPL domain.

- Dario

On 03/08/2012 10:48 AM, Jonathan Hui (johui) wrote:

We've been working on an update to draft-ietf-roll-trickle-mcast.  I've attached a draft of the proposed text.  Note that we will *not* be presenting this draft at the ROLL WG meeting.

In a prior mail, I noted some deficiencies with the initial draft that was posted.  We will discuss some of these deficiencies at the ROLL WG meeting today.  The purpose of this mail is to give you some insight into solving those deficiencies as well as incorporating suggestions that were brought up on the list.  If you get a chance to glance through before the WG meeting, great.  In either case, let's continue the discussion on the list.

Always looking for your feedback, especially from implementors.

Thanks!

--
Jonathan Hui

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

--------------040800080007070308090807--