From rdroms.ietf@gmail.com Mon Apr 1 08:13:07 2013 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 3D97C21F9359 for ; Mon, 1 Apr 2013 08:13:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0O0vLd-05-q for ; Mon, 1 Apr 2013 08:13:05 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 099E521F9357 for ; Mon, 1 Apr 2013 08:13:04 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id d10so2657823vea.28 for ; Mon, 01 Apr 2013 08:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=DsWSXwIt09OfYTcCt4Zz/r0yQSJZTDQD5lJMJL2qQ48=; b=wL9+2v9/ORhCAHPGeZ6Z5aUEz2BYcnmnrhsJBw/5S2OQqWYmopm9MFrpJRJLaD5TYO FTE1AC9t/PMO7qM7gOqmMmiid5hivcyVctughSxYya35FbL5ywtHPJuY1ltRLI8DmZM6 qbBjfo4ZYzrYelLLgzfDBwHyLfTkSiit8FhmD05m1jSJIXKhHr0cVFZSZLOcru24qcy+ ELL1gUgg7Q7G1TeXYZ5ni7YcSkn6eAvvSq5jvJeEFHtwENZQZ7nhdcXXfYMls4+0bRCh AiFMwgS73gOE+Bcn5t/P8LafAyhpZ0+Tq7LxWlDWRF0T8cPYwC8yKpnPV1njx5sVpI7B BKXQ== X-Received: by 10.58.224.101 with SMTP id rb5mr9651932vec.17.1364829184372; Mon, 01 Apr 2013 08:13:04 -0700 (PDT) Received: from [10.131.33.85] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id xu4sm14024719vdb.11.2013.04.01.08.13.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 08:13:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com> Date: Mon, 1 Apr 2013 11:13:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9FD3690D-148B-4EF6-AE57-731CA249D9EE@gmail.com> References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1499) Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 15:13:07 -0000 I apologize for the late feedback... Section 8 seems somewhat out of place, as well as redundant with the = definition of "MPL Domain" in section 2 and the contents of section 5.1. Multicast scope 0x03 has never been formally defined as "subnet-local". = Delete the references to "subnet-local" in sections 5.1 and 8, leaving = just "scope value of 3". Note that scope value 3 is currently defined = as "reserved" in RFC 4291. I am working on publication of an RFC that = will re-define scope value 3 as "(unassigned)" so it can be used as = specified in draft-ietf-roll-trickle-mcast-04. In section 10.1, "the MPL Domain Address" is a little confusing. Does a = device belong to just a single MPL Domain, in which case it might be = clearer to write "the MPL Domain Address to which the source interface = belongs". Otherwise - and I don't think I see any text in the document = that explicitly constrains an interface to belonging to one MPL domain - = the text should read "an MPL Domain Address to which the source = interface belongs". - Ralph From rdroms.ietf@gmail.com Mon Apr 1 09:08:31 2013 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 59F4A1F0D0B for ; Mon, 1 Apr 2013 09:08:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqoLtE1URaIU for ; Mon, 1 Apr 2013 09:08:30 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBB51F0C74 for ; Mon, 1 Apr 2013 09:08:30 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id ib11so2465744vcb.21 for ; Mon, 01 Apr 2013 09:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=bJBU/2Ezfl/J5oaZqwlQMy5fcglQzOGa2P8lJnzGDFM=; b=pbvSVywPlJAxSFzucGwxJWde2Vjh46FFlr9FZUCvbq2xnairnX4w7zbWzGGnUm8l2T gIHiV4pVNlq3mDhcX6mu5M1cqbBNZZbRAUb00y1EcYuQQopQKumjGW3W8QXw/qmZpo8f QinD7SqmoRvO4GzwKakV530W5ZuzLoD7lgKy2IdImwZZmDds4/FdBVcet69PN2yVHrOE ou2x48mbfmdTl8ic098C5eZSd4N+27tqk1aCFGvdLPq+lyY7Y7mXr/jRJTqYVxbfUE+Z 9/BFljvLzUVUCut2rs6pBhCGQs0FSuWdvGUvFn5+b2X0jENnVM1ENMuOyHibHCEDkK9R rvbg== X-Received: by 10.52.76.164 with SMTP id l4mr8110526vdw.122.1364832510060; Mon, 01 Apr 2013 09:08:30 -0700 (PDT) Received: from [10.131.33.85] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id b7sm13852976veq.7.2013.04.01.09.08.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Apr 2013 09:08:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <9FD3690D-148B-4EF6-AE57-731CA249D9EE@gmail.com> Date: Mon, 1 Apr 2013 12:08:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com> <9FD3690D-148B-4EF6-AE57-731CA249D9EE@gmail.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1499) Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 16:08:31 -0000 Following up on my previous feedback - lacking a definition for scope 3, = the document should include a definition for scope 3 as used in MPL; = e.g., "all interfaces connected to a single mesh network". - Ralph On Apr 1, 2013, at 11:13 AM 4/1/13, Ralph Droms = wrote: > I apologize for the late feedback... >=20 > Section 8 seems somewhat out of place, as well as redundant with the = definition of "MPL Domain" in section 2 and the contents of section 5.1. >=20 > Multicast scope 0x03 has never been formally defined as = "subnet-local". Delete the references to "subnet-local" in sections 5.1 = and 8, leaving just "scope value of 3". Note that scope value 3 is = currently defined as "reserved" in RFC 4291. I am working on = publication of an RFC that will re-define scope value 3 as = "(unassigned)" so it can be used as specified in = draft-ietf-roll-trickle-mcast-04. >=20 > In section 10.1, "the MPL Domain Address" is a little confusing. Does = a device belong to just a single MPL Domain, in which case it might be = clearer to write "the MPL Domain Address to which the source interface = belongs". Otherwise - and I don't think I see any text in the document = that explicitly constrains an interface to belonging to one MPL domain - = the text should read "an MPL Domain Address to which the source = interface belongs". >=20 > - Ralph >=20 From internet-drafts@ietf.org Mon Apr 1 11:00:09 2013 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 5C41A21E80AA; Mon, 1 Apr 2013 11:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIN+aW6BhscW; Mon, 1 Apr 2013 11:00:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A377321E80AE; Mon, 1 Apr 2013 11:00:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401180007.18866.32700.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 11:00:07 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 18:00:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : A Mechanism to Measure the Routing Metrics along a Point= -to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-10.txt Pages : 28 Date : 2013-04-01 Abstract: This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-measurement-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=79604f80b=mukul@uwm.edu Mon Apr 1 12:13:40 2013 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 550F411E80E7 for ; Mon, 1 Apr 2013 12:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDe2BSup8VCD for ; Mon, 1 Apr 2013 12:13:39 -0700 (PDT) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9A11E80E6 for ; Mon, 1 Apr 2013 12:13:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAG++WVF/AAAB/2dsb2JhbABDgztBgl+8LoESgxMBAQEEAQEBIEs3BAEBAwINGQIpJgIIBhMJiAsHBZ9sjlWJAIkPgSOMXX0pEgaCJ4ETA4h6jXGBH49sgymCCg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 260362E0F1C for ; Mon, 1 Apr 2013 14:13:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ykZKZhVkYFn for ; Mon, 1 Apr 2013 14:13:36 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id C524D2E0F2C for ; Mon, 1 Apr 2013 14:13:36 -0500 (CDT) Date: Mon, 1 Apr 2013 14:13:36 -0500 (CDT) From: Mukul Goyal To: roll < roll@ietf.org> Message-ID: <2092984169.330874.1364843616693.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20130401180007.18866.32700.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-measurement-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 19:13:40 -0000 Hi all This version contains the following changes made in response to IESG comments: 1. The Address vector must now consist of global or unique local IPv6 addresses only. Further, we now explicitly require the addresses in the Address vector to be the ones with same (elided) prefix as the Start Point Address and End Point Address. 2. The Start Point Address and End Point Address now have to be global or unique local. 3. Section 3.2 (Secure MO): The Start Point decides whether Secure MOs should be used and the Security Configuration to be used for the purpose. All the Intermediate Points and the End Point MUST use the same Security Configuration as the one used by the Start Point. 4. Section 4.4: Previously, we required the use of binary 10000000 as the RPLInstanceID value whenever the route being measured was a Source Route. But, there was no real reason to do so. So, the new version explicitly states that RPLInstanceID "field does not have any significance when a Source Route is being measured and hence can be set to any value." 5. Section 8 (Security Considerations) has been updated based on the changes done in Section 3.2. 6. Minor editorial changes. In my opinion, these changes do not affect how this mechanism is to be used in real use-cases. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Monday, April 1, 2013 1:00:07 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-10.txt Pages : 28 Date : 2013-04-01 Abstract: This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-measurement-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From guo@merl.com Tue Apr 2 15:39:06 2013 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 8380E21F8A0B for ; Tue, 2 Apr 2013 15:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJqD1DdzlP6m for ; Tue, 2 Apr 2013 15:39:05 -0700 (PDT) Received: from ns1.merl.com (ns1.merl.com [137.203.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081FF21F85C3 for ; Tue, 2 Apr 2013 15:39:04 -0700 (PDT) Received: from zack.merl.com (zack.merl.com [137.203.134.14]) by ns1.merl.com (8.13.8/8.12.10) with ESMTP id r32Md4kC004681 for ; Tue, 2 Apr 2013 18:39:04 -0400 Received: from [127.0.0.1] (dulcian.merl.com [137.203.143.95]) by zack.merl.com (Postfix) with ESMTP id 27D4F2C10E1 for ; Tue, 2 Apr 2013 18:39:04 -0400 (EDT) Message-ID: <515B5E02.4000709@merl.com> Date: Tue, 02 Apr 2013 18:38:58 -0400 From: Jianlin Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] draft-guo-roll-loop-free-dodag-repair-01 uploaded X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 22:39:06 -0000 Dear ROLL members, Draft-guo-roll-loop-free-dodag-repair-01 is uploaded. In this version, we introduced a piggybacked data option for transferring delay sensitive data during route repair process. This option is necessary when a node has urgent data to transmit, but has an empty parent set. The piggybacked data can be included in DODAG Information Solicitation (DIS) message or DODAG Repair Request (DRQ) message. Please review draft and make your comments. Jianlin Guo Mitsubishi Electric Research Lab From stokcons@xs4all.nl Wed Apr 3 03:14:07 2013 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 7F24721F86B8 for ; Wed, 3 Apr 2013 03:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.355 X-Spam-Level: * X-Spam-Status: No, score=1.355 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXvOtD62DUfr for ; Wed, 3 Apr 2013 03:14:07 -0700 (PDT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id ADC4421F861A for ; Wed, 3 Apr 2013 03:14:06 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id r33AE4N6080397; Wed, 3 Apr 2013 12:14:04 +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); Wed, 03 Apr 2013 12:14:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Apr 2013 12:14:04 +0200 From: peter van der Stok To: , Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (oqPz5Oc44Pf+eiHXwdCizA8I0RGqsYVv) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [Roll] roll-applicability-template-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 10:14:07 -0000 Hi Michael, Downloading the applicability template (pdf), I discovered a funny table of contents sections 2.1 and 2.2 have the same title: Network Topologies, section 2.2.1 is called Traffic characteristics; I assume this should be the section 2.2 title. By the way is the title "N-cast" for section 2.2.7.not sufficient instead of "duocast and N-cast" ? Greetings, peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From iesg-secretary@ietf.org Thu Apr 4 06:45:00 2013 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 1C28421F8BEA; Thu, 4 Apr 2013 06:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWl3Bfu2Ii16; Thu, 4 Apr 2013 06:44:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAAF21F8C98; Thu, 4 Apr 2013 06:44:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130404134458.27257.45806.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 06:44:58 -0700 Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Document Action: 'A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network' to Experimental RFC (draft-ietf-roll-p2p-measurement-10.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 13:45:00 -0000 The IESG has approved the following document: - 'A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network' (draft-ietf-roll-p2p-measurement-10.txt) as Experimental RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ Technical Summary This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The mechanism described in this document can be used by an Origin in an LLN to measure the aggregated values of some routing metrics along a route to a Target within the LLN. The route is measured in the direction from the Origin to the Target. Such a route could be a source route or a hop-by-hop route established using RPL [RFC6550] or P2P-RPL [I-D.ietf-roll-p2p-rpl]. The Origin decides what metrics to measure and sends a Measurement Request message, carrying the desired routing metric objects, along the route. On receiving a Measurement Request, an Intermediate Router updates the routing metric values inside the message and forwards it to the next hop on the route. Thus, the Measurement Request accumulates the values of the routing metrics for the complete route as it travels towards the Target. Upon receiving the Measurement Request, the Target unicasts a Measurement Reply message, carrying the accumulated values of the routing metrics, back to the Origin. Optionally, the Origin may allow an Intermediate Router to generate the Measurement Reply if it already knows the relevant routing metric values along rest of the route. Working Group Summary: No discontent. Once again, few comments, request for clarifications that have all been addressed by in this revision. Document Quality: Yes there are several known implementations of this specification, with interop testing: An interoperability was carried out last month with INRIA's implementation against Sigma Design's implementation. The report can be found: http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf Experiments with P2P-RPL have also taken place on the Senslab testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz: http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf Personnel: The Document Shepherd is JP Vasseur (jvasseur@cisco.com) The Responsible AD is Adrian Farrel (adrian@olddog.co.uk) From iesg-secretary@ietf.org Thu Apr 4 06:45:00 2013 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 4BB5521F8C93 for ; Thu, 4 Apr 2013 06:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdrEYF4FG0Xq; Thu, 4 Apr 2013 06:45:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2860121F8CA5; Thu, 4 Apr 2013 06:44:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43 X-IETF-Draft-string: draft-ietf-roll-p2p-measurement X-IETF-Draft-revision: 10 Message-ID: <20130404134458.27257.38224.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 06:44:58 -0700 Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Document Action: 'A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network' to Experimental RFC (draft-ietf-roll-p2p-measurement-10.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 13:45:00 -0000 The IESG has approved the following document: - 'A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network' (draft-ietf-roll-p2p-measurement-10.txt) as Experimental RFC This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ Technical Summary This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The mechanism described in this document can be used by an Origin in an LLN to measure the aggregated values of some routing metrics along a route to a Target within the LLN. The route is measured in the direction from the Origin to the Target. Such a route could be a source route or a hop-by-hop route established using RPL [RFC6550] or P2P-RPL [I-D.ietf-roll-p2p-rpl]. The Origin decides what metrics to measure and sends a Measurement Request message, carrying the desired routing metric objects, along the route. On receiving a Measurement Request, an Intermediate Router updates the routing metric values inside the message and forwards it to the next hop on the route. Thus, the Measurement Request accumulates the values of the routing metrics for the complete route as it travels towards the Target. Upon receiving the Measurement Request, the Target unicasts a Measurement Reply message, carrying the accumulated values of the routing metrics, back to the Origin. Optionally, the Origin may allow an Intermediate Router to generate the Measurement Reply if it already knows the relevant routing metric values along rest of the route. Working Group Summary: No discontent. Once again, few comments, request for clarifications that have all been addressed by in this revision. Document Quality: Yes there are several known implementations of this specification, with interop testing: An interoperability was carried out last month with INRIA's implementation against Sigma Design's implementation. The report can be found: http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf Experiments with P2P-RPL have also taken place on the Senslab testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz: http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf Personnel: The Document Shepherd is JP Vasseur (jvasseur@cisco.com) The Responsible AD is Adrian Farrel (adrian@olddog.co.uk) From adrian@olddog.co.uk Sun Apr 7 07:00:18 2013 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 89C5D21F85E7 for ; Sun, 7 Apr 2013 07:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr5b0XFIrYnP for ; Sun, 7 Apr 2013 07:00:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B374521F8554 for ; Sun, 7 Apr 2013 07:00:16 -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 r37E0EiK018005 for ; Sun, 7 Apr 2013 15:00: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 r37E0BUe017909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Apr 2013 15:00:12 +0100 From: "Adrian Farrel" To: References: In-Reply-To: Date: Sun, 7 Apr 2013 15:00:11 +0100 Message-ID: <04dc01ce3398$38c4f300$aa4ed900$@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: Ac4zkUDUlCSvW+AtQdSaPlaGrPU3tQABt0DQ Content-Language: en-gb Subject: [Roll] Errata on RFC 6550 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 14:00:18 -0000 Re-send to ROLL-WG only > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 07 April 2013 14:13 > To: roll@ietf.org > Cc: 'wintert@acm.org'; 'pthubert@cisco.com'; 'abr@sdesigns.dk'; > 'jhui@archrock.com'; 'kelsey@ember.com'; 'pal@cs.stanford.edu'; > 'kpister@dustnetworks.com'; 'rstruik.ext@gmail.com'; 'jpv@cisco.com'; > 'roger.alexander@cooperindustries.com'; 'stbryant@cisco.com'; > 'mcr+ietf@sandelman.ca'; 'jpv@cisco.com' > Subject: Errata on RFC 6550 > > Hi, > > Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Tony). > > I'd like opinions from authors / the WG before acting on these. > > http://www.rfc-editor.org/errata_search.php?eid=3580 > This looks like a block-copy error. I believe the report is right, and although the > error is relatively trivial, Tony is right to mark this as Technical because the error is > in part of the text that describes expected behavior. > I propose to accept this report. > > http://www.rfc-editor.org/errata_search.php?eid=3581 > This looks like a simple typographic error. A value of 0x00000000 was suggested > for an 8-bit field. > While this is an editorial error, I don't believe that the error causes any confusion > in implementation or use, and so I propose to mark the report "Hold for > Document Update" so that the text can be fixed in a future revision if one is > made. > > Thanks, > Adrian From yvonne-anne.pignolet@ch.abb.com Sun Apr 7 22:23:32 2013 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 0A96F21F913E for ; Sun, 7 Apr 2013 22:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.037 X-Spam-Level: X-Spam-Status: No, score=-9.037 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gizvy29AMws for ; Sun, 7 Apr 2013 22:23:30 -0700 (PDT) Received: from nse1.abb.com (nse1.abb.com [129.35.204.68]) by ietfa.amsl.com (Postfix) with ESMTP id 930E821F913C for ; Sun, 7 Apr 2013 22:23:29 -0700 (PDT) Received: from mail04.ch.abb.com (ch-s-0001691.ch.abb.com [138.223.3.121]) by nse1.abb.com (8.13.8/8.13.8) with ESMTP id r385NRSA013905 for ; Mon, 8 Apr 2013 07:23:28 +0200 In-Reply-To: <5154548A.3080600@gmail.com> References: <5154548A.3080600@gmail.com> To: Routing Over Low power and Lossy networks MIME-Version: 1.0 X-KeepSent: CB46C4A4:766D1011-C1257B47:001CCC88; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP1 November 30, 2010 From: Yvonne-Anne Pignolet Message-ID: Date: Mon, 8 Apr 2013 07:23:24 +0200 X-MIMETrack: Serialize by Router on MAIL04.CH.ABB.COM/SRV/ABB(Release 8.5.3FP3 HF205|February 15, 2013) at 04/08/2013 07:23:26 AM, Serialize complete at 04/08/2013 07:23:26 AM Content-Type: multipart/related; boundary="=_related 001CEEC3C1257B47_=" Subject: Re: [Roll] RPL code for Omnet X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 05:23:32 -0000 This is a multipart message in MIME format. --=_related 001CEEC3C1257B47_= Content-Type: multipart/alternative; boundary="=_alternative 001CEEC3C1257B47_=" --=_alternative 001CEEC3C1257B47_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alex Have you had any luck in finding an Omnet implementation of RPL? If yes=20 I'd be very interested to know more.... Cheers Yvonne-Anne PS: Do you know RPL j-sim http://code.google.com/p/rpl-jsim-platform/?=20 Might be helpful for you too...=20 Yvonne-Anne Pignolet Dr. Sc. ETH Z=FCrich ABB Corporate Research Segelhofstrasse 1K 5400 Baden-D=E4ttwil, Switzerland Phone: +41 58 586 86 56 Mobile: +41 79 766 10 54 email: yvonne-anne.pignolet@ch.abb.com From: Alex To: roll@ietf.org Date: 28.03.2013 15:35 Subject: [Roll] RPL code for Omnet Sent by: roll-bounces@ietf.org Dear all, i've repeatedly used RPL in wireless sensor networks using the Contiki OS. = Now i'd like to test RPL functionalities in the OMNET simulator. Are you aware of any RPL source code for Omnet? Thanks in advance, Alex=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 001CEEC3C1257B47_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alex

Have you had any luck in finding an Omnet implementation of RPL? If yes I'd be very interested to know more....=

Cheers
Yvonne-Anne

PS: Do you know RPL j-sim http://code.google.com/p/rpl-jsim-platform/? Might be helpful for you too...
Yvonne-Anne Pignolet
Dr. Sc. ETH Z=FCrich
ABB Corporate Research
Segelhofstrasse 1K
5400 Baden-D=E4ttwil, Switzerland
Phone: +41 58 586 86 56
Mobile: +41 79 766 10 54
email: yvonne-anne.pignolet@ch.abb.com





From:     =    Alex <alfragk@gmail.com&= gt;
To:     &n= bsp;  roll@ietf.org
Date:     =    28.03.2013 15:35
Subject:   &nbs= p;    [Roll] RPL code for Omnet
Sent by:   &nbs= p;    roll-bounces@ietf.or= g



Dear all,

i've repeatedly used RPL in wireless sensor networks using the Contiki OS.

Now i'd like to test RPL functionalities in the OMNET simulator.

Are you aware of any RPL source code for Omnet?


Thanks in advance,

Alex=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 001CEEC3C1257B47_=-- --=_related 001CEEC3C1257B47_= Content-Type: image/gif Content-ID: <_1_0B75FE500B75FA7C001CEEC3C1257B47> Content-Transfer-Encoding: base64 R0lGODlhSgAdALMNAPiusf8AD/q/wfaZm/BTVfWNkPSAg/NvcfvNze9ARO80N/3i4/7+/v///wAA AAAAACH5BAHoAw0ALAAAAABKAB0AAAT/sMk5Qbih4SCob8O2aRgBfKCIkZeJosW4Ga8Uqpl6fLfK YrvaRPTL1HpEHI2ClKmWNYsT03k1V7gAgpktYrY1Q3J27GaDNjMOjfL5rGpVgovzXuYv6RRzQl0v doATfzldLwduImx0iXKMY44vdXV+cYqPexuLFZMqfR6EgZ8pnZ4vBKUbBJWpQKCWrpKtKzywAZuh OlG2F6NpswO1wDVZhZSYWCIKq8iAKstC0dLT1NUfMbwXBa+zsaSNuhSo2QHMg+Rav+AqYBLFxsfq kGvymZcS2Ojb590j3/PHxqEz988ekYLJikkQ8A4ejioInb2rl9CQmIkNoeSaGNHhmwQNZgNhwNNR ZDmKErOsYugJgcstLxHo2VBlY5Z9NnFsu7iB5AuQIpbkfFPy3QI7+2rk8zd0QzCUHjEMYDCTVjQc J5pegFJUCQMGiEQQrCHQldan/NZdmPpV57SlK3ISSNoM3twFX79GAAA7 --=_related 001CEEC3C1257B47_=-- From yvonne-anne.pignolet@ch.abb.com Sun Apr 7 22:23:34 2013 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 B3E0121F9173 for ; Sun, 7 Apr 2013 22:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.606 X-Spam-Level: X-Spam-Status: No, score=-7.606 tagged_above=-999 required=5 tests=[AWL=-1.431, BAYES_00=-2.599, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k68vhNHrhD3 for ; Sun, 7 Apr 2013 22:23:34 -0700 (PDT) Received: from nse1.abb.com (nse1.abb.com [129.35.204.68]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2021F915A for ; Sun, 7 Apr 2013 22:23:33 -0700 (PDT) Received: from mail04.ch.abb.com (ch-s-0001691.ch.abb.com [138.223.3.121]) by nse1.abb.com (8.13.8/8.13.8) with ESMTP id r385NWGO013936 for ; Mon, 8 Apr 2013 07:23:32 +0200 Auto-Submitted: auto-generated To: Routing Over Low power and Lossy networks Message-ID: From: Yvonne-Anne Pignolet Date: Mon, 8 Apr 2013 07:19:46 +0200 X-MIMETrack: Serialize by Router on MAIL04.CH.ABB.COM/SRV/ABB(Release 8.5.3FP3 HF205|February 15, 2013) at 04/08/2013 07:23:30 AM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3" Subject: [Roll] Message Tracking ->Re: RPL code for Omnet X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 05:23:34 -0000 --0__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3 Content-type: multipart/alternative; Boundary="1__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3" --1__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3 Content-type: text/plain; charset=US-ASCII Tracking Request Target roll@ietf.org recipient (s): Request 04/08/2013 07:19:37 AM date: Responses: Tracking response information: --1__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Tracking Request
Target recipient(s):
    roll@ietf.org
Request date:
    04/08/2013 07:19:37 AM
Responses:

Tracking response information: --1__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3-- --0__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <1__=4EBBF1D4DF8EC5A38f9e8a93df938@ch.abb.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=4EBBF1D4DF8EC5A38f9e8a93df938690918c4EBBF1D4DF8EC5A3-- From adrian@olddog.co.uk Tue Apr 9 15:12:59 2013 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 DADE021F9966 for ; Tue, 9 Apr 2013 15:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OMDebt6pWMJ for ; Tue, 9 Apr 2013 15:12:59 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0D01721F9964 for ; Tue, 9 Apr 2013 15:12:58 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39MCv82026956 for ; Tue, 9 Apr 2013 23:12:58 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r39MCv5Y026946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 9 Apr 2013 23:12:57 +0100 From: "Adrian Farrel" To: "'Routing Over Low power and Lossy networks'" Date: Tue, 9 Apr 2013 23:12:55 +0100 Message-ID: <02ab01ce356f$637de4c0$2a79ae40$@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: Ac41b1BzP1N/FWGlTj6z65Q3i4FL1w== Content-Language: en-gb Subject: [Roll] No comments? [Was: Errata on RFC 6550] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:13:00 -0000 > Hi, > > Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Tony). > > I'd like opinions from authors / the WG before acting on these. > > http://www.rfc-editor.org/errata_search.php?eid=3580 > This looks like a block-copy error. I believe the report is right, and > although the error is relatively trivial, Tony is right to mark this as > Technical because the error is in part of the text that describes > expected behavior. > I propose to accept this report. > > http://www.rfc-editor.org/errata_search.php?eid=3581 > This looks like a simple typographic error. A value of 0x00000000 was > suggested for an 8-bit field. > While this is an editorial error, I don't believe that the error causes any > confusion in implementation or use, and so I propose to mark the > report "Hold for Document Update" so that the text can be fixed in > a future revision if one is made. > > Thanks, > Adrian From mariainesrobles@googlemail.com Wed Apr 10 12:19:46 2013 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 1EF0521F8F2F for ; Wed, 10 Apr 2013 12:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLvG7psycyfP for ; Wed, 10 Apr 2013 12:19:45 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E83A921F8EF1 for ; Wed, 10 Apr 2013 12:19:44 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id f13so675529vbg.28 for ; Wed, 10 Apr 2013 12:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=swdASY/Mu1urUv8nQFi9/Oi9WBW7tsFQ9oix1mBT8OQ=; b=r1MUPKm0IXA7u4owIDXaqk1hBfIIQR5QDTtnV8n/R2LAbHqXmnieHP3XWRkJVp0ZDj 115tDNXFoGXqitKNzxQq6DVmvt5moTtS7GGuUzfAZms84p8vJrrvf5FdUweLQqPtnyaO zXzfPQoutgfxG4unh5v55TM4EViJBLcFME8scBbICLdTu2iIIE4sDhNN/+emWBWRcz3r jlF3D36599aSGOnLgIux1aXi8hE6E6Op5ns0PUIUNLqRXs+5n/4giuYsjui8xsr5YDnZ JmqBWNdalYoY1GZaQ5KWUJdfxUmsSvdQcaK43S//t0HK22NkEPfzdMCiIkW3WkWaMcA8 PAAQ== MIME-Version: 1.0 X-Received: by 10.52.17.83 with SMTP id m19mr2251091vdd.73.1365621583916; Wed, 10 Apr 2013 12:19:43 -0700 (PDT) Received: by 10.220.177.135 with HTTP; Wed, 10 Apr 2013 12:19:43 -0700 (PDT) Date: Wed, 10 Apr 2013 16:19:43 -0300 Message-ID: From: Ines Robles To: roll@ietf.org Content-Type: multipart/alternative; boundary=bcaec502d1ea686b1a04da068d74 Subject: [Roll] No comments? [Was: Errata on RFC 6550] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 19:19:46 -0000 --bcaec502d1ea686b1a04da068d74 Content-Type: text/plain; charset=ISO-8859-1 Hello, About the first problem, I didn't probe that in my wsn, but was posted before here http://www.ietf.org/mail-archive/web/roll/current/msg06740.html, if it was no reported I think it should be C1. Regards, Ines Robles. 2013/4/10 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/roll > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Roll mailing list submissions to > roll@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/roll > or, via email, send a message with subject or body 'help' to > roll-request@ietf.org > > You can reach the person managing the list at > roll-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Roll digest..." > > > Today's Topics: > > 1. No comments? [Was: Errata on RFC 6550] (Adrian Farrel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 9 Apr 2013 23:12:55 +0100 > From: "Adrian Farrel" > To: "'Routing Over Low power and Lossy networks'" > Subject: [Roll] No comments? [Was: Errata on RFC 6550] > Message-ID: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> > Content-Type: text/plain; charset="us-ascii" > > > Hi, > > > > Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Tony). > > > > I'd like opinions from authors / the WG before acting on these. > > > > http://www.rfc-editor.org/errata_search.php?eid=3580 > > This looks like a block-copy error. I believe the report is right, and > > although the error is relatively trivial, Tony is right to mark this as > > Technical because the error is in part of the text that describes > > expected behavior. > > I propose to accept this report. > > > > http://www.rfc-editor.org/errata_search.php?eid=3581 > > This looks like a simple typographic error. A value of 0x00000000 was > > suggested for an 8-bit field. > > While this is an editorial error, I don't believe that the error causes > any > > confusion in implementation or use, and so I propose to mark the > > report "Hold for Document Update" so that the text can be fixed in > > a future revision if one is made. > > > > Thanks, > > Adrian > > > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 63, Issue 7 > *********************************** > --bcaec502d1ea686b1a04da068d74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,


About the first problem,=A0I didn't probe tha= t in my wsn, but=A0=A0was posted before here=A0http://www.ietf.org/mail-ar= chive/web/roll/current/msg06740.html, if it was no reported I think it = should be C1.=A0

Regards,

Ines Robles.

2013/4/10 <roll-request@ietf.org>
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

ht= tps://www.ietf.org/mailman/listinfo/roll

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send Roll mailing list submissions to
=A0 =A0 =A0 =A0 roll@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/roll
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 roll-request@ietf.= org

You can reach the person managing the list at
=A0 =A0 =A0 =A0 roll-owner@ietf.org<= /a>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Roll digest..."


Today's Topics:

=A0 =A01. No comments? [Was: Errata on RFC 6550] (Adrian Farrel)


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

Message: 1
Date: Tue, 9 Apr 2013 23:12:55 +0100
From: "Adrian Farrel" <= adrian@olddog.co.uk>
To: "'Routing Over Low power and Lossy networks'" <roll@ietf.org>
Subject: [Roll] No comments? [Was: Errata on RFC 6550]
Message-ID: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk>
Content-Type: text/plain; =A0 =A0 =A0 charset=3D"us-ascii"

> Hi,
>
> Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Tony)= .
>
> I'd like opinions from authors / the WG before acting on these. >
> http://www.rfc-editor.org/errata_search.php?eid=3D3580 > This looks like a block-copy error. I believe the report is right, and=
> although the error is relatively trivial, Tony is right to mark this a= s
> Technical because the error is in part of the text that describes
> expected behavior.
> I propose to accept this report.
>
> http://www.rfc-editor.org/errata_search.php?eid=3D3581 > This looks like a simple typographic error. A value of 0x00000000 was<= br> > suggested for an 8-bit field.
> While this is an editorial error, I don't believe that the error c= auses any
> confusion in implementation or use, and so I propose to mark the
> report "Hold for Document Update" so that the text can be fi= xed in
> a future revision if one is made.
>
> Thanks,
> Adrian



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

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


