Subject: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT))

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Feb 2013 08:48:06 -0500

I am including the WG mailing list in my reply, and fixing the subject.
This relates to: 
     http://datatracker.ietf.org/streams/draft-ietf-roll-p2p-rpl/history/

(If there is a better way to link to just Brian Haberman's comments
in the history I don't know.  I don't like the pop-up, I had to play
browser tricks to get the above URL)

see inline below.

Brian> I am confused by the last bullet in 6.1. It states that a
Brian> P2P-mode DIO may carry a PIO option, but no where does this
Brian> document describe why (or how) that option would be used in this
Brian> approach. What benefit would including a PIO have? Where would an
Brian> arbitrary node in a RPL network get the information to include in
Brian> a PIO? 

Brian raised an interesting question, and I had to think about this.
I see this as an issue of "be liberal in what you accept", and a
question of protecting future innovation by not saying things are
illegal just because can't think what they mean right now.

However, after read the thread, I offer how I can see using a PIO in a DIO.

>>>>> "Brian" == Brian Haberman <[email-masked]> writes:
    >> Hi Brian
    >> 
    >> Not sure what you mean.
    >> 
    >> In P2P-RPL, the DAG is ephemeral but not the discovered routes.

    Brian> What I mean is it does not make sense (to me) to include
    Brian> information that is used to configure IPv6 addresses.
    Brian> Including a PIO in a DIO means that the Source node expects
    Brian> children to autoconfigure addresses using the specified
    Brian> prefix.  However, they already have addresses based on the
    Brian> PIO that would have come down the DODAG (originated at the
    Brian> root). I am trying to understand a use-case where having new

You assume a root DODAG here, which might not (yet) exist.
And, not all DODAGs are grounded, and therefore might not even have
address space yet with which to send out PIOs.

There might not be any root controller/LBR yet, because the factory
and/or house has not yet completed construction.

The resulting routes could consist of link layer addresses only, so the
light switch could still discover the light bulb when the jiprock(wall) is
still not yet up.

If one contemplates full EUI-64 based SLACC with the PIO in that DIO,
then one would be able to see in the mDNS, (or other service discovery) what
the serial number of the light bulb/socket and controller was involved.
(What bulb did you just discover?)

While mDNS and friends can use link layer addresses, on an LLNs, there is
significant advantages to using the 16-bit versions, and that may not
provide the detail one needs.

So, I see no reason to forbid the PIO, but I agree that it might be
unusual to have it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian Haberman <[email-masked]>
Date: Thu, 07 Feb 2013 17:01:33 -0500

Hi Michael,

> So, I see no reason to forbid the PIO, but I agree that it might be

The above does explain a possible use for a PIO in this approach.  I do 
think the draft could benefit from a *brief* description of the above so 
that future readers have some idea of why a PIO is allowed.

Regards,
Brian

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 8 Feb 2013 06:56:19 -0600 (CST)

Michael

Could you offer text, describing possible use of PIOs in P2P mode DIOs, that I could put in the draft?

Thanks
Mukul   

----- Original Message -----
From: "Brian Haberman" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: [email-masked], "Mukul Goyal" <[email-masked]>, "The IESG" <[email-masked]>, [email-masked], [email-masked], [email-masked], "Anders Brandt" <[email-masked]>
Sent: Thursday, February 7, 2013 4:01:33 PM
Subject: Re: use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT))

Hi Michael,

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Feb 2013 10:41:59 -0500

On Feb 7, 2013, at 5:01 PM 2/7/13, Brian Haberman <[email-masked]> wrote:

> The above does explain a possible use for a PIO in this approach.  I do think the draft could benefit from a *brief* description of the above so that future readers have some idea of why a PIO is allowed.

Has this use case been written down and discussed by the WG?

I could see using a non-grounded DAG for this purpose as a way for a stand-alone mesh to establish subnet communication.

It seems inappropriate as a side-effect of a DAG established for point-to-point communication between two mesh nodes.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Feb 2013 12:04:57 -0500

Suggested text, new section 9.8:

