Re: [Roll] Mail regarding draft-thubert-roll-asymlink

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Yoav:

 

I just published the new version of the draft that accounts for your
comments.

 

Thanks again!

 

Pascal

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Yoav Ben-Yehezkel
Sent: mardi 29 novembre 2011 21:20
To: [e-mail]
Cc: [e-mail]
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')

 

 

 
 
 

 

--- Begin Message ---

A new version of I-D, draft-thubert-roll-asymlink-02.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Filename:	 draft-thubert-roll-asymlink
Revision:	 02
Title:		 RPL adaptation for asymmetrical links
Creation date:	 2011-12-09
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   The Routing Protocol for Low Power and Lossy Networks defines a
   generic Distance Vector protocol for Low Power and Lossy Networks,
   many of which exhibit strongly asymmetrical characteristics.  This
   draft proposes an extension for that optimizes RPL operations whereby
   upwards and downwards direction-optimized RPL instances are
   associated.


                                                                                  


The IETF Secretariat

--- End Message ---