End of Roll Digest, Vol 63, Issue 7
***********************************

--bcaec502d1ea686b1a04da068d74-- From mcr@sandelman.ca Wed Apr 10 18:21:38 2013 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 3B21B21F888B for ; Wed, 10 Apr 2013 18:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL1IwBoHLhwd for ; Wed, 10 Apr 2013 18:21:37 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 6715421F89E2 for ; Wed, 10 Apr 2013 18:21:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DC49920172; Wed, 10 Apr 2013 21:31:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 157F4638F7; Wed, 10 Apr 2013 21:21:17 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 06AC8638E8; Wed, 10 Apr 2013 21:21:17 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> References: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] No comments? [Was: Errata on RFC 6550] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 01:21:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Adrian" =3D=3D Adrian Farrel writes: >> Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Ton= y). >>=20 >> I'd like opinions from authors / the WG before acting on these. My opinion is that the comments seem bang on. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWYQDIqHRg3pndX9AQLuPwP/YzfuBjc8IxGPGP0j+h65L7W82MaPbufQ 8aowkDODkm8uIUQ837akDCLLfU2x0a2/FOH3UxADOajDtx10vQuI7s38YHYX8675 96zkGV19d0H3GmfZteQm9qEV5QTHlG+FrjUCwjf0DTp+AE/Di0rILe/NMKO04CZg 99NLyPut/8Q= =Lhhq -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Wed Apr 10 20:31:09 2013 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 1FFF921F8B9B for ; Wed, 10 Apr 2013 20:31:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pekdKbkmssc6 for ; Wed, 10 Apr 2013 20:31:08 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5115821F8BA6 for ; Wed, 10 Apr 2013 20:31:08 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bv4so65173qab.15 for ; Wed, 10 Apr 2013 20:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=NbhbCKBZH4pHk4NDadcXfP6V02aDWOk2PXkVWYkeI8s=; b=0u1Buw7pVIiwaI9ABjlJYWR/zCtzxeji2v03z118uIaM0tA7ict7R/k7uSiTLocaDg NhP3i+O5Zf01UAtqgpbk7Hr2Xs7ZisyTvRS9TSgTXiajTgDrLK2jyuZGYERj1DaH/z2t p/PuHYaJlf0a2dsr+Vdyukgdev+lapM2rVkN8oYxB7uylXLlaHUDUwl36Zw3CktTE7YC bUIiH7j5VQDWHYyu0649aMaY1qYGzSwjTh4yFGlARotiCE4jQq05kiTb1wdv51604yoa /VQoPigzLMl+VP2UDydzbEJnHeIXllc81x3ONrIqS+HRvF+vup8m3L+W0lSEZkvc/9LR HE8Q== X-Received: by 10.49.24.148 with SMTP id u20mr5888543qef.32.1365651065711; Wed, 10 Apr 2013 20:31:05 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:4b3:8bdc:791c:44e4? ([2001:420:2481:20:4b3:8bdc:791c:44e4]) by mx.google.com with ESMTPS id e2sm4411765qey.3.2013.04.10.20.31.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 20:31:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ralph Droms In-Reply-To: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> Date: Wed, 10 Apr 2013 23:31:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1503) Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] No comments? [Was: Errata on RFC 6550] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 03:31:09 -0000 On Apr 9, 2013, at 6:12 PM 4/9/13, Adrian Farrel = wrote: >> Hi, >>=20 >> Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, = Tony). >>=20 >> I'd like opinions from authors / the WG before acting on these. >>=20 >> http://www.rfc-editor.org/errata_search.php?eid=3D3580 >> This looks like a block-copy error. I believe the report is right, = and >> although the error is relatively trivial, Tony is right to mark this = as >> Technical because the error is in part of the text that describes >> expected behavior. >> I propose to accept this report. >>=20 >> http://www.rfc-editor.org/errata_search.php?eid=3D3581 >> This looks like a simple typographic error. A value of 0x00000000 was >> suggested for an 8-bit field. >> While this is an editorial error, I don't believe that the error = causes any >> confusion in implementation or use, and so I propose to mark the >> report "Hold for Document Update" so that the text can be fixed in >> a future revision if one is made. Adrian - I agree with your proposed actions in processing these errata. - Ralph >>=20 >> Thanks, >> Adrian >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Wed Apr 10 21:19:10 2013 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 2A87821F8AD1 for ; Wed, 10 Apr 2013 21:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vckMgveMYbE0 for ; Wed, 10 Apr 2013 21:19:09 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 87BAE21F8976 for ; Wed, 10 Apr 2013 21:19:09 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id y10so637878pdj.12 for ; Wed, 10 Apr 2013 21:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=CLRtwJvMEUeIS3ZLNg3pyoIN31MrRkkukClwp5p2p34=; b=xI/eitgx0wx+T9bxbPn4Po3opxZdgja0lUwS+CSut1D5J8IAb9ZXAlR0JHUrWC8HJ4 yhYr4no6VvsFLvSzoJ0g6RcSJe4uq81ob/dEnUZNOjvXV0SdqoDm9S3WFGBkSYNkTDD7 +ATi1PdiXSW4WYGco97LYx8auTwlv4tar2eOIiD6HiKGxSrZcyKeBKnsy5yP8n171WZb YKjIPg+HRDe712zmW9RTqL6jCGVLrUtdC+cD7HIIid9LdmeSqVwSbJGlDs01DOQ17dpu BM08J1dzkyujLEQnBPArSPg4LcVSLawGSLWqw/YshkOYl/YKkY4575U2tzj0sJvDV75Y oZEg== MIME-Version: 1.0 X-Received: by 10.66.163.129 with SMTP id yi1mr7122858pab.93.1365653949147; Wed, 10 Apr 2013 21:19:09 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Wed, 10 Apr 2013 21:19:08 -0700 (PDT) In-Reply-To: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> References: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> Date: Thu, 11 Apr 2013 06:19:08 +0200 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] No comments? [Was: Errata on RFC 6550] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 04:19:10 -0000 I agree with proposal, and have no comments, AB On 4/10/13, Adrian Farrel wrote: >> Hi, >> >> Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Tony). >> >> I'd like opinions from authors / the WG before acting on these. >> >> http://www.rfc-editor.org/errata_search.php?eid=3580 >> This looks like a block-copy error. I believe the report is right, and >> although the error is relatively trivial, Tony is right to mark this as >> Technical because the error is in part of the text that describes >> expected behavior. >> I propose to accept this report. >> >> http://www.rfc-editor.org/errata_search.php?eid=3581 >> This looks like a simple typographic error. A value of 0x00000000 was >> suggested for an 8-bit field. >> While this is an editorial error, I don't believe that the error causes >> any >> confusion in implementation or use, and so I propose to mark the >> report "Hold for Document Update" so that the text can be fixed in >> a future revision if one is made. >> >> Thanks, >> Adrian > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abdussalambaryun@gmail.com Wed Apr 10 21:36:00 2013 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 70B3321F8CF0 for ; Wed, 10 Apr 2013 21:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsQQCu2zQd5z for ; Wed, 10 Apr 2013 21:35:58 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3B95921F8CE5 for ; Wed, 10 Apr 2013 21:35:58 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kx1so697639pab.28 for ; Wed, 10 Apr 2013 21:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y1zJyPqrhW7cdeplUKV0YfKE1z49fqRjqvgG+daULLM=; b=aGehKAodK9UP0WdVN1piuLVPnQh1ytdFs6w76w9Q6vTKTov4ePmlHrCpZfHq/S4LLj 4tFN8j0JVRsDsMxljysWyOVzFzZ0gKAwjEsZgjObFN1eQ5x08qcyh86sVEWX8lSyoJch cy0VunbVIh4O9QhUhkK97jJgP/ve/JLubxjDwRdbkOp07imtZ11uw+922TEkaUjWSZL0 34vQGUkTEbM6cy/cY7u4vdmNQUI3m++h+prHUbGC0iS7qyyFPD1bGaoZXH5hl9/RGH2q RU2pTXH4TbDvGZlpk1WmmePWcL34Mjt0UppwE3x1swovD8y5IjdYyiEwLp+9kvoX7YCD 3fAw== MIME-Version: 1.0 X-Received: by 10.66.122.8 with SMTP id lo8mr7148140pab.163.1365654957920; Wed, 10 Apr 2013 21:35:57 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Wed, 10 Apr 2013 21:35:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Apr 2013 06:35:57 +0200 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset=ISO-8859-1 Cc: Ines Robles Subject: Re: [Roll] No comments? [Was: Errata on RFC 6550] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 04:36:00 -0000 Hi Ines, Thanks for reminder, so the errata 3580 was reported after a year from an input comment in 2012. Thanks to Consoli Federico, and Tony Cheneau. AB On 4/10/13, Ines Robles wrote: > Hello, > > About the first problem, I didn't probe that in my wsn, but was posted > before here > http://www.ietf.org/mail-archive/web/roll/current/msg06740.html, > if it was no reported I think it should be C1. > > Regards, > > Ines Robles. > > 2013/4/10 > >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/roll >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send Roll mailing list submissions to >> roll@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/roll >> or, via email, send a message with subject or body 'help' to >> roll-request@ietf.org >> >> You can reach the person managing the list at >> roll-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Roll digest..." >> >> >> Today's Topics: >> >> 1. No comments? [Was: Errata on RFC 6550] (Adrian Farrel) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 9 Apr 2013 23:12:55 +0100 >> From: "Adrian Farrel" >> To: "'Routing Over Low power and Lossy networks'" >> Subject: [Roll] No comments? [Was: Errata on RFC 6550] >> Message-ID: <02ab01ce356f$637de4c0$2a79ae40$@olddog.co.uk> >> Content-Type: text/plain; charset="us-ascii" >> >> > Hi, >> > >> > Tony Cheneau has raised two Errata Reports for RFC 6550 (thanks, Tony). >> > >> > I'd like opinions from authors / the WG before acting on these. >> > >> > http://www.rfc-editor.org/errata_search.php?eid=3580 >> > This looks like a block-copy error. I believe the report is right, and >> > although the error is relatively trivial, Tony is right to mark this as >> > Technical because the error is in part of the text that describes >> > expected behavior. >> > I propose to accept this report. >> > >> > http://www.rfc-editor.org/errata_search.php?eid=3581 >> > This looks like a simple typographic error. A value of 0x00000000 was >> > suggested for an 8-bit field. >> > While this is an editorial error, I don't believe that the error causes >> any >> > confusion in implementation or use, and so I propose to mark the >> > report "Hold for Document Update" so that the text can be fixed in >> > a future revision if one is made. >> > >> > Thanks, >> > Adrian >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> End of Roll Digest, Vol 63, Issue 7 >> *********************************** >> > From adrian@olddog.co.uk Thu Apr 11 05:23:29 2013 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 79E2E21F8D29 for ; Thu, 11 Apr 2013 05:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFy05oPqXQfZ for ; Thu, 11 Apr 2013 05:23:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A821F8D11 for ; Thu, 11 Apr 2013 05:23:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BCNRWH009874; Thu, 11 Apr 2013 13:23:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BCNQu6009862 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Apr 2013 13:23:26 +0100 From: "Adrian Farrel" To: Date: Thu, 11 Apr 2013 13:23:25 +0100 Message-ID: <029801ce36af$5de1aa10$19a4fe30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: Ac42rqn+i/tL/MorT5K0X3X7E9JVlw== Cc: draft-ietf-roll-mcast-trickle@tools.ietf.org Subject: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 12:23:29 -0000 Hi, It's been brought to my attention that between -02 and -03 the form of the IPv6 option number was changed. I've had a quick chat with the chairs, and I'm jumping in because of the implications for IANA (see below). The act bits remain the same (01) indicating that the IPv6 node MUST discard the packet if it doesn't recognize the option type. But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit nodes can now change the content of the option. I have no comment on whether this is a good idea (the WG should decide about that), but I haven't been able to find a discussion of this change on the list. Perhaps it is buried in a ticket? The problem caused is that the WG went through the hoop to ask for an early code point allocation. part of that request is confirming that the content of the IANA section is stable. The allocation was made against the -02 revision, so now you have a code point in the registry that you say you do not want to use :-( Let's sort out first things first. - Authors, please explain why the change was made. - WG, please wait for the authors to explain, and then respond with your opinions. - Chairs, please let me know what the consensus is. Thanks, Adrian From johui@cisco.com Thu Apr 11 07:52:34 2013 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 3D28B21F8D10 for ; Thu, 11 Apr 2013 07:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SkU9gnq5cGV for ; Thu, 11 Apr 2013 07:52:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 67DC521F88A1 for ; Thu, 11 Apr 2013 07:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4354; q=dns/txt; s=iport; t=1365691952; x=1366901552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X50gHqNGcy8JSrYM1RM1K8cexDWfjvFhtwFCIFD7QLE=; b=MU0P2xr+aZcoQ7KyDkwDYdae7Q8KXhC2IIYNPG7aXB0RSVNtNI1HVztW Rduyzm+hWRYL830iNx212p3CFrU+Q0+FAcRE+Ayg5M0o/t0xZY0niFtzS OJBnDZiohM+g/lmzI1AYVg6dAvyCDXO0klKoUvw69eIKFb2zUlbKLwEpe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIzNZlGtJXG+/2dsb2JhbABQgwY2wUiBBBZ0ghgHAQEBAwEBAQE3NAsFCwIBCCIUECcLJQIEDgUIAYVAB4I+Bgy9b41JCxAKdQIxAgWCYGEDqBGDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,455,1363132800"; d="scan'208";a="197620545" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 11 Apr 2013 14:52:30 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3BEqUle023296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Apr 2013 14:52:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 09:52:30 -0500 From: "Jonathan Hui (johui)" To: "" , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle Thread-Index: AQHONsQwUzbqxpA81U2x4GgDyKSGyA== Date: Thu, 11 Apr 2013 14:52:29 +0000 Message-ID: References: <029801ce36af$5de1aa10$19a4fe30$@olddog.co.uk> In-Reply-To: <029801ce36af$5de1aa10$19a4fe30$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 14:52:34 -0000 The actions taken to change the HbH option chg bit predates the posting of = -03. Here is the summary of events: 1) 13 Jul 2012 We reposted -00 as -01 to change its status back to active. At the same ti= me, I sent my notes to the ROLL ML on areas that we needed to address in fu= ture revisions of the draft. Among the list of items was the following: "I'm aware of one technical bug with the HBH Option when trying to utilize = a sliding window larger than 1. In particular, a device processing the HBH= Option does not know if the Sequence value represents the largest sequence= value received by the neighboring node or an older message that it happens= to be retransmitting. Ideally, a device only resets its Trickle timer whe= n receiving indication that a neighboring device has not yet received a mes= sage yet. I propose adding a flag to the HBH Option that indicates whether= the Sequence value is the latest." http://www.ietf.org/mail-archive/web/roll/current/msg07224.html 2) 03 Aug 2012 We sent a proposed update to -01 to the ROLL ML. As mentioned in that emai= l, the intent was to provide WG members some additional visibility into how= we were addressing the announced deficiencies and to prime discussion duri= ng the ROLL WG meeting. This draft included the following change to the Hb= H Option Header: M 1-bit flag. 0 indicates that the value in sequence is not the largest sequence number that was received from the MPL seed. Unfortunately, this proposed text did not include necessary updates to the = chg bit. http://www.ietf.org/mail-archive/web/roll/current/msg07246.html 3) 19 Oct 2012 We collected comments, made further changes to the proposed text from Augus= t, and posted -02. Unfortunately again, this text did not include necessar= y updates to the chg bit. http://www.ietf.org/mail-archive/web/roll/current/msg07378.html 4) 20 Dec 2012 The IEST approved a code point allocation based on the chg bit set to zero. http://www.ietf.org/mail-archive/web/roll/current/msg07611.html 5) 14 Jan 2013 In a private email exchange, Joseph Reddy pointed out to me that -02 had an= inconsistency between the 'M' flag and the chg bit. Ralph Droms was inclu= ded on that mail and he indicated that we could get it modified "although t= he responsible AD may be a little cranky" :) In any case, for whatever rea= son, we failed to announce the issue on the ROLL ML. 6) 24 Jan 2013 We posted -03 which includes the necessary text to align the chg bit with t= he use of the 'M' flag. http://www.ietf.org/mail-archive/web/roll/current/msg07656.html And now we are where we are today. -- Jonathan Hui On Apr 11, 2013, at 5:23 AM, Adrian Farrel wrote: > Hi, >=20 > It's been brought to my attention that between -02 and -03 the form of th= e IPv6 > option number was changed. I've had a quick chat with the chairs, and I'm > jumping in because of the implications for IANA (see below). >=20 > The act bits remain the same (01) indicating that the IPv6 node MUST disc= ard the > packet if it doesn't recognize the option type. > But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit no= des can > now change the content of the option. >=20 > I have no comment on whether this is a good idea (the WG should decide ab= out > that), but I haven't been able to find a discussion of this change on the= list. > Perhaps it is buried in a ticket? >=20 > The problem caused is that the WG went through the hoop to ask for an ear= ly code > point allocation. part of that request is confirming that the content of = the > IANA section is stable. The allocation was made against the -02 revision,= so now > you have a code point in the registry that you say you do not want to use= :-( >=20 > Let's sort out first things first.=20 > - Authors, please explain why the change was made. > - WG, please wait for the authors to explain, and then > respond with your opinions. > - Chairs, please let me know what the consensus is. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Thu Apr 11 08:04:37 2013 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 93E3821F8F75 for ; Thu, 11 Apr 2013 08:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TKlxUYQZRzw for ; Thu, 11 Apr 2013 08:04:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2921F8F38 for ; Thu, 11 Apr 2013 08:04:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:38134 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQJ3A-0001Nq-MQ; Thu, 11 Apr 2013 17:04:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Thu, 11 Apr 2013 15:04:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/114 Message-ID: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> X-Trac-Ticket-ID: 114 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130411150436.E7F2921F8F38@ietfa.amsl.com> Resent-Date: Thu, 11 Apr 2013 08:04:36 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 15:04:37 -0000 #114: mcast option number changed From: "Adrian Farrel" Subject: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle It's been brought to my attention that between -02 and -03 the form of the IPv6 option number was changed. I've had a quick chat with the chairs, and I'm jumping in because of the implications for IANA (see below). The act bits remain the same (01) indicating that the IPv6 node MUST discard the packet if it doesn't recognize the option type. But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit nodes can now change the content of the option. I have no comment on whether this is a good idea (the WG should decide about that), but I haven't been able to find a discussion of this change on the list. Let's sort out first things first. - Authors, please explain why the change was made. - WG, please wait for the authors to explain, and then respond with your opinions. - Chairs, please let me know what the consensus is. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Keywords: Severity: Submitted | WG Document | -------------------------+------------------------------------------------- Ticket URL: roll From mcr@sandelman.ca Thu Apr 11 08:17:10 2013 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 22D1221F8935 for ; Thu, 11 Apr 2013 08:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiHCtBBAuX1T for ; Thu, 11 Apr 2013 08:17:09 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id F04BF21F8614 for ; Thu, 11 Apr 2013 08:17:08 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 62E8520170 for ; Thu, 11 Apr 2013 11:26:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 44AF5638FD; Thu, 11 Apr 2013 11:16:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 34EF4638E8 for ; Thu, 11 Apr 2013 11:16:48 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 15:17:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {I would prefer that we have this discussion on the thread created by the ticket, so that this can be tracked.} Jonathan Hui writes: >2) 03 Aug 2012 > >We sent a proposed update to -01 to the ROLL ML. As mentioned in that >email, the intent was to provide WG members some additional visibility >into how we were addressing the announced deficiencies and to prime >discussion during the ROLL WG meeting. This draft included the >following change to the HbH Option Header:=20 > M 1-bit flag. 0 indicates that the value in > sequence is not the largest sequence number that > was received from the MPL seed. > >Unfortunately, this proposed text did not include necessary updates to >the chg bit.=20 This is all well and good, but I don't see how this makes the hop-by-hop option mutable enroute. The option flows along a single link. My understanding is that the packet is received by mcast forwarders on that link, and a new outer packet is emitted by each forwarder, along with what is effectively a new HbH option and outer header.=20=20 The chg bit is supposed to indicate when a packet is transiting a=20 normal router and will continue mostly-unchanged, that that option is mutable by the routers along the way.=20=20=20=20 I don't see how this is the case for the HbH option in question. >5) 14 Jan 2013 > >In a private email exchange, Joseph Reddy pointed out to me that -02 >had an inconsistency between the 'M' flag and the chg bit. Ralph Droms >was included on that mail and he indicated that we could get it >modified "although the responsible AD may be a little cranky" :) In >any case, for whatever reason, we failed to announce the issue on the >ROLL ML.=20 If the issue tracker could be used more, this would be much less of an issue. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWbT4IqHRg3pndX9AQLuDQQAt1pacHM7iXXjFgr1Wj9essj8auV/lZlh V7uNpejXrTqX3DF0jj1EfLes+GrZbwZC3TGXpdnzQ085070YzWqS+ClKTx7XDMsf 42dGIQnygvMLQt8yXk7Ez+SoTd9/686Tmnv3BST+MPQ/gb6JD3Dt0sAtSBzSsdhc TKplRYSykR4= =3aUh -----END PGP SIGNATURE----- --=-=-=-- From markzzzsmith@yahoo.com.au Fri Mar 29 14:11:17 2013 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 66A0A21F8F2F for ; Fri, 29 Mar 2013 14:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyN9P4TGhH0G for ; Fri, 29 Mar 2013 14:11:17 -0700 (PDT) Received: from nm33-vm4.bullet.mail.bf1.yahoo.com (nm33-vm4.bullet.mail.bf1.yahoo.com [72.30.239.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6116621F8F28 for ; Fri, 29 Mar 2013 14:11:04 -0700 (PDT) Received: from [98.139.212.153] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 29 Mar 2013 21:11:03 -0000 Received: from [98.139.212.239] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 29 Mar 2013 21:11:03 -0000 Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 29 Mar 2013 21:11:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 364524.38405.bm@omp1048.mail.bf1.yahoo.com Received: (qmail 93298 invoked by uid 60001); 29 Mar 2013 21:11:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1364591463; bh=0lwulGEpX+lsbwx6BtXMEOoX99p7hoMkwQ8tynsBwII=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o/vPGH4qn+evZV1/xPEJ+569ahWf6uewN3yl1RfRcEZNs4l2r2XHVobLWbDgnlMJDSTx2mq1T2LHHbG7LGKi0isR2z62x6m8tD6cQhWKr4cUgxjnXBuaymBMeVM96e3y+tfJeHBj8vhaUXMcZZ94o6sahlOebtC+JaBtWiI2jAg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GfaeeQeMxQAis7kA5olSwH22Gq7+HJYaaxZ/++DZSMUTHJCj4Kx710gGv+smzgZmy/RP+ZVS4r6VUdJCZWpYdP2XQ8BRZJirN2gmgVrjCKuj81jBw3yWqixLeB3ypTUjL1b0BME9Jwbb7gw26tkFY2wmK5rf+CXu4uHxDeyMsIU=; X-YMail-OSG: wphaYtMVM1kroKIrw5mxMzvCvpTnJNCIQPXLnmt4Jcdqrp3 NXR2iWVVn.VZPn3yHhvH0rJe3a2KEKfs5C83zVdJ_BZNOh7VSEZNP_dqEwrZ bW85MkEiPKNWxvdEq3tfyJkvH_ffY1tLmN.MhZcYk2xaWY06vznaa3rpaAOK DtLCITK8Vgla0gdSU8UBOniiUhBPE6_Jm3344KQr2vPTtQk0swTmQA5yLM02 M6hutbkGHw5IKI4zMAhEZbkN8YUKJXqc4BL42D_J3cKhA8ZnnPXV976_kn2m MK4kfB5phS_alxZMoMUV1CK5ioM8GodfRTZ5oyRfwwSPAO.8c1furnglXPxk xUChkd8wR4_VNNzMN1CQVISS6JC5SCssE3zSr7drHFdUwfiAuj9.66LVI8Da dTZYwkXOSnWh.IzfbC.OEuszYTi06Pcv.yTg8mvLFdbSt1.Hi0goJ_T.zpKb BCA.JPutXWGyDe.nRHs0U73BApuPRrmVTEC.QxIHMtr39j8cEYQ2JyNmk32l HK4sSjC_.ST8LTcIzCPSuSjWZ Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Fri, 29 Mar 2013 14:11:03 PDT X-Rocket-MIMEInfo: 002.001, SGkgQ2Fyc3RlbiwKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc.Cj4gVG86ICI2bG93cGFuQGlldGYub3JnIiA8Nmxvd3BhbkBpZXRmLm9yZz4KPiBDYzogcm9sbEBpZXRmLm9yZzsgImlwdjZAaWV0Zi5vcmcgTGlzdCIgPGlwdjZAaWV0Zi5vcmc.OyAiY29yZSAoY29yZUBpZXRmLm9yZykiIDxjb3JlQGlldGYub3JnPgo.IFNlbnQ6IFNhdHVyZGF5LCAzMCBNYXJjaCAyMDEzIDEyOjIyIEFNCj4gU3ViamVjdDogR0hDIG5vdyBjcnVuY2gBMAEBAQE- X-Mailer: YahooMailWebService/0.8.139.530 References: <18113.1339529290@marajade.sandelman.ca> <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> <26808a929674c2b96850f40a9d7cd686@xs4all.nl> Message-ID: <1364591463.93179.YahooMailNeo@web142505.mail.bf1.yahoo.com> Date: Fri, 29 Mar 2013 14:11:03 -0700 (PDT) From: Mark Smith To: Carsten Bormann , "6lowpan@ietf.org" <6lowpan@ietf.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 11 Apr 2013 08:18:15 -0700 Cc: "roll@ietf.org" , "ipv6@ietf.org List" , "core \(core@ietf.org\)" Subject: Re: [Roll] GHC now crunches DTLS (Re: [6lowpan] draft-bormann-ghc) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark Smith , Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:11:17 -0000 Hi Carsten,=0A=0A=0A----- Original Message -----=0A> From: Carsten Bormann = =0A> To: "6lowpan@ietf.org" <6lowpan@ietf.org>=0A> Cc: roll@i= etf.org; "ipv6@ietf.org List" ; "core (core@ietf.org)" =0A> Sent: Saturday, 30 March 2013 12:22 AM=0A> Subject: GHC now = crunches DTLS (Re: [Roll] [6lowpan] draft-bormann-ghc)=0A> =0A> On Aug 25,= 2012, at 13:41, peter van der Stok wrote:=0A> =0A=0A=0A> I'm CCing 6man because part of the proposal is a new ND (ICMPv6) = option for =0A> node capability indication.=0A=0AJust focusing on this, I w= onder if it would be better to create a more general purpose capability opt= ion for ND, limited to layer 3 capabilities (I think stateless/stateful DHC= Pv6 would be the place for layer 4 and above capability indications), of wh= ich 6LoWPAN/GHC uses one of the bits. RFC5175, "IPv6 Router Advertisement F= lags Option" could probably be an example to model the text on, perhaps in = a different ID.=0A=0ABest regards,=0AMark.=0A=0A> Specific comments on that= probably best go to the 6man mailing list.=0A> =0A> Gr=FC=DFe, Carsten=0A>= =0A> --------------------------------------------------------------------= =0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Administrat= ive Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> --------------= ------------------------------------------------------=0A> From wwwrun@rfc-editor.org Thu Apr 4 11:51:10 2013 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 2CC9F21F8E99 for ; Thu, 4 Apr 2013 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tV0OSnnVmAj for ; Thu, 4 Apr 2013 11:51:09 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AE21F8D1C for ; Thu, 4 Apr 2013 11:51:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9390BB1E003; Thu, 4 Apr 2013 11:50:54 -0700 (PDT) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, stbryant@cisco.com, adrian@olddog.co.uk, mcr+ietf@sandelman.ca, jpv@cisco.com From: RFC Errata System Message-Id: <20130404185054.9390BB1E003@rfc-editor.org> Date: Thu, 4 Apr 2013 11:50:54 -0700 (PDT) X-Mailman-Approved-At: Thu, 11 Apr 2013 08:18:15 -0700 Cc: roll@ietf.org, rfc-editor@rfc-editor.org, tony.cheneau@amnesiak.org Subject: [Roll] [Technical Errata Reported] RFC6550 (3580) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:51:10 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=3580 -------------------------------------- Type: Technical Reported by: Tony Cheneau Section: 9.9.1 Original Text ------------- 1. Let C1 send a DAO containing a Target T with a Path Control 10000000b. Node N stores an entry associating 10000000b with the Path Control field for C1 and Target T. 2. Let C2 send a DAO containing a Target T with a Path Control 00010000b. Node N stores an entry associating 00010000b with the Path Control field for C1 and Target T. 3. Let C3 send a DAO containing a Target T with a Path Control 00001100b. Node N stores an entry associating 00001100b with the Path Control field for C1 and Target T. Corrected Text -------------- 1. Let C1 send a DAO containing a Target T with a Path Control 10000000b. Node N stores an entry associating 10000000b with the Path Control field for C1 and Target T. 2. Let C2 send a DAO containing a Target T with a Path Control 00010000b. Node N stores an entry associating 00010000b with the Path Control field for C2 and Target T. 3. Let C3 send a DAO containing a Target T with a Path Control 00001100b. Node N stores an entry associating 00001100b with the Path Control field for C3 and Target T. Notes ----- Bullet 2 and 3 seem wrong. I believe "C1" should be replaced by "C2" in bullet 2 and "C1" should be replaced by "C3" in bullet 3. This issue was initially reported by Federico Consoli on the ROLL WG mailing list. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Apr 4 12:00:12 2013 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 86BBC21F9671 for ; Thu, 4 Apr 2013 12:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfTAsiycki4l for ; Thu, 4 Apr 2013 12:00:09 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5D21F966C for ; Thu, 4 Apr 2013 12:00:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 06DF9B1E003; Thu, 4 Apr 2013 11:59:53 -0700 (PDT) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, stbryant@cisco.com, adrian@olddog.co.uk, mcr+ietf@sandelman.ca, jpv@cisco.com From: RFC Errata System Message-Id: <20130404185954.06DF9B1E003@rfc-editor.org> Date: Thu, 4 Apr 2013 11:59:54 -0700 (PDT) X-Mailman-Approved-At: Thu, 11 Apr 2013 08:18:15 -0700 Cc: roll@ietf.org, rfc-editor@rfc-editor.org, tony.cheneau@amnesiak.org Subject: [Roll] [Editorial Errata Reported] RFC6550 (3581) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 19:00:12 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=3581 -------------------------------------- Type: Editorial Reported by: Tony Cheneau Section: 6.4.3 Original Text ------------- A special case of the DAO message, termed a No-Path, is used in Storing mode to clear Downward routing state that has been provisioned through DAO operation. The No-Path carries a Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target. Corrected Text -------------- A special case of the DAO message, termed a No-Path, is used in Storing mode to clear Downward routing state that has been provisioned through DAO operation. The No-Path carries a Target option and an associated Transit Information option with a lifetime of 0x00 to indicate a loss of reachability to that Target. Notes ----- The Path Lifetime field of the Transit Information option is a 8-bit field. Using 0x00000000 here would indicate a 32 bits encoding and is misleading. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From plevis@stanford.edu Sat Apr 6 12:23:17 2013 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 8EEDD21F8B13 for ; Sat, 6 Apr 2013 12:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRYySfIO3wuU for ; Sat, 6 Apr 2013 12:23:16 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by ietfa.amsl.com (Postfix) with ESMTP id E9E3221F853D for ; Sat, 6 Apr 2013 12:23:15 -0700 (PDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BFBD664635F; Sat, 6 Apr 2013 12:23:15 -0700 (PDT) Received: from [192.168.0.102] (unknown [76.14.66.110]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: plevis) by smtp.stanford.edu (Postfix) with ESMTPSA id 3FF5B646343; Sat, 6 Apr 2013 12:23:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com> Date: Sat, 6 Apr 2013 12:23:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E801A2A-CB2B-457A-B33E-64AF839D9363@stanford.edu> References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com> To: Routing Over Low power and Lossy networks X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Thu, 11 Apr 2013 08:18:15 -0700 Cc: Michael Richardson Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2013 19:24:06 -0000 On Mar 15, 2013, at 4:34 AM, JP Vasseur (jvasseur) wrote: > Dear all, >=20 > All issues raised during the previous WG LC have been successfully = addressed in draft-ietf-roll-trickle-mcast-04. > That said, since we made several changes, this starts a 2-week WG LC = that will end on March 29 at noon ET. > Thanks. I missed the last call, but this is a comment rather than a suggested = change. I worry a bit about the default value for DATA_MESSAGE_IMAX. Setting = IMAX to the same as IMIN misses one very useful property of = exponentially increasing timers, which is that they quickly find the = right randomization interval under heavy congestion. The original = motivation for the exponential timer in Trickle was to find the right = randomization interval (much as, say, Ethernet CSMA/CD does). The = challenge with having IMAX equal IMIN is that if IMIN is too small, = you'll end up with a lot of congestion and link-layer collisions. I don't think this needs any change to the document because it's just a = default. If experience and practice shows that you don't want IMAX to be = equal to IMIN, then I'm sure people will adjust best practices and = recommendations appropriately. Just wanted to point out that keeping an = eye on this might be valuable. Phil= From abdussalambaryun@gmail.com Thu Apr 11 09:19:54 2013 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 4323A21F9254 for ; Thu, 11 Apr 2013 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mnhgW1stkEJ for ; Thu, 11 Apr 2013 09:19:53 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC7E21F9305 for ; Thu, 11 Apr 2013 09:19:52 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id q11so937738pdj.11 for ; Thu, 11 Apr 2013 09:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7crFwP4zgn3r9EMhrN3LtEP9FOj7pSzU1nzJ/6v58T4=; b=StMvK3lHOsXab2EunAbZXGfMIhe2lxYp3d929O8jIFMdZp86yrGWLn3rHS2UbewZqc Id0o3yCVs12kQs4rByk7/rUHLdaBFkS6/Nn+9T+rEjIWK6xd9ria2iwHq+y9H+eH9aEY hY4PiQuteUqidLilzoAGCHoTrBIlU4MasU/dzVq+N26gQJ7iau7Vhsh/t3Mn/+azMP2w 9DRG2fffU+kweJz6S2n073vv2JZaZJqrijhQiehlWaY+7WU/AWiZN2IllVdfRckM5Vzp BiuEisJd2bns2WZfA0UtVwx3gIh5Jp3ggBYbTtt9aMjjWJ1wjBIwcncODeexfRn4ClHY 6xDQ== MIME-Version: 1.0 X-Received: by 10.68.213.1 with SMTP id no1mr9791385pbc.163.1365697191841; Thu, 11 Apr 2013 09:19:51 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Thu, 11 Apr 2013 09:19:51 -0700 (PDT) In-Reply-To: References: <029801ce36af$5de1aa10$19a4fe30$@olddog.co.uk> Date: Thu, 11 Apr 2013 17:19:51 +0100 Message-ID: From: Abdussalam Baryun To: roll Content-Type: multipart/alternative; boundary=e89a8ff1c6bafd95ed04da1827a0 Cc: "" Subject: Re: [Roll] Unannounced change in draft-ietf-roll-mcast-trickle X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:19:54 -0000 --e89a8ff1c6bafd95ed04da1827a0 Content-Type: text/plain; charset=ISO-8859-1 Hi Jonathan and Adrian, [Reply to request] My opinion is that it is bad idea for transit nodes to change option content. However, I did not understand the explaination that there was inconsistency between M and chg, how? AB On Thu, Apr 11, 2013 at 3:52 PM, Jonathan Hui (johui) wrote: > > The actions taken to change the HbH option chg bit predates the posting of > -03. Here is the summary of events: > > 1) 13 Jul 2012 > > We reposted -00 as -01 to change its status back to active. At the same > time, I sent my notes to the ROLL ML on areas that we needed to address in > future revisions of the draft. Among the list of items was the following: > > "I'm aware of one technical bug with the HBH Option when trying to utilize > a sliding window larger than 1. In particular, a device processing the HBH > Option does not know if the Sequence value represents the largest sequence > value received by the neighboring node or an older message that it happens > to be retransmitting. Ideally, a device only resets its Trickle timer when > receiving indication that a neighboring device has not yet received a > message yet. I propose adding a flag to the HBH Option that indicates > whether the Sequence value is the latest." > > http://www.ietf.org/mail-archive/web/roll/current/msg07224.html > > 2) 03 Aug 2012 > > We sent a proposed update to -01 to the ROLL ML. As mentioned in that > email, the intent was to provide WG members some additional visibility into > how we were addressing the announced deficiencies and to prime discussion > during the ROLL WG meeting. This draft included the following change to > the HbH Option Header: > > M 1-bit flag. 0 indicates that the value in > sequence is not the largest sequence number that > was received from the MPL seed. > > Unfortunately, this proposed text did not include necessary updates to the > chg bit. > > http://www.ietf.org/mail-archive/web/roll/current/msg07246.html > > 3) 19 Oct 2012 > > We collected comments, made further changes to the proposed text from > August, and posted -02. Unfortunately again, this text did not include > necessary updates to the chg bit. > > http://www.ietf.org/mail-archive/web/roll/current/msg07378.html > > 4) 20 Dec 2012 > > The IEST approved a code point allocation based on the chg bit set to zero. > > http://www.ietf.org/mail-archive/web/roll/current/msg07611.html > > 5) 14 Jan 2013 > > In a private email exchange, Joseph Reddy pointed out to me that -02 had > an inconsistency between the 'M' flag and the chg bit. Ralph Droms was > included on that mail and he indicated that we could get it modified > "although the responsible AD may be a little cranky" :) In any case, for > whatever reason, we failed to announce the issue on the ROLL ML. > [Procedure comment] I recommend that any editing update should be discussed on list not private but still this practice I see in some WGs in IETF, but some like to reduce volume of messages. If something related to WG business not discussed in IETF then I assume that event never occured (only personal issues may occur). However, you now posted some details in IETF. I may be not familiar with the registration process but why we do it before the end of the WGLC, if before we will always get into that situation. > > 6) 24 Jan 2013 > > We posted -03 which includes the necessary text to align the chg bit with > the use of the 'M' flag. > > http://www.ietf.org/mail-archive/web/roll/current/msg07656.html > > And now we are where we are today. > > -- > Jonathan Hui > > On Apr 11, 2013, at 5:23 AM, Adrian Farrel wrote: > > > Hi, > > > > It's been brought to my attention that between -02 and -03 the form of > the IPv6 > > option number was changed. I've had a quick chat with the chairs, and I'm > > jumping in because of the implications for IANA (see below). > > > > The act bits remain the same (01) indicating that the IPv6 node MUST > discard the > > packet if it doesn't recognize the option type. > > But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit > nodes can > > now change the content of the option. > > > > I have no comment on whether this is a good idea (the WG should decide > about > > that), but I haven't been able to find a discussion of this change on > the list. > > Perhaps it is buried in a ticket? > > > > The problem caused is that the WG went through the hoop to ask for an > early code > > point allocation. part of that request is confirming that the content of > the > > IANA section is stable. The allocation was made against the -02 > revision, so now > > you have a code point in the registry that you say you do not want to > use :-( > > > > Let's sort out first things first. > > - Authors, please explain why the change was made. > > - WG, please wait for the authors to explain, and then > > respond with your opinions. > > - Chairs, please let me know what the consensus is. > > > > Thanks, > > Adrian > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --e89a8ff1c6bafd95ed04da1827a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jonathan and Adrian,
=A0
[Repl= y to request] My opinion is that it is bad idea for transit nodes to change= option content. However, I did not understand the explaination that there = was inconsistency between M and chg, how?
=A0
AB