9.8 Processing of DIO options in a P2P Temporary DAG

RFC6550 defines a number of DIO options.  The DAG Metric (0x02),
Routing Information (0x03) and DODAG Configuration (0x04). 
The Prefix Information (0x08) would not normally be included 
in the RPL P2P DIO messages.  Any current or future DIO options
are permitted in a P2P DIO message, and unknown ones should be ignored,
and not cause the DIO message to be rejected as invalid.(XXX)

In the specific case of Prefix Information in a DIO, this would normally
cause a node to configure an address using that prefix.   This is
generally not desireable for the temporary DAG that P2P RPL wishes to
construct. The P2P DIO SHOULD not include the Prefix Information option.
A node that receives a P2P DIO with a PIO option and is a member of
other DODAGs that have already provided it with Prefix Information MAY
ignore the Prefix Information.  The Prefix Information SHOULD be 
copied into any DIO messages sent by this node.

There is probably only a single use case for including Prefix
Information into a P2P RPL.  This would be the situation where a LLN is
being installed, the LLN is not complete (has no border router yet) and
the installers need to know if the components installed work, and more
specifically if they have provisioned enough routers in the right places
so that a P2P route can in fact be found.   While the P2P route can
consist of link-layer addresses, with the small size (16-bits) used as
the MAC Address, it could be hard to relate an observed route back to
actual devices involved.

(XXX) - I don't think RFC6550 says what to do with options that
      a node does not understand.  Specifically whether or not they should
      be copied into DIOs generated downstream by a node.
      I can think of arguments both ways!!!

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Feb 2013 13:05:11 -0500

>>>>> "Ralph" == Ralph Droms <[email-masked]> writes:
    >>> You assume a root DODAG here, which might not (yet) exist.  And,
    >>> not all DODAGs are grounded, and therefore might not even have
    >>> There might not be any root controller/LBR yet, because the
    >>> factory and/or house has not yet completed construction.
    >>> 
    >>> The resulting routes could consist of link layer addresses only,
    >>> so the light switch could still discover the light bulb when the
    >>> jiprock(wall) is still not yet up.
    >>> 
    >>> If one contemplates full EUI-64 based SLACC with the PIO in that
    >>> DIO, then one would be able to see in the mDNS, (or other
    >>> service discovery) what the serial number of the light
    >>> bulb/socket and controller was involved.  (What bulb did you
    >>> just discover?)
    >>> 
    >>> While mDNS and friends can use link layer addresses, on an LLNs,
    >>> there is significant advantages to using the 16-bit versions,
    >>> and that may not provide the detail one needs.
    >>> 
    >>> So, I see no reason to forbid the PIO, but I agree that it might
    >>> be unusual to have it.
    >>> 
    >> The above does explain a possible use for a PIO in this approach.
    >> I do think the draft could benefit from a *brief* description of
    >> the above so that future readers have some idea of why a PIO is
    >> allowed.

    Ralph> Has this use case been written down and discussed by the WG?

    Ralph> I could see using a non-grounded DAG for this purpose as a
    Ralph> way for a stand-alone mesh to establish subnet communication.

    Ralph> It seems inappropriate as a side-effect of a DAG established
    Ralph> for point-to-point communication between two mesh nodes.

I hope you will read my suggested text.
I agree that a piece of test equipment could create a non-grounded DAG.
I think that the question is both:
  a) does the presence of a PIO render the DIO invalid?
  b) related to this, does the presence of an unknown DIO option
     render the DIO invalid?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Feb 2013 13:14:17 -0500

> b) related to this, does the presence of an unknown DIO option

I did read your text, but your questions are predicated on a premise I disagreed with in my previous answer, so I didn't comment on your text.

I don't think there is ever a justification for a PIO in a P2P-RPL DIO.  Enabling mesh communication as a side-effect of forming a P2P DAG is inappropriate.  Use a non-grounded DAG for your use case.

- Ralph

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 8 Feb 2013 13:16:29 -0600 (CST)

I realized that some of the folks on this message might not have received Michael's text. So, here it is:

Thanks
Mukul