Re: [Roll] Mail regarding draft-thubert-roll-asymlink
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 30 November 2011 06:51 UTC
Return-Path: <pthubert@cisco.com>
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 6AB4911E808B for <roll@ietfa.amsl.com>; Tue, 29 Nov 2011 22:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 DOeDa5zq80Jc for <roll@ietfa.amsl.com>; Tue, 29 Nov 2011 22:51:48 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 366C811E8083 for <roll@ietf.org>; Tue, 29 Nov 2011 22:51:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=65534; q=dns/txt; s=iport; t=1322635905; x=1323845505; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ZKHiltx1aMUcVLZXGojj13L3/VXuWrQko2V8+jlh5Os=; b=hhcV3L/a2Dwyyj17LDA8tOnevK4etjKWRWrkdW5A1ODZP5tALqrTjsYo 2DXVeLXqUktZ6EzAebgcUzwDZmMhx6LKjJDJJYLQa8+N9HPWdIjyLHvms rVdlHNyF/foV7BPXD8tDctfcoOEoEGYmpyo8F3/1L8nhxruo8zG0mhKKk U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAL3R1U6Q/khL/2dsb2JhbABEgk2oNoEFgXIBAQEEDAYBCREDSRACAQgRBAEBCwYQAQYBBgFFCQgBAQQBCQkIEwehXQGeNoouYwSmaA
X-IronPort-AV: E=Sophos; i="4.69,595,1315180800"; d="scan'208,217"; a="122779494"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2011 06:51:43 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAU6ph1o013484; Wed, 30 Nov 2011 06:51:43 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Nov 2011 07:51:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAF2C.851F2C1B"
Date: Wed, 30 Nov 2011 07:50:31 +0100
Message-ID: <BDF2740C082F6942820D95BAEB9E1A84790D7F@XMB-AMS-108.cisco.com>
In-Reply-To: <a25809669156d81154bbc03b627f495d@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Roll] Mail regarding draft-thubert-roll-asymlink
Thread-Index: Acyu04PCqW7QkuVjRCeei851PmupjAAWK8fA
References: <a25809669156d81154bbc03b627f495d@mail.gmail.com>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Yoav Ben-Yehezkel <yoav@yitran.com>, draft-thubert-roll-asymlink@tools.ietf.org
X-OriginalArrivalTime: 30 Nov 2011 06:51:43.0398 (UTC) FILETIME=[8522E460:01CCAF2C]
Cc: roll@ietf.org
Subject: Re: [Roll] Mail regarding draft-thubert-roll-asymlink
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2011 06:51:55 -0000
Thanks a bunch Yoav. On the side, do you see that this work is useful for your applications? Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: mardi 29 novembre 2011 21:20 To: draft-thubert-roll-asymlink@tools.ietf.org Cc: roll@ietf.org Subject: [Roll] Mail regarding draft-thubert-roll-asymlink Dear Roll-ers, Find below comments to the draft. Mostly editorial, I hope they make sense. Best regards, Yoav Comments to Introduction section 1: In one hand, RPL requires bi-directional links for the control, but on the other, there is no requirement that the properties of a link are the same in both directions. In fact, a perfect symmetry is rarely present in Low Power and Lossy Networks (LLNs), whether links are based on radios or power-line. 1. Replace "In one hand" with "On one hand" 2. Replace "on the other," with "on the other hand,". 3. Replace "whether links are based on radios or power-line" with "such as wireless radio or power-line links." Some initial implementations require that the quality of both directions of a link is evaluated as very good so that the link can be used for control and data in both directions. This eliminates asymmetrical links that are very good in one direction, but only good enough for scarce activity in the other direction. 4. Replace "that the quality of both directions of a link is evaluated as very good" with "that the quality of both directions of a link is evaluated as operational at an acceptable level" - because they do not necessarily have to be very good. Comments to Terminology section 2: The term upwards qualifies a link, a DODAG or an instance that is optimal for sending traffic in the general direction of the root, though may be usable but suboptimal for traffic coming form the direction of the root. The term downwards qualifies the same words for the opposite direction. 1. Should the term "instance" be replaced with the term "RPL instance"? 2. What does "general direction of the root" means? Shouldn't it simply be "towards the root"? 3. Replace "though may be usable but suboptimal for traffic coming form the direction of the root" with "though may be usable but suboptimal for traffic coming from the direction of the root" (form=from) 4. Replace "The term downwards qualifies the same words for the opposite direction" with "The term downwards qualifies the same wording, only for opposite directions" 5. Question: shouldn't the terms "upwards" and "downwards" be included into the terminology draft? bi-directional: A link is bi-directional when traffic confirmed possible in both direction, in a fashion that is sufficient to operate RPL control. 1. Replace "possible in both direction" with "possible in both directions" (missing 's'). asymmetric: A link is assymetric if it is bi-directional, but exhibits important differences in link characteristics for both directions. 1. Replace "A link is assymetric" with "A link is asymmetric" (typo) 2. Replace "important" with "major" Comments to The asymmetrical link problem section 3: 1. Capitalize first letter of each word like in all other sections. Comments to Solution Overview section 4: One direct consequence of that design choice is that a topology must be very good for both upwards and downwards traffic; 1. Replace "very good" with "operational at an acceptable level". In that case, an asymmetrical link, that can only be used for traffic in one direction, can not participate to the routing topology. 1. Replace "can not" with "cannot". OTOH, with RPL as it is specified,... 1. Replace "OTOH" with "On the other hand". ... so that a node may transfer traffic from an instance onto another. 1. Replace "an instance onto another" with "an upwards instance onto the downwards instance". Comments to Modified DIO section 5: Directional (D): The Directional (D) flag is set to indicate that the instance is intended for directional operation, and reset otherwise. When it is set, a MOP of 0 indicates the upwards direction whereas any other value specified in [I-D.ietf-roll-rpl] indicates downwards. All other values of MOP will be considered downwards unless explicitly specified otherwise. 1. Replace "and reset otherwise" with "and is reset otherwise". 2. Replace "upwards direction" with "upwards", or add the word "direction" to all subsequence indications of the word "downwards" 3. Replace "will be considered downwards" with "shall be considered downwards". Comments to Operations section 6: This specification allows an organization of Instances as follows: 1. Replace "Instances" with "instances" (non-capitalized 'I') The direction is indicated by the MOP field, a MOP of 0 means upwards and otherwise is downwards. 2. Replace "a MOP of 0 means" with "a MOP set to a value 0 indicates" 3. Replace "and otherwise is downwards" with "and indicates downwards if set otherwise". Transferring from an upwards instance to a downwards instance if generally desirable. Other forms of transfers are generally not desirable. Policies MAY be put in place to ovreride that general guidance. 1. Replace "if" with "is" 2. Remove "generally" and "general" or explain what they mean. 3. Replace "put in place" with "used" 4. Replace "ovreride" with "override" Comments to Backward compatibility section 7: 1. Replace "Backward" with "Backwards" 2. Replace "compatibility" with "Compatibility" (capital 'C') An OF is generally designed to compute a Rank of a directional link in a fashion that is diffent from a bidirectional link, and in particular will not use the same metrics and thusobtain different ranks for a same situation. 1. Replace "diffent" with "different" 2. Missing space between "thus" and "obtain" An OF that supports directional links SHOULD favor directional links over non directional links, in a fashion that is to be specified with the OF. In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be accounted for before the computation of item 8 in the "Selection Of The Preferred Parent" section 4.2.1., that is before Ranks and be calculated and compared. 1. Replace "specified with the OF" with "specified by the OF" 2. Replace "section 4.2.1.," with "section 4.2.1," (remove extra dot) 3. 4. Replace "that is before Ranks and be calculated and compared" with "that is before ranks are calculated and compared" (is there anything else that needs comparison other than the rank?) Comments to IANA Considerations section 8: This specification requires that a bit in DIO be assigned to indicate directional link operations as specified in section 1. Replace "a bit in DIO be assigned" with "a bit in DIO shall be assigned" 2. Replace "as specified in section" with "as specified in section 5" Comments to Security Considerations section 9: Security Considerations for this proposal are to be developed in accordance with recommendations laid out in, for example, [I-D.tsao-roll-security-framework]. 1. Replace "Security Considerations for this proposal" in the first line with "Security considerations for this proposal" (non-capitalized 'c')
- [Roll] Mail regarding draft-thubert-roll-asymlink Yoav Ben-Yehezkel
- Re: [Roll] Mail regarding draft-thubert-roll-asym… Pascal Thubert (pthubert)
- Re: [Roll] Mail regarding draft-thubert-roll-asym… Yoav Ben-Yehezkel
- Re: [Roll] Mail regarding draft-thubert-roll-asym… Pascal Thubert (pthubert)
- Re: [Roll] Mail regarding draft-thubert-roll-asym… Pascal Thubert (pthubert)