On Thu, Apr 11, 2013 at 3:52 PM, Jonathan Hui (johui) <johui@c= isco.com> wrote:

The actions taken to change the HbH option chg bit predates the posting of = -03. =A0Here is the summary of events:

1) 13 Jul 2012

We reposted -00 as -01 to change its status back to active. =A0At the same = time, I sent my notes to the ROLL ML on areas that we needed to address in = future revisions of the draft. =A0Among the list of items was the following= :

"I'm aware of one technical bug with the HBH Option when trying to= utilize a sliding window larger than 1. =A0In particular, a device process= ing the HBH Option does not know if the Sequence value represents the large= st sequence value received by the neighboring node or an older message that= it happens to be retransmitting. =A0Ideally, a device only resets its Tric= kle timer when receiving indication that a neighboring device has not yet r= eceived a message yet. =A0I propose adding a flag to the HBH Option that in= dicates whether the Sequence value is the latest."

http://www.ietf.org/mail-archive/web/roll/current/msg072= 24.html

2) 03 Aug 2012

We sent a proposed update to -01 to the ROLL ML. =A0As mentioned in that em= ail, the intent was to provide WG members some additional visibility into h= ow we were addressing the announced deficiencies and to prime discussion du= ring the ROLL WG meeting. =A0This draft included the following change to th= e HbH Option Header:

