Subject: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt

From: [email-masked]
Date: Wed, 15 Dec 2010 15:00:01 -0800

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           : RPL: IPv6 Routing Protocol for Low power and Lossy Networks
	Author(s)       : T. Winter, et al.
	Filename        : draft-ietf-roll-rpl-17.txt
	Pages           : 159
	Date            : 2010-12-15

Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained.  LLN routers
typically operate with constraints on processing power, memory, and
energy (battery power).  Their interconnects are characterized by
high loss rates, low data rates, and instability.  LLNs are comprised
of anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices
inside the LLN), point-to-multipoint (from a central control point to
a subset of devices inside the LLN), and multipoint-to-point (from
devices inside the LLN towards a central control point).  This
document specifies the IPv6 Routing Protocol for LLNs (RPL), which
provides a mechanism whereby multipoint-to-point traffic from devices
inside the LLN towards a central control point, as well as point-to-
multipoint traffic from the central control point to the devices
inside the LLN, is supported.  Support for point-to-point traffic is
also available.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tim Winter <[email-masked]>
Date: Wed, 15 Dec 2010 18:08:31 -0500

WG,

With this revision we continue to address concerns brought up in IESG evaluation 
(https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/)

Regards,

-Tim

On 12/15/2010 06:00 PM, [email-masked] wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 17 Dec 2010 14:40:24 -0800

There seems to be a discrepancy between draft-ietf-roll-rpl-17 and 
draft-ietf-6man-rpl-routing-header-01:

The following pseudo code in the RPL RH draft:

           else if i<  n and Address[i] is not on-link {
              send an ICMP Destination Unreachable, Code 7, message to	<--***
              the Source Address and discard the packet
           }
           else {
              swap the IPv6 Destination Address and Address[i]	<--***

              if the IPv6 Hop Limit is less than or equal to 1 {
                 send an ICMP Time Exceeded -- Hop Limit Exceeded in
                 Transit message to the Source Address and discard the
                 packet
              }

does not correlate with the following wording in the RPL draft (section 
11.2.2.3):

      ....                 .... The "Error in Source Routing Header"
    message has the
    same format as the "Destination Unreachable Message" as specified in
    [RFC4443].  The portion of the invoking packet that is sent back in
    the ICMP message should record at least up to the routing header, and
    the routing header should be consumed by this node so that the
    destination in the IPv6 header is the next hop that this node could
    <--***
    not reach.

Dario

---

From: Christopher Ntyangiri <[email-masked]>
Date: Sun, 19 Dec 2010 18:15:56 -0800 (PST)

Tim,

I have a question regarding how to send PIO in RPL.

From "6.7.10.  Prefix Information" it has been clearly stated that
   "The root of a DODAG is authoritative for setting that information.
   The information is propagated down the DODAG unchanged, with the
   exception that a RPL router may update (extend) the prefix by
   appending it's own suffix."
 
Now, in the appendix:
A.2. Example Operation in Storing Mode With Node-owned Prefixes
A.2.1. DIO messages and PIO
Node A, for example, will send DIO messages with a PIO as follows:
’A’ flag: Set
’L’ flag: Set
’R’ flag: Clear
Prefix Length: 64
Prefix: A::

Node B, for example, will send DIO messages with a PIO as follows:
’A’ flag: Set
’L’ flag: Set
’R’ flag: Set
Prefix Length: 64
Prefix: B::B
...

Here, Node B has completely changed the Prefix received from the Root.
Is there something I don't understand?

Thanks in advance.

Chris.

________________________________
From: Tim Winter <[email-masked]>
To: [email-masked]
Sent: Thu, December 16, 2010 8:08:31 AM
Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt

WG,

Regards,

-Tim

---

From: Christopher Ntyangiri <[email-masked]>
Date: Sun, 19 Dec 2010 19:16:37 -0800 (PST)

To elaborate more.
I can see there is an exception when the PIO's  L flag is set.
That is the "L" flag distinguish between <1> Subnet-wide Prefix
and <2>Node-owned Prefixes.

Wouldn't it be better to elaborate this as another exception in 
"6.7.10.  Prefix Information". Or add the words "For Subnet-wide Prefix "
as below.
 
   "For Subnet-wide Prefix the root of a DODAG is authoritative for setting that 
information.

Chris.

________________________________
From: Christopher Ntyangiri <[email-masked]>
To: [email-masked]
Sent: Mon, December 20, 2010 11:15:56 AM
Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt

Tim,

 
Now, in the appendix:

Thanks in advance.

Chris.

WG,

Regards,

-Tim