Subject: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-03

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Feb 2013 13:58:16 -0500

This is to start a 1 week WG call on adopting 

  Applicability Statement: The use of RPL-P2P in Home and Building Control
  draft-brandt-roll-rpl-applicability-home-building-03

as a WG document.  

Please, if you have objection to this document as a starting document
towards use of RPL in Home and Building LLN networks, please speak by 
2013-02-28.

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Feb 2013 01:21:18 +0100

Hi Michael,

I wanted to have discussion before this call. I still waiting the
reply from authors for the discussion related, my last message was as
below;

http://www.ietf.org/mail-archive/web/roll/current/msg07740.html

AB

---

From: Anders Brandt <[email-masked]>
Date: Thu, 21 Feb 2013 07:49:35 +0000

Abdussalam Baryun wrote:
> I still waiting the reply from authors for the discussion related, my last message was as below;
>

Responding inline:

> So I understand from your reply that you think RPL MAY NOT be
> applicabale for home and building application,

To the authors of the draft, P2P-RPL seems to be the best choice for home applications.
RPL may be  applicable as well.

> why it is best choice? this was not mentioned clearly in draft,

The purpose of an applicability document is to describe the applicability of an invention, i.e.
how one should configure host and routing protocol parameters to make the invention work
in a given setting; in this case, P2P-RPL in home and building environments.
A similar document may be created for RPL in home and building environments.

One day, when there also exists an RPL home & building applicability document, one _could_
draft an evaluation document; comparing the applicability of the two protocols.

> or describe P2P in this draft and leave others as P2MP and RPL in
> other draft if you like

Exactly.

- Anders

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 21. februar 2013 01:21
To: Michael Richardson
Cc: [email-masked]
Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-03

Hi Michael,

I wanted to have discussion before this call. I still waiting the reply from authors for the discussion related, my last message was as below;

AB

> towards use of RPL in Home and Building LLN networks, please speak by 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 10:40:21 -0500

>>>>> "Anders" == Anders Brandt <[email-masked]> writes:
    Anders> To the authors of the draft, P2P-RPL seems to be the best choice for home applications.
    Anders> RPL may be  applicable as well.

    >> why it is best choice? this was not mentioned clearly in draft,

    Anders> The purpose of an applicability document is to describe the applicability of an invention, i.e.
    Anders> how one should configure host and routing protocol parameters to make the invention work
    Anders> in a given setting; in this case, P2P-RPL in home and building environments.
    Anders> A similar document may be created for RPL in home and building environments.

    Anders> One day, when there also exists an RPL home & building applicability document, one _could_
    Anders> draft an evaluation document; comparing the applicability of
    Anders> the two protocols.

Based upon recent clarifications to P2P-RPL, it seems that it is not
possible to use P2P-RPL without prior using rooted RPL, so your document
must explain how RPL will be used in the home, in order that P2P may
then be used.

-- 
]               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: Ralph Droms <[email-masked]>
Date: Thu, 21 Feb 2013 10:43:40 -0500

On Feb 21, 2013, at 10:40 AM 2/21/13, Michael Richardson <[email-masked]> wrote:

> possible to use P2P-RPL without prior using rooted RPL,

How so?

- Ralph

> so your document

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 12:41:15 -0500

>>>>> "Ralph" == Ralph Droms <[email-masked]> writes:
    Anders> One day, when there also exists an RPL home & building
    Anders> applicability document, one _could_ draft an evaluation
    Anders> document; comparing the applicability of the two protocols.

    >> Based upon recent clarifications to P2P-RPL, it seems that it is
    >> not possible to use P2P-RPL without prior using rooted RPL,

    Ralph> How so?

1) we said that LL addressees are not permitted in the P2P's DRO.
2) we said that P2P can not have a PIO, so the P2P process can not 
   number the nodes.