=A0 =A0M =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1-bit flag. 0 indicates that t= he value in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sequence is not the largest = sequence number that
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0was received from the MPL se= ed.

Unfortunately, this proposed text did not include necessary updates to the = chg bit.

http://www.ietf.org/mail-archive/web/roll/current/msg072= 46.html

3) 19 Oct 2012

We collected comments, made further changes to the proposed text from Augus= t, and posted -02. =A0Unfortunately again, this text did not include necess= ary updates to the chg bit.

http://www.ietf.org/mail-archive/web/roll/current/msg073= 78.html

4) 20 Dec 2012

The IEST approved a code point allocation based on the chg bit set to zero.=

http://www.ietf.org/mail-archive/web/roll/current/msg076= 11.html

5) 14 Jan 2013

In a private email exchange, Joseph Reddy pointed out to me that -02 had an= inconsistency between the 'M' flag and the chg bit. =A0Ralph Droms= was included on that mail and he indicated that we could get it modified &= quot;although the responsible AD may be a little cranky" :) =A0In any = case, for whatever reason, we failed to announce the issue on the ROLL ML.<= br>
=A0
[Procedure comment] I recommend that any ed= iting update should be discussed on list not private but still this practic= e I see in some WGs in IETF, but some like to reduce volume of messages. If= something related to WG business not discussed in IETF then I assume that = event never occured (only personal issues may occur). However, you now post= ed some details in IETF. I may be not familiar with the registration proces= s but why we do it before the end of the WGLC, if before we will always get= into that situation.
=A0

6) 24 Jan 2013

We posted -03 which includes the necessary text to align the chg bit with t= he use of the 'M' flag.

http://www.ietf.org/mail-archive/web/roll/current/msg076= 56.html

And now we are where we are today.

--
Jonathan Hui

On Apr 11, 2013, at 5:23 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi,
>
> It's been brought to my attention that between -02 and -03 the for= m of the IPv6
> option number was changed. I've had a quick chat with the chairs, = and I'm
> jumping in because of the implications for IANA (see below).
>
> The act bits remain the same (01) indicating that the IPv6 node MUST d= iscard the
> packet if it doesn't recognize the option type.
> But the chg bit changed from 0 in -02 to 1 in -01 meaning that transit= nodes can
> now change the content of the option.
>
> I have no comment on whether this is a good idea (the WG should decide= about
> that), but I haven't been able to find a discussion of this change= on the list.
> Perhaps it is buried in a ticket?
>
> The problem caused is that the WG went through the hoop to ask for an = early code
> point allocation. part of that request is confirming that the content = of the
> IANA section is stable. The allocation was made against the -02 revisi= on, so now
> you have a code point in the registry that you say you do not want to = use :-(
>
> Let's sort out first things first.
> - Authors, please explain why the change was made.
> - WG, please wait for the authors to explain, and then
> =A0respond with your opinions.
> - Chairs, please let me know what the consensus is.
>
> Thanks,
> Adrian
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--e89a8ff1c6bafd95ed04da1827a0-- From abdussalambaryun@gmail.com Thu Apr 11 09:29:04 2013 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 0562821F85B3 for ; Thu, 11 Apr 2013 09:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cUTAyy8voUW for ; Thu, 11 Apr 2013 09:29:02 -0700 (PDT) Received: from mail-da0-x22a.google.com (mail-da0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1958621F8581 for ; Thu, 11 Apr 2013 09:29:01 -0700 (PDT) Received: by mail-da0-f42.google.com with SMTP id n15so753043dad.1 for ; Thu, 11 Apr 2013 09:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=GcEn533ralNAIzatwy76TvdeyfUyTAo5xKL65r4xPUQ=; b=gjESsy7909sGLlWCeO+WZBFuBCpk0ldiJj0h8e8R0TkKGOQ30S7G8ZYhho7zNgASN8 0zdGI9PAu4YIYUsihTDuzVWpsl0dY6L3mN+SAq+Cto7Ws6KgO4tyy5fkZhXfHFwwwc9v pBJMBxItgs0NuXV0HiXhar2AZl6lpT8npLPGbMBq3U0ybldZckJceWXMyS85PKIS7oOY j3fL5sW3sr2NbMv7mclrT2B3qdw44Sa9FTll28MEtr08b0eeavcPv0+2S5+0XBD1EXny Zp/iafcFtOekSc6Dv/x8VPhH5ZnvzYf0sg1qeTWPZEjB4MlHCfUlnsCICFRxrKk8woHz g+wA== MIME-Version: 1.0 X-Received: by 10.68.28.201 with SMTP id d9mr9882250pbh.113.1365697726202; Thu, 11 Apr 2013 09:28:46 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Thu, 11 Apr 2013 09:28:46 -0700 (PDT) In-Reply-To: <12776.1365693408@sandelman.ca> References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> Date: Thu, 11 Apr 2013 17:28:46 +0100 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=bcaec520eafdd7471e04da1847b3 Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:29:04 -0000 --bcaec520eafdd7471e04da1847b3 Content-Type: text/plain; charset=ISO-8859-1 >In a private email exchange, Joseph Reddy pointed out to me that -02 > had an inconsistency between the 'M' flag and the chg bit. Ralph Droms > was included on that mail and he indicated that we could get it > modified "although the responsible AD may be a little cranky" :) In > any case, for whatever reason, we failed to announce the issue on the > ROLL ML. IMHO, no eidtor should make any change to WG draft until discussed in IETF, I know it is not a best practice but discussion list is the place to work, not privately AB On Thu, Apr 11, 2013 at 4:16 PM, Michael Richardson wrote: > > {I would prefer that we have this discussion on the thread created by > the ticket, so that this can be tracked.} > > Jonathan Hui writes: > >2) 03 Aug 2012 > > > >We sent a proposed update to -01 to the ROLL ML. As mentioned in that > >email, the intent was to provide WG members some additional visibility > >into how we were addressing the announced deficiencies and to prime > >discussion during the ROLL WG meeting. This draft included the > >following change to the HbH Option Header: > > > M 1-bit flag. 0 indicates that the value in > > sequence is not the largest sequence number that > > was received from the MPL seed. > > > >Unfortunately, this proposed text did not include necessary updates to > >the chg bit. > > This is all well and good, but I don't see how this makes the hop-by-hop > option mutable enroute. > > The option flows along a single link. My understanding is that the > packet is received by mcast forwarders on that link, and a new outer > packet is emitted by each forwarder, along with what is effectively a > new HbH option and outer header. > > The chg bit is supposed to indicate when a packet is transiting a > normal router and will continue mostly-unchanged, that that option is > mutable by the routers along the way. > I don't see how this is the case for the HbH option in question. > > >5) 14 Jan 2013 > > > >In a private email exchange, Joseph Reddy pointed out to me that -02 > >had an inconsistency between the 'M' flag and the chg bit. Ralph Droms > >was included on that mail and he indicated that we could get it > >modified "although the responsible AD may be a little cranky" :) In > >any case, for whatever reason, we failed to announce the issue on the > >ROLL ML. > > If the issue tracker could be used more, this would be much less of an > issue. > > > > > > > > > > -- > Michael Richardson , Sandelman Software Works > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --bcaec520eafdd7471e04da1847b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>In a private email exchange, Joseph Reddy pointed= out to me that -02
> had an inconsistency between the 'M' fl= ag and the chg bit. Ralph Droms
> was included on that mail and he i= ndicated that we could get it
> modified "although the responsible AD may be a little cranky"= ; :) In
> any case, for whatever reason, we failed to announce the i= ssue on the
> ROLL ML.
IMHO, no eidtor should make any = change to WG draft until discussed in IETF, I know it is not a best practic= e but discussion list is the place to work, not privately
=A0
AB


On Thu, Apr 11, 2013 at 4:16 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

{I would prefer that we have this discussion on the thread created by
the ticket, so that this can be tracked.}

Jonathan Hui writes:
>2) 03 Aug 2012
>
>We sent a proposed update to -01 to the ROLL ML. =A0As mentioned in tha= t
>email, the intent was to provide WG members some additional visibility<= br> >into how we were addressing the announced deficiencies and to prime
>discussion during the ROLL WG meeting. =A0This draft included the
>following change to the HbH Option Header:

> =A0 M =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1-bit flag. 0 indicates that= the value in
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sequence is not the larges= t sequence number that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 was received from the MPL = seed.
>
>Unfortunately, this proposed text did not include necessary updates to<= br> >the chg bit.

This is all well and good, but I don't see how this makes the hop-by-ho= p
option mutable enroute.

The option flows along a single link. =A0My understanding is that the
packet is received by mcast forwarders on that link, and a new outer
packet is emitted by each forwarder, along with what is effectively a
new HbH option and outer header.

The chg bit is supposed to indicate when a packet is transiting a
normal router and will continue mostly-unchanged, that that option is
mutable by the routers along the way.
I don't see how this is the case for the HbH option in question.

>5) 14 Jan 2013
>
>In a private email exchange, Joseph Reddy pointed out to me that -02 >had an inconsistency between the 'M' flag and the chg bit. =A0R= alph Droms
>was included on that mail and he indicated that we could get it
>modified "although the responsible AD may be a little cranky"= :) =A0In
>any case, for whatever reason, we failed to announce the issue on the >ROLL ML.

If the issue tracker could be used more, this would be much less of an
issue.









--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works



_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--bcaec520eafdd7471e04da1847b3-- From adrian@olddog.co.uk Thu Apr 11 10:38:11 2013 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 C9E7821F9199 for ; Thu, 11 Apr 2013 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSBdG5uqVEiq for ; Thu, 11 Apr 2013 10:38:11 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id EB2D221F913E for ; Thu, 11 Apr 2013 10:38:10 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BHc9WU023485 for ; Thu, 11 Apr 2013 18:38:09 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3BHc8Qx023474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 11 Apr 2013 18:38:09 +0100 From: "Adrian Farrel" To: Date: Thu, 11 Apr 2013 18:38:07 +0100 Message-ID: <038e01ce36db$548393d0$fd8abb70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: Ac422yQ6kss92z//TDyVDreJRWQn+Q== Subject: [Roll] Code point allocations for draft-ietf-roll-mcast-trickle X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 17:38:11 -0000 Thanks, Jonathan, for the explanation of history. Thanks, Michael, for raising a ticket to track this. The IESG just discussed the topic because a request was made to IANA to change the (early) allocated value to match the draft. The IESG determined to defer the decision until it meets on April 25th. It would be really helpful if, by that time, the WG can decide: - What it wants the code point to be - Whether the early allocation needs to be updated with urgency or can wait until the document reaches the IESG (very soon as you have last called it). - How the WG wants to handle the (early) allocated code point (release it or deprecate it?) Part of this discussion is that the code points are encouraged to have different rest values, regardless of the settings of the other 3 bits, but they are actually considered different code points even if they have the same rest value. Thanks for your help with this, Adrian From johui@cisco.com Thu Apr 11 11:26:04 2013 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 9CE6121F8EFC for ; Thu, 11 Apr 2013 11:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.299 X-Spam-Level: X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJu2zZOhEkqM for ; Thu, 11 Apr 2013 11:25:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAF821F8EF1 for ; Thu, 11 Apr 2013 11:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1746; q=dns/txt; s=iport; t=1365704757; x=1366914357; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2uNTilooufFCG6Z2vT8+gfRJOBRKPycSybvPfCj7hhU=; b=FrXsqfPxwFeJK7W9qiQ4bToSflwL7H2WvdkvbCJARs1T4iyIBmeag3Tk M7idhb17CZux0ujZH1P8Vmm837FvN6oe99MPXjV1dOpxJZqQCiXX29uHH dFMr69xeurleHXbxDumU0TD8ChyGp7i9zOQ4DF0KH67SSBQ/lEy1L1rmT k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHT/ZlGtJXHB/2dsb2JhbABQgwbBfoEHFnSCHwEBAQMBOkQLAgEIIhQQMiUCBBMIiAYGvWuNSQuBDwI4gmBhA6gRgwuBczU X-IronPort-AV: E=Sophos;i="4.87,456,1363132800"; d="scan'208";a="197556229" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 11 Apr 2013 18:25:56 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3BIPuMH007301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Apr 2013 18:25:56 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 13:25:56 -0500 From: "Jonathan Hui (johui)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #114: mcast option number changed Thread-Index: AQHONuIB9PkEQcWLvUKfeFC5Zqa/8Q== Date: Thu, 11 Apr 2013 18:25:55 +0000 Message-ID: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> In-Reply-To: <12776.1365693408@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <3079ADF4E7C83D468B2AC66806F6EC1E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 18:26:04 -0000 On Apr 11, 2013, at 8:16 AM, Michael Richardson wro= te: > Jonathan Hui writes: >> 2) 03 Aug 2012 >>=20 >> We sent a proposed update to -01 to the ROLL ML. As mentioned in that >> email, the intent was to provide WG members some additional visibility >> into how we were addressing the announced deficiencies and to prime >> discussion during the ROLL WG meeting. This draft included the >> following change to the HbH Option Header:=20 >=20 >> M 1-bit flag. 0 indicates that the value in >> sequence is not the largest sequence number that >> was received from the MPL seed. >>=20 >> Unfortunately, this proposed text did not include necessary updates to >> the chg bit.=20 >=20 > This is all well and good, but I don't see how this makes the hop-by-hop > option mutable enroute. >=20 > The option flows along a single link. My understanding is that the > packet is received by mcast forwarders on that link, and a new outer > packet is emitted by each forwarder, along with what is effectively a > new HbH option and outer header. =20 >=20 > The chg bit is supposed to indicate when a packet is transiting a=20 > normal router and will continue mostly-unchanged, that that option is > mutable by the routers along the way. =20 > I don't see how this is the case for the HbH option in question. MPL Data Messages are generated by MPL Seeds. The IPv6 Destination Address= of the outer header is set to the MPL Domain Address, which serves to scop= e the dissemination to an MPL Domain. MPL Forwarders do not generate a new= outer IPv6 Header and HbH Option when forwarding MPL Data Messages. -- Jonathan Hui From abdussalambaryun@gmail.com Thu Apr 11 12:20:22 2013 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 B075C21F87D1 for ; Thu, 11 Apr 2013 12:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jgfzK3IWEJw for ; Thu, 11 Apr 2013 12:20:22 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0005F21F8F75 for ; Thu, 11 Apr 2013 12:20:21 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id lj1so1053414pab.35 for ; Thu, 11 Apr 2013 12:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=0oiBZBdgtHoyPQs+TiuI8PsVBg98PlBDHMfxbefhbPE=; b=IYufr7jxUlnt7aZ7sz4FzZw0kQgGCjdtxbkzsioJdb7TYSBueeXFKJXtx4k7D2Gryr jrSqW0Ywl7ZUW9AJm3TBnVK/g5E+bUbAEQoPEM/qCKPXeqC5il/7Expuvnv1ZKixnxr+ rbRamT6hKZY4usVOPPZtmkMYqZo8QR8y6oUWil/fHgemElfbJSr2lBYMvdc6h5fOqzQ2 +jkBUE3Wrg4y3rcqxD1YlEjb+CCpB65hXqH4A2iG17BlFAyzXz2aWr2zT4eG7eQZNj/v KyjMIjCp94T6ixCH6aAL57praRraoVW92EyJCTvGgRjExIAxWPF8oVMVlnQBSa5+Svuy s0jQ== MIME-Version: 1.0 X-Received: by 10.68.101.226 with SMTP id fj2mr3901524pbb.6.1365708021744; Thu, 11 Apr 2013 12:20:21 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Thu, 11 Apr 2013 12:20:21 -0700 (PDT) In-Reply-To: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> Date: Thu, 11 Apr 2013 20:20:21 +0100 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b6d94f480cb2404da1aadf8 Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:20:22 -0000 --047d7b6d94f480cb2404da1aadf8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 7:25 PM, Jonathan Hui (johui) wrote: > > The chg bit is supposed to indicate when a packet is transiting a > > normal router and will continue mostly-unchanged, that that option is > > mutable by the routers along the way. > > I don't see how this is the case for the HbH option in question. > > MPL Data Messages are generated by MPL Seeds. The IPv6 Destination > Address of the outer header is set to the MPL Domain Address, which serves > to scope the dissemination to an MPL Domain. MPL Forwarders do not > generate a new outer IPv6 Header and HbH Option when forwarding MPL Data > Messages. > I understand that you agree that no need that forwarders change the option content. Or you may mean if forwarder changes it, then it MUST be forwarding-to different domains or destinations' group. Is that right, please advise, AB > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --047d7b6d94f480cb2404da1aadf8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Apr 11, 2013 at 7:25 PM, Jonathan Hui (johui) <johui@cisco.com> wrote:
> The chg bit is supposed to indicate= when a packet is transiting a
> normal router and will continue mostly-unchanged, that that option is<= br> > mutable by the routers along the way.
> I don't see how this is the case for the HbH option in question.
MPL Data Messages are generated by MPL Seeds. =A0The IPv6 Destination= Address of the outer header is set to the MPL Domain Address, which serves= to scope the dissemination to an MPL Domain. =A0MPL Forwarders do not gene= rate a new outer IPv6 Header and HbH Option when forwarding MPL Data Messag= es.
=A0
I understand that you agree that no need th= at forwarders change the option content. Or you may mean=A0if forwarder=A0c= hanges it, then=A0it=A0MUST be forwarding-to different domains or destinati= ons' group. Is that right, please advise,
=A0
AB=A0

--
Jonathan Hui

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--047d7b6d94f480cb2404da1aadf8-- From abdussalambaryun@gmail.com Thu Apr 11 12:27:34 2013 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 CFE6B21F8546 for ; Thu, 11 Apr 2013 12:27:34 -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.086, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lrbt1hkoseQG for ; Thu, 11 Apr 2013 12:27:34 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEE921F85CE for ; Thu, 11 Apr 2013 12:27:34 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id x11so1013091pdj.10 for ; Thu, 11 Apr 2013 12:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=VQM2UAmYzBn28VIOYWYPHx9Fo8IuUxxy8jUWsRJxN8g=; b=ZBb5q5FZNjcM8rmOrW0kUAblaz8/F696LT72AIeIGD5H+7bTymoGjACm6qiqeT1roP CisBudMyXh+ZgqI+Fwbxm5hpyXrTREtnuRUss7RmnVm5zQWR20dFVR5u7bctvKmSiuKg VcvxOlfznAl/QsVcpDYmDEA49yyNj0St/K5bPbVkIkALGUMaIgwWrheycaHb7jvb9g+9 otZxCr8JJqviHAicBIH8IqxI141Qe6+HhZO75GZg0dAP4sCJTn1E1QIguIFAXslW2AtE Ka1DJKDp0LAClomE74IYsCfxgBQUcJ2lElPGswPM+YSa6Cnkk+DmU63bryoX0/VVtdSb 2ANQ== MIME-Version: 1.0 X-Received: by 10.68.101.226 with SMTP id fj2mr3928382pbb.6.1365708453779; Thu, 11 Apr 2013 12:27:33 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Thu, 11 Apr 2013 12:27:33 -0700 (PDT) In-Reply-To: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> Date: Thu, 11 Apr 2013 20:27:33 +0100 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7b6d94f4411f7904da1ac79c Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 19:27:35 -0000 --047d7b6d94f4411f7904da1ac79c Content-Type: text/plain; charset=ISO-8859-1 I understand that each domain is forwarded to but the forwarders are same decisions, not different. If you have change to option-content then you have complixity I think, Please note that that is my opinion, not tested, AB On Thu, Apr 11, 2013 at 8:20 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > On Thu, Apr 11, 2013 at 7:25 PM, Jonathan Hui (johui) wrote: > >> > The chg bit is supposed to indicate when a packet is transiting a >> > normal router and will continue mostly-unchanged, that that option is >> > mutable by the routers along the way. >> > I don't see how this is the case for the HbH option in question. >> >> MPL Data Messages are generated by MPL Seeds. The IPv6 Destination >> Address of the outer header is set to the MPL Domain Address, which serves >> to scope the dissemination to an MPL Domain. MPL Forwarders do not >> generate a new outer IPv6 Header and HbH Option when forwarding MPL Data >> Messages. >> > > I understand that you agree that no need that forwarders change the option > content. Or you may mean if forwarder changes it, then it MUST be > forwarding-to different domains or destinations' group. Is that right, > please advise, > > AB > >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > --047d7b6d94f4411f7904da1ac79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I understand that each domain is forwarded to but the= forwarders are same decisions, not different. If you have change to option= -content then you have complixity I think,
=A0
Please n= ote that that is my opinion, not tested,
=A0
AB