Therefore, in order to use P2P RPL, there must first have been an RPL
that provided stable addresses to all nodes.  (I wrote "rooted",
intending to mean grounded, but probably that's too much)

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Feb 2013 12:45:50 -0500

> intending to mean grounded, but probably that's too much)

Why is RPL needed for address assignment?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 21 Feb 2013 13:12:13 -0500

> Why is RPL needed for address assignment?

E.g., RFC 6775 w/ DHCPv6 would provide address assignment without RPL, right?

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 13:16:14 -0500

>> Therefore, in order to use P2P RPL, there must first have been an
    >> RPL that provided stable addresses to all nodes.  (I wrote
    >> "rooted", intending to mean grounded, but probably that's too
    >> much)

    Ralph> Why is RPL needed for address assignment?

On a number of media,  I guess that it isn't.
On the media where classic RA/ND or DHCPv6 works, you don't need it.
On those media, you might not need P2P RPL either.

On some 6LowPAN mesh under systems, we have an RA/ND that does work.

As far as I can tell, none of these are the situation contemplated by
rpl-applicability-home-building.   

(And this is why I want our applicability statements to be very very
narrow in their scope, because these are questions that need to be
answered if we are going to have interoperability between muyltiple
vendors without resorting to yet another level of vendor forums)

---

From: Don Sturek <[email-masked]>
Date: Thu, 21 Feb 2013 10:25:35 -0800

Hi Michael,

Having implemented and certified 6 vendor solutions using ROLL RPL in
ZigBee IP, I doubt very seriously that this is true:

"......because these are questions that need to be
answered if we are going to have interoperability between muyltiple
vendors without resorting to yet another level of vendor forums)"

It would be best to keep the scope of the applicability statement to just
RPL P2P, not add assumptions on the use of outside RFCs/drafts and let
commercial groups complete certification by choosing configuration
parameters that address their needs.

I would doubt we are going to get to a place where an ad hoc group of
vendors are going to pick up 6LoWPAN, 6LoWPAN-ND, ROLL RPL, ROLL RPL P2P,
ROLL Mr. HOF, etc. ....  ,   implement all these and find their solutions
are all interoperable.   Just looking at all the configuration options in
these various drafts, it is unlikely for interoperability to just happen
(ignoring for a minute the security bootstrapping topic which has its own
set of complications)

Don

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Feb 2013 20:32:06 +0100

> <[email-masked]> wrote:

The P2P-RPL is route discovery, the I-D already mentions that it is an
extension of RPL, so the P2P-RPL core routing function is similar to
RPL,

I agree that the both protocols are not very similar in performance,
but in this applicability draft I think both can be used in similar
ways, or users may use them in similar ways. The draft can advise
where is the need for different way of use.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Feb 2013 20:37:57 +0100

Hi Don,

IMHO, I don't think the draft is about interoperability, nor
commercial issues. The draft is an applicability draft, it helps users
to use the protocol in such environment or applications,

AB

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 15:12:42 -0500

>>>>> "Don" == Don Sturek <[email-masked]> writes:
    Don> Having implemented and certified 6 vendor solutions using ROLL
    Don> RPL in ZigBee IP, I doubt very seriously that this is true:

    Don> "......because these are questions that need to be answered if
    Don> we are going to have interoperability between muyltiple vendors
    Don> without resorting to yet another level of vendor forums)"

    Don> It would be best to keep the scope of the applicability
    Don> statement to just RPL P2P, not add assumptions on the use of
    Don> outside RFCs/drafts and let commercial groups complete
    Don> certification by choosing configuration parameters that address
    Don> their needs.

Don, are you offering to take the Home and Building Applicability
statement to a vendor forum, and produce a document which a *building
architect* (not a member of said vendor forum) can list on a NAFTA
Article 10-compliant RFP, and which will tell an implementor (also not a
member of said vendor forum) what pieces need to be implemented in order
to interoperate? 

Because, that's the situation for all other IETF (routing) specifications.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 15:43:40 -0500

>>>>> "Abdussalam" == Abdussalam Baryun <[email-masked]> writes:
    Abdussalam> IMHO, I don't think the draft is about interoperability,
    Abdussalam> nor commercial issues. The draft is an applicability
    Abdussalam> draft, it helps users to use the protocol in such
    Abdussalam> environment or applications,

If there is anything in the document which is not essential for
interoperability then it can be removed from the document.

RFC6550 and friends (including the 6lowpan and 6man things) have given
us palette of options.  The purpose of this document is how to apply 
those options to a specific situation.  This document *MUST* explain
what options *MUST* be present in a device in order to interoperate 
in the situation.  Given the real constraints in the devices involved,
they can be manufactured with every available feature of the protocol,
nor can we assume that we can turn them all on at the same time, and
create as much state (==memory) as we want.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Feb 2013 15:59:21 -0500

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:
    Michael> *MUST* be present in a device in order to interoperate in
    Michael> the situation.  Given the real constraints in the devices
    Michael> involved, they can be manufactured with every available
    Michael> feature of the protocol, nor can we assume that we can turn
    Michael> them all on at the same time, and create as much state
    Michael> (==memory) as we want.

Forgive me for missing a key "not" in that sentence.

> Given the real constraints in the devices involved, they can **NOT** be
> manufactured with every available feature of the protocol, nor can we
> assume that we can turn ...

---

From: Don Sturek <[email-masked]>
Date: Thu, 21 Feb 2013 13:37:55 -0800

Hi Michael,

No, however, I was hoping the applicability statement would outline the
list of features of the protocol that map to solving home and building
automation issues.

I do, however, expect that the applicability statement by itself is
insufficient to build interoperable vendor solutions (plus the IETF does
not create certification programs).  So the main purpose is to provide a
document to groups like:  Z-Wave, ZigBee, CABA, ASHRAE, BACnet, etc. where
they can begin to define protocols that fit their use cases.

Don

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Feb 2013 23:51:01 +0100

I agree with situation interoperability for the doc as you state in
your message, however, I ment that the interoperability among
different implemetation of the protocol. Will you include that in
draft as well?

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Feb 2013 23:53:42 +0100

I ment not to include the interoperability among different
implemetation of the protocol in the draft proposed.

If I misunderstood please advise,

AB

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 21 Feb 2013 20:01:52 -0600 (CST)

Ralph> How so?

[MCR]

[MG]

But, P2P-RPL allows elision of the prefix. So, why can't a router (in a home LLN) participate in P2P-RPL using just link identifier as the address? Why does it need to know the prefix if it is understood that there is only one prefix and that prefix can be elided?

Mukul

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 21 Feb 2013 20:05:14 -0600 (CST)

I meant interface identifier (not link identifier).

----- Original Message -----
From: "Mukul Goyal" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: [email-masked]
Sent: Thursday, February 21, 2013 8:01:52 PM
Subject: Re: [Roll] WG call to	adopt	draft-brandt-roll-rpl-applicability-home-building-03

    Ralph> How so?

[MCR]

[MG]

Mukul

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2013 09:02:35 -0500

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> But, P2P-RPL allows elision of the prefix. So, why can't a
    Mukul> router (in a home LLN) participate in P2P-RPL using just link
    Mukul> identifier as the address? Why does it need to know the
    Mukul> prefix if it is understood that there is only one prefix and
    Mukul> that prefix can be elided?

Perhaps I don't understand this part.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Feb 2013 13:42:27 -0500

This thread is at http://www.ietf.org/mail-archive/web/roll/current/msg07754.html
had 20 messages from 7 participants.  All seemed interested in this work
and a number of substantive questions were asked about how ROLL it is to
used in the home, for instance, about how address assignment will be
done in the home/building context.

No participant express a view that the document was an inappropriate
start, or that it was out of scope for the working group.

The view is the chairs is to adopt the document.
If the authors could repost it as
draft-ietf-roll-applicability-home-building-00 on March 11, when the ID 
site reopens.