On Thu, Apr 11, 2013 at 8:20 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
=
On Thu, Apr 11, 2013 at 7:25 P= M, Jonathan Hui (johui) <johui@cisco.com> wrote:
> The chg bit is supposed to indicate when a packe= t is transiting a
> normal router and will continue mostly-unchanged, that that option is<= br> > mutable by the routers along the way.
> I don't see how this is the case for the HbH option in question.
MPL Data Messages are generated by MPL Seeds. =A0The IPv6 Destination= Address of the outer header is set to the MPL Domain Address, which serves= to scope the dissemination to an MPL Domain. =A0MPL Forwarders do not gene= rate a new outer IPv6 Header and HbH Option when forwarding MPL Data Messag= es.
=A0
I understand that you agree that no n= eed that forwarders change the option content. Or you may mean=A0if forward= er=A0changes it, then=A0it=A0MUST be forwarding-to different domains or des= tinations' group. Is that right, please advise,
=A0
AB=A0

--
Jonathan Hui

_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--047d7b6d94f4411f7904da1ac79c-- From mcr@sandelman.ca Thu Apr 11 13:07:27 2013 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 62A6221F8A8A for ; Thu, 11 Apr 2013 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWq73e+DyGNT for ; Thu, 11 Apr 2013 13:07:26 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 455D721F8A74 for ; Thu, 11 Apr 2013 13:07:26 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B8D762016F for ; Thu, 11 Apr 2013 16:17:00 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 86AF9A9946; Thu, 11 Apr 2013 16:06:55 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6EFDF638E8 for ; Thu, 11 Apr 2013 16:06:55 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 20:07:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "johui" =3D=3D johui writes: >> The chg bit is supposed to indicate when a packet is transiting a=20 >> normal router and will continue mostly-unchanged, that that option is >> mutable by the routers along the way.=20=20=20=20 >> I don't see how this is the case for the HbH option in question. johui> MPL Data Messages are generated by MPL Seeds. The IPv6 johui> Destination Address of the outer header is set to the MPL johui> Domain Address, which serves to scope the dissemination to an johui> MPL Domain. MPL Forwarders do not generate a new outer IPv6 johui> Header and HbH Option when forwarding MPL Data Messages.=20 okay. This seems at odds with the slides that were produced last November. http://tools.ietf.org/agenda/85/slides/slides-85-roll-5.pdf Slide 3. Did I misunderstand our conclusion as to how things work? Two mechanisms are describe in slide 3: MPL domain multicast, and Link Local Multicast. Do we still have two mechanisms, or one? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWcX34qHRg3pndX9AQLcNQQAkrEEzWoWAE1CX9Lt+u0SojRmNCBdTY+D W0uCKBt9OJsAth3ud3ffL1I8qG4JtTmtzSQd2dg0dGl3VOXwx+4XQ1wpYkDjksGi /VVbhh3g9WPqKQAisdIRWXKskeCFceInpaan4VyO6mxScMp5WJhCYYlWJ9GIFM2B eBxw1Oyau04= =ttpJ -----END PGP SIGNATURE----- --=-=-=-- From johui@cisco.com Thu Apr 11 14:28:33 2013 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 7B8FF21F904B for ; Thu, 11 Apr 2013 14:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh3SdS2eoiSf for ; Thu, 11 Apr 2013 14:28:32 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C054521F8F24 for ; Thu, 11 Apr 2013 14:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1319; q=dns/txt; s=iport; t=1365715712; x=1366925312; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0rhaOKEzMOk4PoH4VL0WJoIszZijIVwb97IfZ6SNlVU=; b=GD8qg9xRgH9eVOxiXLprXRhf70t2vk5PkeoXSYAlCPvZHONuWSJjQ0jU IU0ueHNwK0upp20DJGkjn07Fu7FMAjQky+N2at4jv6fZiAvkVEeKrdf13 WGfrEm8eGP3bKGUk+YfpzJ6GTTFeXAUFxBut5OaHTGuBGqc+aYV2gfZ5p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKgpZ1GtJV2Z/2dsb2JhbABQgwY2wUmBBxZ0giABAQICOk8CAQgiFBAyJQIEEwgBiAsMvUyNZH8CMwWCYGEDmCOPboMLgXM1 X-IronPort-AV: E=Sophos;i="4.87,458,1363132800"; d="scan'208";a="197824118" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 11 Apr 2013 21:28:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3BLSWCE026787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Apr 2013 21:28:32 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 16:28:32 -0500 From: "Jonathan Hui (johui)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #114: mcast option number changed Thread-Index: AQHONuIB9PkEQcWLvUKfeFC5Zqa/8Q== Date: Thu, 11 Apr 2013 21:28:31 +0000 Message-ID: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> <31854.1365710815@sandelman.ca> In-Reply-To: <31854.1365710815@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:28:33 -0000 On Apr 11, 2013, at 1:06 PM, Michael Richardson wro= te: >>>>>> "johui" =3D=3D johui writes: >>> The chg bit is supposed to indicate when a packet is transiting a=20 >>> normal router and will continue mostly-unchanged, that that option is >>> mutable by the routers along the way. =20 >>> I don't see how this is the case for the HbH option in question. >=20 > johui> MPL Data Messages are generated by MPL Seeds. The IPv6 > johui> Destination Address of the outer header is set to the MPL > johui> Domain Address, which serves to scope the dissemination to an > johui> MPL Domain. MPL Forwarders do not generate a new outer IPv6 > johui> Header and HbH Option when forwarding MPL Data Messages.=20 >=20 > okay. >=20 > This seems at odds with the slides that were produced last November. >=20 > http://tools.ietf.org/agenda/85/slides/slides-85-roll-5.pdf >=20 > Slide 3. Did I misunderstand our conclusion as to how things work? > Two mechanisms are describe in slide 3: MPL domain multicast, > and Link Local Multicast. Do we still have two mechanisms, or one? We only have the MPL Domain mechanism (termed subnet-local in a prior mail)= . http://www.ietf.org/mail-archive/web/roll/current/msg07624.html -- Jonathan Hui From johui@cisco.com Thu Apr 11 14:34:56 2013 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 28A9021F8691 for ; Thu, 11 Apr 2013 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.832 X-Spam-Level: X-Spam-Status: No, score=-9.832 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6idvAwUD8nX for ; Thu, 11 Apr 2013 14:34:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3C221F8555 for ; Thu, 11 Apr 2013 14:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6967; q=dns/txt; s=iport; t=1365716095; x=1366925695; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=E3tgN9WEFyh2RutqUtsFGpD5SO86+nX1Mi7TOnQHaCQ=; b=jM2YeqOK2ZcLa/+IF8UjQffuevxvvGWEZynXMXlz004CKhEFP/1/HfsK 2L2RebF2nZZi2Bo0NVBrdZPsRqmLXADecyzj2YL12CDSqXxQKj0Ht3LNT 6V1+7c9w2RCvlqI/wPUpadfbui37IYyVjjfb66TKGoYBDmPkIhGAauxwv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOorZ1GtJV2b/2dsb2JhbABQgwY2wUmBBxZ0gh8BAQEDAQEBAWsQCwIBCBgKHQchBgsUEQIEEwiHegMJBgyzXQ2JWQSMQ4IiLQuCYGEDiEuMVI1WhRyDC4Io X-IronPort-AV: E=Sophos;i="4.87,458,1363132800"; d="scan'208,217";a="197623759" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 11 Apr 2013 21:34:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3BLYspR015341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Apr 2013 21:34:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.31]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 16:34:54 -0500 From: "Jonathan Hui (johui)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] [roll] #114: mcast option number changed Thread-Index: AQHONuIB9PkEQcWLvUKfeFC5Zqa/8Q== Date: Thu, 11 Apr 2013 21:34:53 +0000 Message-ID: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.55] Content-Type: multipart/alternative; boundary="_000_B50D0F163D52B74DA572DD345D5044AF1884787Dxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:34:56 -0000 --_000_B50D0F163D52B74DA572DD345D5044AF1884787Dxmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Trickle relies on having a node determine whether or not there is new infor= mation. MPL uses a sequence number to make that determination. 1) A node determines that a neighbor has newer information if that neighbor= announces a larger sequence number. 2) A node determines that it has newer information than its neighbor if tha= t neighbor announces a smaller sequence number with the 'M' flag set. With= out the 'M' flag, a neighbor retransmitting an 'older' packet can falsely c= ause a node to determine that it needs newer information. -- Jonathan Hui On Apr 11, 2013, at 12:27 PM, Abdussalam Baryun > wrote: I understand that each domain is forwarded to but the forwarders are same d= ecisions, not different. If you have change to option-content then you have= complixity I think, Please note that that is my opinion, not tested, AB On Thu, Apr 11, 2013 at 8:20 PM, Abdussalam Baryun > wrote: On Thu, Apr 11, 2013 at 7:25 PM, Jonathan Hui (johui) > wrote: > The chg bit is supposed to indicate when a packet is transiting a > normal router and will continue mostly-unchanged, that that option is > mutable by the routers along the way. > I don't see how this is the case for the HbH option in question. MPL Data Messages are generated by MPL Seeds. The IPv6 Destination Address= of the outer header is set to the MPL Domain Address, which serves to scop= e the dissemination to an MPL Domain. MPL Forwarders do not generate a new= outer IPv6 Header and HbH Option when forwarding MPL Data Messages. I understand that you agree that no need that forwarders change the option = content. Or you may mean if forwarder changes it, then it MUST be forwardin= g-to different domains or destinations' group. Is that right, please advise= , AB -- Jonathan Hui _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_B50D0F163D52B74DA572DD345D5044AF1884787Dxmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Trickle relies on having a node determine whether or not there is new = information.  MPL uses a sequence number to make that determination.

1) A node determines that a neighbor has newer information if that nei= ghbor announces a larger sequence number.

2) A node determines that it has newer information than its neighbor i= f that neighbor announces a smaller sequence number with the 'M' flag set. =  Without the 'M' flag, a neighbor retransmitting an 'older' packet can= falsely cause a node to determine that it needs newer information.

--
Jonathan Hui

On Apr 11, 2013, at 12:27 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I understand that each domain is forwarded to but the forwarders are s= ame decisions, not different. If you have change to option-content then you= have complixity I think,
 
Please note that that is my opinion, not tested,
 
AB


On Thu, Apr 11, 2013 at 8:20 PM, Abdussalam Bary= un <abdussa= lambaryun@gmail.com> wrote:
On Thu, Apr 11, 2013 at 7:25 PM, Jonathan Hui (johui) <johui@cisco.com> wrote:
> The chg bit is supposed to indicate when a packet is transiting a=
> normal router and will continue mostly-unchanged, that that option is<= br> > mutable by the routers along the way.
> I don't see how this is the case for the HbH option in question.

MPL Data Messages are generated by MPL Seeds.  The IPv6 Destination Ad= dress of the outer header is set to the MPL Domain Address, which serves to= scope the dissemination to an MPL Domain.  MPL Forwarders do not gene= rate a new outer IPv6 Header and HbH Option when forwarding MPL Data Messages.
 
I understand that you agree that no need that forwarders change the op= tion content. Or you may mean if forwarder changes it, then = it MUST be forwarding-to different domains or destinations' group. Is = that right, please advise,
 
AB 

--
Jonathan Hui


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

--_000_B50D0F163D52B74DA572DD345D5044AF1884787Dxmbrcdx04ciscoc_-- From mcr@sandelman.ca Thu Apr 11 15:49:36 2013 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 3FC1021F8842 for ; Thu, 11 Apr 2013 15:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwFqqfp0DvwS for ; Thu, 11 Apr 2013 15:49:35 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6821F87E9 for ; Thu, 11 Apr 2013 15:49:35 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4696720170 for ; Thu, 11 Apr 2013 18:59:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B29DBA9946; Thu, 11 Apr 2013 18:49:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9B2BEB9396 for ; Thu, 11 Apr 2013 18:49:14 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <058.01a618d1a7b5cd8b99d1962f7773d556@trac.tools.ietf.org> <12776.1365693408@sandelman.ca> <31854.1365710815@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #114: mcast option number changed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:49:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "johui" =3D=3D johui writes: >> okay. >>=20 >> This seems at odds with the slides that were produced last November. >>=20 >> http://tools.ietf.org/agenda/85/slides/slides-85-roll-5.pdf >>=20 >> Slide 3. Did I misunderstand our conclusion as to how things work? >> Two mechanisms are describe in slide 3: MPL domain multicast, >> and Link Local Multicast. Do we still have two mechanisms, or one? johui> We only have the MPL Domain mechanism (termed subnet-local in johui> a prior mail).=20 johui> http://www.ietf.org/mail-archive/web/roll/current/msg07624.html okay, this explains things: we decided in January that this was the case. I don't think that the ticket got closed properly with that conclusion. January was after we asked for the early adoption. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWc96oqHRg3pndX9AQI1NQP/RGqjy4xzu1XgLlYT9r5vPPNgsgnsjgYx zk9CzSVYBw7A5qWzM4xYKW4jyPhkyu9Jj0mxKLHrjrKAFkAIL0ZUdwOub7ACQAE+ yYiQxMbOFcJXJkRcMGB1VGStt49w8ul9l0efG8rcAzCFaNGwIqQwtUoqLyGxGWSE ScR4HZVlI+0= =4vxQ -----END PGP SIGNATURE----- --=-=-=-- From trac+roll@trac.tools.ietf.org Thu Apr 11 15:53:38 2013 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 5C53721F86FA for ; Thu, 11 Apr 2013 15:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRt44-Cl3aCq for ; Thu, 11 Apr 2013 15:53:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1C921F8935 for ; Thu, 11 Apr 2013 15:53:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:60919 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UQQMx-0000xA-P6; Fri, 12 Apr 2013 00:53:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 11 Apr 2013 22:53:27 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/105#comment:4 Message-ID: <073.9fa4ad7752759369f05cc265fc73ae7c@trac.tools.ietf.org> References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130411225336.9D1C921F8935@ietfa.amsl.com> Resent-Date: Thu, 11 Apr 2013 15:53:36 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 22:53:38 -0000 #105: trickle-mcast: how to determine scope of MPL domain Changes (by mcr@sandelman.ca): * status: new => closed * resolution: => fixed Comment: Jonathan: "There isn't really a need for both #3 (subnet-local mc address) and #4 (link-local mc address) as they are both mechanisms for encapsulating a mc message originating from or destined for outside the MPL Domain. I think the original aim was to keep the specification flexible for implementation choice. The latest draft will only specify #3. " -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From abdussalambaryun@gmail.com Thu Apr 11 23:56:22 2013 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 50E2C21F8AE7 for ; Thu, 11 Apr 2013 23:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxuqW6YZVqDH for ; Thu, 11 Apr 2013 23:56:19 -0700 (PDT) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 52ACB21F87B6 for ; Thu, 11 Apr 2013 23:56:19 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id kq13so1309229pab.15 for ; Thu, 11 Apr 2013 23:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=AxDteFZsL/BspFuRT8zjkaiC4TGOaa0PkT8mi8VGSCg=; b=n8CjZj2Wnl3CZezKQZ4t3hpFdFKoC+kkvKuUScDHVogiKAPTCE9u6ZrMzat2wZFpmK m2wW5N5719QRxG6pjdA5iU6nsjDT3+HQKkIE8zX6/KUD2eFKuYNpXAr4r5jlswwbgRfS thp3i85i2Itjw3ofserXbi7AiaQNp7J2M6PzyY8n+vOSv/OIoqnMWrJbfZGpUv2WoouA i5gFN1Z4ZkDnDWey4N75zso9x68JRhR3j44jC/ivAwbk9wQo0OLsSVmwjxbcz1DbOnSf 00oSy3T0D4ae5UM3rwnTWmIrAq0e2Q+sPsyuHf34rBAFDCI1YVsQwbCHjbKIaz+SV/wr nZqg== MIME-Version: 1.0 X-Received: by 10.68.48.201 with SMTP id o9mr12767972pbn.215.1365749779102; Thu, 11 Apr 2013 23:56:19 -0700 (PDT) Received: by 10.69.8.2 with HTTP; Thu, 11 Apr 2013 23:56:18 -0700 (PDT) In-Reply-To: <9FD3690D-148B-4EF6-AE57-731CA249D9EE@gmail.com> References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com> <03B78081B371D44390ED6E7BADBB4A772333BC0D@xmb-rcd-x02.cisco.com> <9FD3690D-148B-4EF6-AE57-731CA249D9EE@gmail.com> Date: Fri, 12 Apr 2013 08:56:18 +0200 Message-ID: From: Abdussalam Baryun To: Routing Over Low power and Lossy networks Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 06:56:22 -0000 I agree with the below message proposal, and to add that I think this I-D should define the trickle parameters not leaving them for open test. I think IMAX should not equal IMIN [1] for this protocol, but mostly tests will proof best. IMO, the use of trickle parameter to make change in MPL forwarding is better than enabling transit node to change option content [2], Could transit nodes change trickle parameter value when that chg bit is 1, but not change option content? [I-D>Abstract] Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. [AB] The I-D does not show parameter values/relations/equations, how can I test their consistency with the protocol? [1] http://www.ietf.org/mail-archive/web/roll/current/msg07887.html [2] http://www.ietf.org/mail-archive/web/roll/current/msg07880.html Just thoughts, if not reasonable please ignore. Regards AB If you think didn't understand the protocol - I already know that, you don't need to remind me :-) On 4/1/13, Ralph Droms wrote: > I apologize for the late feedback... > > Section 8 seems somewhat out of place, as well as redundant with the > definition of "MPL Domain" in section 2 and the contents of section 5.1. > > Multicast scope 0x03 has never been formally defined as "subnet-local". > Delete the references to "subnet-local" in sections 5.1 and 8, leaving just > "scope value of 3". Note that scope value 3 is currently defined as > "reserved" in RFC 4291. I am working on publication of an RFC that will > re-define scope value 3 as "(unassigned)" so it can be used as specified in > draft-ietf-roll-trickle-mcast-04. > > In section 10.1, "the MPL Domain Address" is a little confusing. Does a > device belong to just a single MPL Domain, in which case it might be clearer > to write "the MPL Domain Address to which the source interface belongs". > Otherwise - and I don't think I see any text in the document that explicitly > constrains an interface to belonging to one MPL domain - the text should > read "an MPL Domain Address to which the source interface belongs". > > - Ralph > > _______________________________________________ > Roll mailing list > Roll@ietf.org On 4/1/13, Ralph Droms wrote: > I apologize for the late feedback... > > Section 8 seems somewhat out of place, as well as redundant with the > definition of "MPL Domain" in section 2 and the contents of section 5.1. > > Multicast scope 0x03 has never been formally defined as "subnet-local". > Delete the references to "subnet-local" in sections 5.1 and 8, leaving just > "scope value of 3". Note that scope value 3 is currently defined as > "reserved" in RFC 4291. I am working on publication of an RFC that will > re-define scope value 3 as "(unassigned)" so it can be used as specified in > draft-ietf-roll-trickle-mcast-04. > > In section 10.1, "the MPL Domain Address" is a little confusing. Does a > device belong to just a single MPL Domain, in which case it might be clearer > to write "the MPL Domain Address to which the source interface belongs". > Otherwise - and I don't think I see any text in the document that explicitly > constrains an interface to belonging to one MPL domain - the text should > read "an MPL Domain Address to which the source interface belongs". > > - Ralph > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From mcr@sandelman.ca Fri Apr 12 09:58:15 2013 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 5116D21F8640; Fri, 12 Apr 2013 09:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbUwZxwU42ed; Fri, 12 Apr 2013 09:58:14 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 58D4A21F8617; Fri, 12 Apr 2013 09:58:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 781222016E; Fri, 12 Apr 2013 13:07:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 016EC638F7; Fri, 12 Apr 2013 12:57:51 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E3B75638E8; Fri, 12 Apr 2013 12:57:51 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <19846.1365772913@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: IETF 6TSCH <6tsch@ietf.org> Subject: Re: [Roll] [6tsch] draft agenda for call on April 12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 16:58:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On the 6tsch I wrote: ** Given the apparent dependancy that draft-ietf-roll-rpl-industrial-applicability-00=20 has on the 6tsch work, I wonder if this "BOF" effort would like to suggest text changes to the charter of the ROLL WG to the IESG. ** Would the 6tsch WG/BOF like to adopt the above work item? In further thinking this morning while unblock the shower drain, I realized that there are a number of additional options. From=20draft-ietf-roll-rpl-industrial-applicability-00: > It appears from the above sections that whether and the way RPL can > be applied for a given flow depends both on the deployment scenario > and on the class of application / traffic. At a high level, this can > be summarized by the following matrix: > > >+---------------------+------------------------------------------------+ >| Phase \ Class | 0 1 2 3 4 5 | >+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >| Construction | X X X X | >+---------------------+------------------------------------------------+ >| Planned startup | X X X X | >+---------------------+------------------------------------------------+ >| Normal operation | ? ? ? | >+---------------------+------------------------------------------------+ >| Planned shutdown | X X X X | >+---------------------+------------------------------------------------+ >|Plant decommissioning| X X X X | >+---------------------+------------------------------------------------+ >| Recovery and repair | X X X X X X | >+---------------------+------------------------------------------------+ > > ? : typically usable for all but higher-rate classes 0,1 PS traffic > > Figure 1: RPL applicability matrix my understanding is that "Normal Operation" is when the 6tsch schedules are really necessary. The rest of the time a non-timeslotted system might be perfectedly acceptable. So additional options would be for=20 draft-ietf-roll-rpl-industrial-applicability to become draft-ietf-roll-rpl-industrial-nonnormal-applicability and for a new document: draft-ietf-6tsch-rpl-industrial-normal-applicability to come to exist. This would mean that the current document would essentially declare normal operation to be out of scope (punt at 6tsch for this), and for the document to get finished. That would remove 6tsch as a blocker for this document. It's not the only option on how to do things. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUWg9D4qHRg3pndX9AQJ+egQA35v0aJXxm2flsQUMaD/oGRNRqWjSkHsY HMY3Dkw2HbfhM7C14P6EdLrMESY7pL2OCm3d9BtFju+cOXAHZk2HsiyxvLMvdd/i ofmUnivij0BEiugIsNFKNCQIO8RSwsbDnqHp+6CZqK6+sDqwNvsSAIIe8yL4jMr6 nlyv3sCELIQ= =4ucD -----END PGP SIGNATURE----- --=-=-=-- From trac+roll@trac.tools.ietf.org Mon Apr 15 02:13:16 2013 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 01C7921F9346 for ; Mon, 15 Apr 2013 02:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymnAyxAvU3or for ; Mon, 15 Apr 2013 02:13:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7103021F933B for ; Mon, 15 Apr 2013 02:13:11 -0700 (PDT) Received: from localhost ([127.0.0.1]:55370 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URfTG-0004WJ-RV; Mon, 15 Apr 2013 11:13:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: roll Date: Mon, 15 Apr 2013 09:13:06 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/104#comment:1 Message-ID: <073.6131ca490eb438a4e620d51e48f2084d@trac.tools.ietf.org> References: <058.955ce9de0a87bbb6918ebae344761d9b@trac.tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <058.955ce9de0a87bbb6918ebae344761d9b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130415091315.7103021F933B@ietfa.amsl.com> Resent-Date: Mon, 15 Apr 2013 02:13:11 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #104: trickle-mast: missing security considerations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:13:16 -0000 #104: trickle-mast: missing security considerations Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: section added in -03 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Mon Apr 15 02:16:03 2013 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 254FE21F934B for ; Mon, 15 Apr 2013 02:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PfaVgBjP4vM for ; Mon, 15 Apr 2013 02:16:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 819CD21F9335 for ; Mon, 15 Apr 2013 02:16:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:55454 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1URfW3-0001ju-4u; Mon, 15 Apr 2013 11:15:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: roll Date: Mon, 15 Apr 2013 09:15:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/112#comment:3 Message-ID: <078.cb5fddbcfced8f0ba967fd1b921da057@trac.tools.ietf.org> References: <063.468e22713e8b5bd609d1d9128c4b5ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <063.468e22713e8b5bd609d1d9128c4b5ce4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130415091602.819CD21F9335@ietfa.amsl.com> Resent-Date: Mon, 15 Apr 2013 02:16:02 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #112: MPL IANA request section to mention 0x0-0xFF range group ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:16:03 -0000 #112: MPL IANA request section to mention 0x0-0xFF range group ID Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: Done in -04: request is added. Note that this efficient compression can only be achieved for link-local (FF02::X) addresses with 1<=X<=255, e.g. if FF02::ALL_MPL_FORWARDERS will be used. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- esko.dijk@philips.com | mcast@tools.ietf.org Type: enhancement | Status: closed Priority: minor | Milestone: Component: trickle- | Version: mcast | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From tony.cheneau@nist.gov Fri Apr 19 10:51:58 2013 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 7004F21F95D2 for ; Fri, 19 Apr 2013 10:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1U9QZUbGcWS for ; Fri, 19 Apr 2013 10:51:55 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 871A721F944A for ; Fri, 19 Apr 2013 10:51:52 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Apr 2013 13:51:30 -0400 Received: from smtp.nist.gov (129.6.16.226) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server id 8.3.298.1; Fri, 19 Apr 2013 13:51:50 -0400 Received: from 24-140.antd.nist.gov (24-140.antd.nist.gov [129.6.140.24]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id r3JHpna6014610 for ; Fri, 19 Apr 2013 13:51:50 -0400 Date: Fri, 19 Apr 2013 13:51:49 -0400 From: "Tony V. Cheneau" To: Message-ID: <20130419135149.28a8e36f@24-140.antd.nist.gov> Organization: NIST X-Mailer: Claws Mail 3.9.0 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [Roll] Announcing the public release of SimpleRPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:05:57 -0000 Hello, I'd like to announce the release of SimpleRPL, a Linux-based implementation of the Routing Protocol for Low-Power and Lossy Networks (RPL). This implementation is a fully functional (and hopefully fully compliant) implementation of the standard. I tested it on both wired and wireless links and it ran just fine, although you might want to adjust some constant values (as I picked the default values from the RFC and did not performed any fine tuning yet). I could not test SimpleRPL against Contiki's implementation of RPL (due to the current 6LoWPAN interrop issues between Linux and Contiki), but I'll do it as soon as possible. The GitHub project page provide more information concerning the limitations and various design choices. The implementation is currently hosted on GitHub: https://github.com/tcheneau/simpleRPL Feedback is welcomed! Regards, Tony From stokcons@xs4all.nl Thu Apr 25 00:52:46 2013 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 A899421F93DE for ; Thu, 25 Apr 2013 00:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+QV4HiKpqIR for ; Thu, 25 Apr 2013 00:52:46 -0700 (PDT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC57A21F93DC for ; Thu, 25 Apr 2013 00:52:45 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id r3P7qh6g088043 for ; Thu, 25 Apr 2013 09:52:44 +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); Thu, 25 Apr 2013 09:52:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 25 Apr 2013 09:52:43 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (qFs8Y6Ci0hW4MlNYehwwq3gnXuwg4Tbi) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [Roll] multicast address in p2p-rpl-17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 07:52:46 -0000 Dear wg, having read draft-ietf-roll-p2p-rpl-17 I ended up with a question concerning the routing to a multicast address. I assume that routing the packet implies sending the packet with unicast to a given unicast address, following the source route table. However, in case of a multicast address, the draft does not specify how routing should take place from the last unicast address in the source route to the multicast destination address. Is this: - a link-local multicast to the multicast address - an invocation of MPL An alternative might be that all nodes for which an interface is enabled for the multicast address fill in their unicast address in the source route table; that means as many source routes as there are members of the multicast group; and routing ends at the last destination of the source route table. From the text it is not clear for me what the authors intended. __________________________________________________________________________________________________________________________________ Below there are some suggestions to improve text readability: section 1, introduction, text before the two bullits: .... due to the following reasons: /replace with/ ....due to the following characteristics of RPL [RFC6550] section 2 line 3, /remove/ "suddenly" section 3 last alinea ... The values for Counter is Time /replace with/ ... The values for Counter with T-flag (the first time this reads as a major cut/paste mistake) section 5 alinea 2, line 3, up to four source routes per target. Where does "four" come from? The text seems to hint that it is linked to a 2 bit field in the RDO format. section 5, last alinea of page 9. The story about service discovery rather breaks the flow of the document and needs much more becakground and motivation to be useful. I suggest to suppress or to start a new section. The consequence is that on page 10 the phrase: "This document does not specify ..... to select a route for ...." is less emphasized than it merits. section 6, page 11 and 12, use k instead of l, the latter confuses easily with 1, although I understand the relation with L. section 7, bullit TargetAddr, the unicast address is qualified but not the multicast address, why? section 9.5 2nd alinea end at page 27. ... avoid selecting routes that have large segments in common. The reason for this criterium being that multiple paths can be used to supply fault tolerance within a short period and not needing new route discovery. I found this rather important aspect nowhere mentioned in the text. I suggest adding a paragraph in the introduction for motivating p2p-rpl. Greetings, hope this helps, peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 From prvs=8207b0816=mukul@uwm.edu Thu Apr 25 04:36:36 2013 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 4138721F9434 for ; Thu, 25 Apr 2013 04:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg76Z1UIH6re for ; Thu, 25 Apr 2013 04:36:35 -0700 (PDT) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 45B2221F93E8 for ; Thu, 25 Apr 2013 04:36:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAJ0UeVF/AAAB/2dsb2JhbABRgzyDN7p6gReDEwEBAQQBAQEgJh4HBBMPEQQBAQMCDRYDAikfCQgGARKIFAytC4ksh2aBI41ZOwaCM4ETA4kQjgyRIIMsggo Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 90E0E2A0B27; Thu, 25 Apr 2013 06:36:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtNQWZHzLs1S; Thu, 25 Apr 2013 06:36:34 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 28B312A0B22; Thu, 25 Apr 2013 06:36:34 -0500 (CDT) Date: Thu, 25 Apr 2013 06:36:34 -0500 (CDT) From: Mukul Goyal To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Message-ID: <352231263.294156.1366889794050.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] multicast address in p2p-rpl-17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 11:36:36 -0000 Hi Peter P2P-RPL does not form a multicast tree if that is what you are asking. It just allows the discovery of _unicast_ routes to destinations that belong to a particular multicast group. A multicast address can be specified as Target in a P2P-RPL discovery and when a destination subscribing to this multicast group receives the DIO, it sends a DRO back (which carries a _unicast_ source route to this destination and which also establishes a hop-by-hop _unicast_ route to this particular destination if desired). I guess it is too late to make the editorial changes you suggested. I am trying to answer your other queries below: >section 5 alinea 2, line 3, up to four source routes per target. Where does "four" come from? The text seems to hint that it is linked to a 2 bit field in the RDO format. Yes. Also, it seems that there is no need for more routes per target. >section 7, bullit TargetAddr, the unicast address is qualified but not the multicast address, why? I guess you are referring to the requirement that unicast address be global or unique local. What qualification do you seek for the multicast address? Thanks Mukul ----- Original Message ----- From: "peter van der Stok" To: roll@ietf.org Sent: Thursday, April 25, 2013 2:52:43 AM Subject: [Roll] multicast address in p2p-rpl-17 Dear wg, having read draft-ietf-roll-p2p-rpl-17 I ended up with a question concerning the routing to a multicast address. I assume that routing the packet implies sending the packet with unicast to a given unicast address, following the source route table. However, in case of a multicast address, the draft does not specify how routing should take place from the last unicast address in the source route to the multicast destination address. Is this: - a link-local multicast to the multicast address - an invocation of MPL An alternative might be that all nodes for which an interface is enabled for the multicast address fill in their unicast address in the source route table; that means as many source routes as there are members of the multicast group; and routing ends at the last destination of the source route table. From the text it is not clear for me what the authors intended. __________________________________________________________________________________________________________________________________ Below there are some suggestions to improve text readability: section 1, introduction, text before the two bullits: .... due to the following reasons: /replace with/ ....due to the following characteristics of RPL [RFC6550] section 2 line 3, /remove/ "suddenly" section 3 last alinea ... The values for Counter is Time /replace with/ ... The values for Counter with T-flag (the first time this reads as a major cut/paste mistake) section 5 alinea 2, line 3, up to four source routes per target. Where does "four" come from? The text seems to hint that it is linked to a 2 bit field in the RDO format. section 5, last alinea of page 9. The story about service discovery rather breaks the flow of the document and needs much more becakground and motivation to be useful. I suggest to suppress or to start a new section. The consequence is that on page 10 the phrase: "This document does not specify ..... to select a route for ...." is less emphasized than it merits. section 6, page 11 and 12, use k instead of l, the latter confuses easily with 1, although I understand the relation with L. section 7, bullit TargetAddr, the unicast address is qualified but not the multicast address, why? section 9.5 2nd alinea end at page 27. ... avoid selecting routes that have large segments in common. The reason for this criterium being that multiple paths can be used to supply fault tolerance within a short period and not needing new route discovery. I found this rather important aspect nowhere mentioned in the text. I suggest adding a paragraph in the introduction for motivating p2p-rpl. Greetings, hope this helps, peter -- Peter van der Stok mailto: consultancy@vanderstok.org www: www.vanderstok.org tel NL: +31(0)492474673 F: +33(0)966015248 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From adrian@olddog.co.uk Thu Apr 25 23:31:07 2013 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 A433B21F97EE for ; Thu, 25 Apr 2013 23:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6M+4-771DNd for ; Thu, 25 Apr 2013 23:31:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 5705021F97ED for ; Thu, 25 Apr 2013 23:31:05 -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 r3Q6V4F6025674 for ; Fri, 26 Apr 2013 07:31:04 +0100 Received: from 950129200 ([31.100.87.72]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r3Q6UsO3025553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 26 Apr 2013 07:31:03 +0100 From: "Adrian Farrel" To: References: <20130425150452.13496.74796.idtracker@ietfa.amsl.com> In-Reply-To: <20130425150452.13496.74796.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 07:30:53 +0100 Message-ID: <022b01ce4247$9ffe08a0$dffa19e0$@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: AQKLz9jU1cYDIJEbXYNjyPbCNnyPlZdsm0/w Content-Language: en-gb Subject: [Roll] FW: Last Call: (Neighbor Unreachability Detection is too impatient) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 06:31:07 -0000 Since neighbor discovery is important to ROLL, you might want to look at this document currently in IETF last call. Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 25 April 2013 16:05 > To: IETF-Announce > Cc: ipv6@ietf.org > Subject: Last Call: (Neighbor > Unreachability Detection is too impatient) to Proposed Standard > > > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Neighbor Unreachability Detection is too impatient' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-05-09. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. > That function is very useful when a host has an alternative neighbor, > for instance when there are multiple default routers, since it allows > the host to switch to the alternative neighbor in short time. This > time is 3 seconds after the node starts probing by default. However, > if there are no alternative neighbors, this is far too impatient. > This document specifies relaxed rules for Neighbor Discovery > retransmissions that allow an implementation to choose different > timeout behavior based on whether or not there are alternative > neighbors. This document updates RFC 4861. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-impatient-nud/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From stokcons@xs4all.nl Fri Apr 26 01:00:25 2013 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 E94EF21F97DB for ; Fri, 26 Apr 2013 01:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqhpFqwEMtx2 for ; Fri, 26 Apr 2013 01:00:24 -0700 (PDT) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by ietfa.amsl.com (Postfix) with ESMTP id E794521F97DA for ; Fri, 26 Apr 2013 01:00:23 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id r3Q80LJU039873 for ; Fri, 26 Apr 2013 10:00:22 +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); Fri, 26 Apr 2013 10:00:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 26 Apr 2013 10:00:21 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: Message-ID: X-Sender: stokcons@xs4all.nl (1mkmd0JMc7/CxQR7luHJBuJPaEGTCRZo) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] multicast address in p2p-rpl-17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 08:00:25 -0000 Hi Mukul, thanks for your answer. I apologize for my late questions but they are motivated by my recent contribution to rpl applicability statement. I will reformulate my question in more detail. Suppose that a DIO arrives with a source: , and route and arrives at an interface with unicast IP address, IPdst, which is enabled for multicast address MCdst. What will the DRO contain that is sent back? In my opinion the text seems to allow at least 2 possibilities (and needs clarification): possibility 1: possibility 2: variation 2: In case of possibility 1, a packet, unicast routed from source to IPhop2, is probably propagated with a link-local multicast from IPhop2 to MCdst? That may suggest that only link-local Multicast addresses can be specified. When the packet is propagated from IPhop2 with MPL, (but then why do the unicast route first?) I would suggest to specify site-local and link-local MC addresses only. In case of possibility 2, with variation 2, the packet is unicast routed from source to IPdst. (this is closest to the objective you describe below, but further from the RPL-P2P text) The source receives as many DROs with at most 4 routes as there are members of the multicast group. That changes the restriction of "four source routes per target" into "four source routes per unicast destination". There is probably no technical limitation to the MC address but I would suggest also site-local and link-local MC addresses, given that rpl-p2p focusses on routing within a mesh, when routing via the root (edge router) gives unnecessary overhead. I hope my question is clearer now. Glad to read where my interpretation goes wrong. Greetings, peter Mukul Goyal schreef op 2013-04-25 13:36: > Hi Peter > P2P-RPL does not form a multicast tree if that is what you are > asking. It just allows the discovery of _unicast_ routes to > destinations that belong to a particular multicast group. A multicast > address can be specified as Target in a P2P-RPL discovery and when a > destination subscribing to this multicast group receives the DIO, it > sends a DRO back (which carries a _unicast_ source route to this > destination and which also establishes a hop-by-hop _unicast_ route to > this particular destination if desired). > I guess it is too late to make the editorial changes you suggested. I > am trying to answer your other queries below: > >> section 5 alinea 2, line 3, up to four source routes per target. >> Where > does "four" come from? The text seems to hint that it is linked to a 2 > bit field in the RDO format. > Yes. Also, it seems that there is no need for more routes per target. > >> section 7, bullit TargetAddr, the unicast address is qualified but >> not > the multicast address, why? > I guess you are referring to the requirement that unicast address be > global or unique local. What qualification do you seek for the > multicast address? > Thanks > Mukul > > > ----- Original Message ----- > From: "peter van der Stok" > To: roll@ietf.org > Sent: Thursday, April 25, 2013 2:52:43 AM > Subject: [Roll] multicast address in p2p-rpl-17 > Dear wg, > having read draft-ietf-roll-p2p-rpl-17 I ended up with a question > concerning the routing to a multicast address. > I assume that routing the packet implies sending the packet with > unicast to a given unicast address, following the source route table. > However, in case of a multicast address, the draft does not specify > how > routing should take place from the last unicast address in the source > route to the multicast destination address. Is this: > - a link-local multicast to the multicast address > - an invocation of MPL > An alternative might be that all nodes for which an interface is > enabled for the multicast address fill in their unicast address in the > source route table; that means as many source routes as there are > members of the multicast group; and routing ends at the last > destination > of the source route table. > From the text it is not clear for me what the authors intended. > __________________________________________________________________________________________________________________________________ > Below there are some suggestions to improve text readability: > section 1, introduction, text before the two bullits: > .... due to the following reasons: /replace with/ ....due to the > following characteristics of RPL [RFC6550] > section 2 line 3, /remove/ "suddenly" > section 3 last alinea ... The values for Counter is Time /replace > with/ ... The values for Counter with T-flag (the first time this > reads > as a major cut/paste mistake) > section 5 alinea 2, line 3, up to four source routes per target. Where > does "four" come from? The text seems to hint that it is linked to a 2 > bit field in the RDO format. > section 5, last alinea of page 9. The story about service discovery > rather breaks the flow of the document and needs much more becakground > and motivation to be useful. I suggest to suppress or to start a new > section. > The consequence is that on page 10 the phrase: "This document does not > specify ..... to select a route for ...." is less emphasized than it > merits. > section 6, page 11 and 12, use k instead of l, the latter confuses > easily with 1, although I understand the relation with L. > section 7, bullit TargetAddr, the unicast address is qualified but not > the multicast address, why? > section 9.5 2nd alinea end at page 27. ... avoid selecting routes that > have large segments in common. The reason for this criterium being > that > multiple paths can be used to supply fault tolerance within a short > period and not needing new route discovery. I found this rather > important aspect nowhere mentioned in the text. I suggest adding a > paragraph in the introduction for motivating p2p-rpl. > Greetings, hope this helps, > peter From prvs=82180c015=mukul@uwm.edu Fri Apr 26 08:06:55 2013 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 36ADE21F992B for ; Fri, 26 Apr 2013 08:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXZdglsBaP5N for ; Fri, 26 Apr 2013 08:06:54 -0700 (PDT) Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id CD08821F991F for ; Fri, 26 Apr 2013 08:06:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAK6XelF/AAAB/2dsb2JhbABRgz2DN7sCgRiDEwEBAQQBAQEgRAcEEw8RBAEBAwINGQIpKAgGARKIFAytSok2h30EgSONOzsGgjWBEwOJEo4LkSmDLIIK Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id A11EF2A0B51; Fri, 26 Apr 2013 10:06:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C46q6cSac72K; Fri, 26 Apr 2013 10:06:25 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 2725D2A0B6A; Fri, 26 Apr 2013 10:06:25 -0500 (CDT) Date: Fri, 26 Apr 2013 10:06:24 -0500 (CDT) From: Mukul Goyal To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks Message-ID: <1676928326.315269.1366988784639.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] multicast address in p2p-rpl-17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 15:06:55 -0000 Peter Please see inline. [Peter] Suppose that a DIO arrives with a source: , and route and arrives at an interface with unicast IP address, IPdst, which is enabled for multicast address MCdst. What will the DRO contain that is sent back? In my opinion the text seems to allow at least 2 possibilities (and needs clarification): possibility 1: possibility 2: variation 2: [Mukul] Variation 2 is what will happen. I think the draft is clear about it: Section 7, inside the description of TargetAddr field inside P2P-RDO: "When the P2P-RDO is included in a P2P-DRO, this field MUST contain a unicast global or unique local IPv6 address of the Target generating the P2P-DRO." Also, in Section 8.2 (Setting a P2P-RDO Carried in a P2P Discovery Reply Object): "TargetAddr: This field MUST contain a unicast global or unique local IPv6 address of the Target generating the P2P-DRO." Section 7, inside the description of Address[1..n] field inside P2P-RDO: "* The Origin and Target addresses MUST NOT be included in the Address vector." (So, the route wont include "IPdst") Inside Section 9.3 (Processing a P2P mode DIO): " The router MUST check the Target addresses listed in the P2P-RDO and any RPL Target Options included in the received DIO. If one of its IPv6 addresses is listed as a Target address or if it belongs to the multicast group specified as one of the Target addresses, the router considers itself a Target and processes the received DIO as specified in Section 9.5." and then Section 9.5 describes how P2P-DRO is generated. [Peter] In case of possibility 2, with variation 2, the packet is unicast routed from source to IPdst. (this is closest to the objective you describe below, but further from the RPL-P2P text) [Mukul] As I said above, I think the P2P-RPL text is clear about it. [Peter] The source receives as many DROs with at most 4 routes as there are members of the multicast group. [Mukul] If the Origin wants each Target (which, as per definition in Section 2, is "the IPv6 router at the other end point of the P2P route(s) to be discovered"; hence a multicast TargetAddr specifies multiple Targets) to send back 4 source routes. [Peter] That changes the restriction of "four source routes per target" into "four source routes per unicast destination". [Mukul] I wonder what sense "four source routes per multicast group" would make? I think "four source routes per target/unicast-dest" is fine if that is what Origin wants. Origin can ask for "one source route per target/unicast-dest" if that is what it wants. [Peter] There is probably no technical limitation to the MC address but I would suggest also site-local and link-local MC addresses, given that rpl-p2p focusses on routing within a mesh, when routing via the root (edge router) gives unnecessary overhead. [Mukul] Not sure what you mean. Thanks Mukul Mukul Goyal schreef op 2013-04-25 13:36: > Hi Peter > P2P-RPL does not form a multicast tree if that is what you are > asking. It just allows the discovery of _unicast_ routes to > destinations that belong to a particular multicast group. A multicast > address can be specified as Target in a P2P-RPL discovery and when a > destination subscribing to this multicast group receives the DIO, it > sends a DRO back (which carries a _unicast_ source route to this > destination and which also establishes a hop-by-hop _unicast_ route to > this particular destination if desired). > I guess it is too late to make the editorial changes you suggested. I > am trying to answer your other queries below: > >> section 5 alinea 2, line 3, up to four source routes per target. >> Where > does "four" come from? The text seems to hint that it is linked to a 2 > bit field in the RDO format. > Yes. Also, it seems that there is no need for more routes per target. > >> section 7, bullit TargetAddr, the unicast address is qualified but >> not > the multicast address, why? > I guess you are referring to the requirement that unicast address be > global or unique local. What qualification do you seek for the > multicast address? > Thanks > Mukul > > > ----- Original Message ----- > From: "peter van der Stok" > To: roll@ietf.org > Sent: Thursday, April 25, 2013 2:52:43 AM > Subject: [Roll] multicast address in p2p-rpl-17 > Dear wg, > having read draft-ietf-roll-p2p-rpl-17 I ended up with a question > concerning the routing to a multicast address. > I assume that routing the packet implies sending the packet with > unicast to a given unicast address, following the source route table. > However, in case of a multicast address, the draft does not specify > how > routing should take place from the last unicast address in the source > route to the multicast destination address. Is this: > - a link-local multicast to the multicast address > - an invocation of MPL > An alternative might be that all nodes for which an interface is > enabled for the multicast address fill in their unicast address in the > source route table; that means as many source routes as there are > members of the multicast group; and routing ends at the last > destination > of the source route table. > From the text it is not clear for me what the authors intended. > __________________________________________________________________________________________________________________________________ > Below there are some suggestions to improve text readability: > section 1, introduction, text before the two bullits: > .... due to the following reasons: /replace with/ ....due to the > following characteristics of RPL [RFC6550] > section 2 line 3, /remove/ "suddenly" > section 3 last alinea ... The values for Counter is Time /replace > with/ ... The values for Counter with T-flag (the first time this > reads > as a major cut/paste mistake) > section 5 alinea 2, line 3, up to four source routes per target. Where > does "four" come from? The text seems to hint that it is linked to a 2 > bit field in the RDO format. > section 5, last alinea of page 9. The story about service discovery > rather breaks the flow of the document and needs much more becakground > and motivation to be useful. I suggest to suppress or to start a new > section. > The consequence is that on page 10 the phrase: "This document does not > specify ..... to select a route for ...." is less emphasized than it > merits. > section 6, page 11 and 12, use k instead of l, the latter confuses > easily with 1, although I understand the relation with L. > section 7, bullit TargetAddr, the unicast address is qualified but not > the multicast address, why? > section 9.5 2nd alinea end at page 27. ... avoid selecting routes that > have large segments in common. The reason for this criterium being > that > multiple paths can be used to supply fault tolerance within a short > period and not needing new route discovery. I found this rather > important aspect nowhere mentioned in the text. I suggest adding a > paragraph in the introduction for motivating p2p-rpl. > Greetings, hope this helps, > peter _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From hammondjohnson@hushmail.com Sat Apr 27 14:07:00 2013 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 048F621F9949 for ; Sat, 27 Apr 2013 14:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdq3TrlgA7PQ for ; Sat, 27 Apr 2013 14:06:59 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE921F9940 for ; Sat, 27 Apr 2013 14:06:59 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id F25F6E7D3E for ; Sat, 27 Apr 2013 18:04:30 +0000 (UTC) X-hush-relay-time: 220 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 18:04:30 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id BCB06E6736; Sat, 27 Apr 2013 18:04:30 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 14:04:30 -0400 To: roll@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427180430.BCB06E6736@smtp.hushmail.com> Subject: [Roll] Biggest Fake Conference in Computer Science X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:07:00 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From stokcons@xs4all.nl Mon Apr 29 00:31:34 2013 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 0B7B321F97EE for ; Mon, 29 Apr 2013 00:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2LAtQH+KnDt for ; Mon, 29 Apr 2013 00:31:33 -0700 (PDT) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 047A421F8523 for ; Mon, 29 Apr 2013 00:31:29 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube3.xs4all.net [194.109.20.199]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id r3T7VQA0017881; Mon, 29 Apr 2013 09:31:27 +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); Mon, 29 Apr 2013 09:31:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 Apr 2013 09:31:26 +0200 From: peter van der Stok To: Mukul Goyal Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <1676928326.315269.1366988784639.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1676928326.315269.1366988784639.JavaMail.root@mail17.pantherlink.uwm.edu> Message-ID: <37aad08d27c19499b5f17f2a493f9196@xs4all.nl> X-Sender: stokcons@xs4all.nl (P4jfgOcPujJHoLG5TUDXAThr0eEnH9J4) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] multicast address in p2p-rpl-17 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2013 07:31:34 -0000 Mukul, Thanks for the detailed pointing out of text. Not reading the explicit changing of MC address to unicast address in the RDO at arrival at the target, I read the text as being valid for the unicast case, with the multicast case left open. My mistake, Greetings, peter Mukul Goyal schreef op 2013-04-26 17:06: > Peter > > Please see inline. > > [Peter] > Suppose that a DIO arrives with a source: , and route > and arrives at an interface with unicast IP address, > IPdst, which is enabled for multicast address MCdst. > What will the DRO contain that is sent back? In my opinion the text > seems to allow at least 2 possibilities (and needs clarification): > possibility 1: IPhop2> > possibility 2: IPhop2, IPdst> > variation 2: IPhop2> > > [Mukul] > Variation 2 is what will happen. I think the draft is clear about it: > > Section 7, inside the description of TargetAddr field inside P2P-RDO: > "When the P2P-RDO is included in a > P2P-DRO, this field MUST contain a unicast global or unique > local > IPv6 address of the Target generating the P2P-DRO." > > Also, in Section 8.2 (Setting a P2P-RDO Carried in a P2P Discovery > Reply Object): > "TargetAddr: This field MUST contain a unicast global or unique > local IPv6 address of the Target generating the P2P-DRO." > > Section 7, inside the description of Address[1..n] field inside > P2P-RDO: > "* The Origin and Target addresses MUST NOT be included in the > Address vector." > (So, the route wont include "IPdst") > > Inside Section 9.3 (Processing a P2P mode DIO): > " The router MUST check the Target addresses listed in the P2P-RDO and > any RPL Target Options included in the received DIO. If one of its > IPv6 addresses is listed as a Target address or if it belongs to > the > multicast group specified as one of the Target addresses, the > router > considers itself a Target and processes the received DIO as > specified > in Section 9.5." > > and then Section 9.5 describes how P2P-DRO is generated. > > [Peter] > > In case of possibility 2, with variation 2, the packet is unicast > routed from source to IPdst. (this is closest to the objective you > describe below, but further from the RPL-P2P text) > > [Mukul] > As I said above, I think the P2P-RPL text is clear about it. > > [Peter] > The source receives as many DROs with at most 4 routes as there are > members of the multicast group. > > [Mukul] > If the Origin wants each Target (which, as per definition in Section > 2, is "the IPv6 router at the other end point of the P2P route(s) to > be discovered"; hence a multicast TargetAddr specifies multiple > Targets) to send back 4 source routes. > > [Peter] > That changes the restriction of "four > source routes per target" into "four source routes per unicast > destination". > > [Mukul] > I wonder what sense "four source routes per multicast group" would > make? I think "four source routes per target/unicast-dest" is fine if > that is what Origin wants. Origin can ask for "one source route per > target/unicast-dest" if that is what it wants. > > [Peter] > There is probably no technical limitation to the MC > address but I would suggest also site-local and link-local MC > addresses, > given that rpl-p2p focusses on routing within a mesh, when routing via > the root (edge router) gives unnecessary overhead. > > [Mukul] > Not sure what you mean. > > Thanks > Mukul > > > Mukul Goyal schreef op 2013-04-25 13:36: >> Hi Peter >> P2P-RPL does not form a multicast tree if that is what you are >> asking. It just allows the discovery of _unicast_ routes to >> destinations that belong to a particular multicast group. A multicast >> address can be specified as Target in a P2P-RPL discovery and when a >> destination subscribing to this multicast group receives the DIO, it >> sends a DRO back (which carries a _unicast_ source route to this >> destination and which also establishes a hop-by-hop _unicast_ route >> to >> this particular destination if desired). >> I guess it is too late to make the editorial changes you suggested. I >> am trying to answer your other queries below: >> >>> section 5 alinea 2, line 3, up to four source routes per target. >>> Where >> does "four" come from? The text seems to hint that it is linked to a >> 2 >> bit field in the RDO format. >> Yes. Also, it seems that there is no need for more routes per target. >> >>> section 7, bullit TargetAddr, the unicast address is qualified but >>> not >> the multicast address, why? >> I guess you are referring to the requirement that unicast address be >> global or unique local. What qualification do you seek for the >> multicast address? >> Thanks >> Mukul >> >> >> ----- Original Message ----- >> From: "peter van der Stok" >> To: roll@ietf.org >> Sent: Thursday, April 25, 2013 2:52:43 AM >> Subject: [Roll] multicast address in p2p-rpl-17 >> Dear wg, >> having read draft-ietf-roll-p2p-rpl-17 I ended up with a question >> concerning the routing to a multicast address. >> I assume that routing the packet implies sending the packet with >> unicast to a given unicast address, following the source route table. >> However, in case of a multicast address, the draft does not specify >> how >> routing should take place from the last unicast address in the source >> route to the multicast destination address. Is this: >> - a link-local multicast to the multicast address >> - an invocation of MPL >> An alternative might be that all nodes for which an interface is >> enabled for the multicast address fill in their unicast address in >> the >> source route table; that means as many source routes as there are >> members of the multicast group; and routing ends at the last >> destination >> of the source route table. >> From the text it is not clear for me what the authors intended. >> __________________________________________________________________________________________________________________________________ >> Below there are some suggestions to improve text readability: >> section 1, introduction, text before the two bullits: >> .... due to the following reasons: /replace with/ ....due to the >> following characteristics of RPL [RFC6550] >> section 2 line 3, /remove/ "suddenly" >> section 3 last alinea ... The values for Counter is Time /replace >> with/ ... The values for Counter with T-flag (the first time this >> reads >> as a major cut/paste mistake) >> section 5 alinea 2, line 3, up to four source routes per target. >> Where >> does "four" come from? The text seems to hint that it is linked to a >> 2 >> bit field in the RDO format. >> section 5, last alinea of page 9. The story about service discovery >> rather breaks the flow of the document and needs much more >> becakground >> and motivation to be useful. I suggest to suppress or to start a new >> section. >> The consequence is that on page 10 the phrase: "This document does >> not >> specify ..... to select a route for ...." is less emphasized than it >> merits. >> section 6, page 11 and 12, use k instead of l, the latter confuses >> easily with 1, although I understand the relation with L. >> section 7, bullit TargetAddr, the unicast address is qualified but >> not >> the multicast address, why? >> section 9.5 2nd alinea end at page 27. ... avoid selecting routes >> that >> have large segments in common. The reason for this criterium being >> that >> multiple paths can be used to supply fault tolerance within a short >> period and not needing new route discovery. I found this rather >> important aspect nowhere mentioned in the text. I suggest adding a >> paragraph in the introduction for motivating p2p-rpl. >> Greetings, hope this helps, >> peter > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll