Subject: [Roll] commercial-routing-reqs comments

From: Zach Shelby <[email-masked]>
Date: Thu, 24 Jul 2008 16:06:52 +0300

Jerry et. al.

First of all Jerry, welcome to the IETF. I'm sure you will be a huge 
asset to ROLL (and 6lowpan). The IETF is full of fun-loving, t-shirt 
wearing, Internet nerds, who drink plenty of beer, many of whom wish it 
was still the 70s ;-) Just be sure not to wear a suit!

Here are some comments on your draft. In general this is an awesome 
handbook for commercial building automation, we just need to trim it 
down to the essential routing issues. Maybe some of the other 
requirements and ideas could be contributed to the application and 
security drafts in 6lowpan?

I like Chapter 3, I think i gives insight into how commercial building 
automation is organized right now. Could the application areas (HVAC, 
Fire etc.) be expanded a bit more like in home-routing-reqs? One thing 
to keep in mind in this chapter is that the flexibility provided by IP 
in such a network may enable a flatter architecture than FMS - BC - ZC - 
AC - Sensors/Actuators. Could this a section here be added to consider 
how a future architecture using IP with ROLL routing might look?

Chapter 4 and 5 are not needed in the draft.

There are tons of requirements here. I would like to see only the 
routing-related ones kept. Maybe like 20 requirements max? Here is a 
list of what I think belongs:

Chapter 8:

Requirements 3, 5, 6, 9 (make a generic traffic pattern requirement 
rather than a BACnet specific one), 17

Chapter 9:

Requirements 20, 23.

Chapter 10:

Requirements 27, 30, 33, 34, 35, 36, 37, 38, 39, 47, 48, 50, 51. Note 50 
and 51 should use the oposite logic and limit those tables to a maximum 
rather than a minimum which constrains the routing algorithm to scale 
better - O(D) as in levis-protocols-survey.

Not sure what to do with Chapter 11.. boil it down to just a few 
security requirements somehow?

Hope this helps,
Zach

-- 
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd.   www.sensinode.com
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: [email-masked]
Date: Thu, 24 Jul 2008 14:56:56 -0500

Hey Zach.

Thanks for the welcome and the comments.  You can be assured my suits and 
ties will stay safely stored in the back of my closet.  If I have to work 
weekends, it will be in my weekend attire. (grubby).

I appreciate your thorough review of the document.  I will try to provide 
you some insights in this email.  Maybe we can do a deeper dive over a 
beer next week.  I believe JP told me 'rookies buy!!!'.

So as for the comments...

1.      First off, I can see that my trying to sneak some non-routing 
requirements past you didn't work!!!  (Very perceptive!!!)  I realize this 
is outside the scope of ROLL, however it isn't outside the purview of 
commercial building requirements.  If we're going to spend weekends 
developing routing algorithms to move packets that are on the network, we 
really should be confident that there are economically viable means of 
getting the packets onto the network in the first place.  We need to 
realize that we are not adding a $1000 laptop or $10000 server to the 
network.  We are talking about client devices (e.g. temperature sensors) 
in the $30 range.  If ROLL, 6LowPan and the IETF decide to ignore these 
constraints that fine, however pragmatics will enter into the equation as 
manufacturers develop these products.

2.      As for flattening the topology.  No question that can happen. 
However, as I tried to note, there are still logical groupings of 
independent devices communicating that should be segmented off from the 
rest of the network.  For instance a meeting room in an office building 
may have an occupancy sensor, lighting sensors, temp sensors, solar load 
sensors, shutter control, and air flow dampers all collaborating to 
provide the optimal environmental experience for the room inhabitants. 
These 15 devices however are nearly completely independent from the next 
meeting room down the hall.  So yes flattening the network is a great 
thing if it doesn't deleteriously affect the network bandwidth.  The 
current hierarchical topology provides this nature segmentation.  So we 
want to flatten the physical network, yet not the logical network.  I 
tried to note that run-time discovery of devices and objects are required. 
 Again, I would like to be able to scope the discovery domains.

3.      Not sure what your BACnet reference means.  BACnet is the 
interoperable application layer protocol of choice to sew the thousands of 
disparate devices installed in a building into a synergistic application 
solution as prescribed by the customer.  I hate to be so blasphemous to 
the IETF on my first email, but the customer is way more interested in a 
seamless interaction of his system components than having IP temperature 
sensors.!!!  Something I forgot to note in my document which might be 
enlightening is that the Facility Director is king of the facility domain, 
in the same regard the CTO is king of the IT domain.  These guys typically 
don't talk much and many times (currently about 50%) don't even want to be 
on the same network infrastructure.  I guess what I'm trying to say is the 
allure of IP devices might be lost to the customer when you're selling a 
facility management system.

4.      Chapter 11 was my weak attempt at trying to describe various 
security scenarios along the continuum of commercial buildings.  These 
systems have to serve buildings ranging from a single tenant multi-story 
office building, to pharmaceutical manufacturing facilities to military 
installations.  The security levels defined must then match the 
application requirements at hand.  These systems, by the way, are 
typically 'shrink-wrapped' at the development center and tailored in the 
field.  One size fits all.  They are not installed in a 'one off' fashion. 
 This means that the system must innately support the entire gamut of 
requirements.  They are then selected in the field to match the customer 
requirements.

I hope this adds a touch more insight into the needs.  Again, I realize I 
overshot the mark, but thought it best to capture the entire picture and 
whinny it down then to provide a brief outline that might miss the salient 
points.

Hope to meet you in Dublin,

Jerry

Zach Shelby <[email-masked]> 
Sent by: [email-masked]
07/24/2008 08:07 AM

To
[email-masked]
cc

Subject
[Roll] commercial-routing-reqs comments

Jerry et. al.

Chapter 8:

Chapter 9:

Requirements 20, 23.

Chapter 10:

Hope this helps,
Zach

---

From: Zach Shelby <[email-masked]>
Date: Fri, 25 Jul 2008 10:01:09 +0300

Hi,

[email-masked] wrote:

> requirements past you didn't work!!!  (Very perceptive!!!)  I realize 
> this is outside the scope of ROLL, however it isn't outside the purview 
> of commercial building requirements.  If we're going to spend weekends 
> developing routing algorithms to move packets that are on the network, 
> we really should be confident that there are economically viable means 
> of getting the packets onto the network in the first place.  We need to 
> constraints that fine, however pragmatics will enter into the equation 
> as manufacturers develop these products.

I also like the approach: an overall view. I think by boiling it down to 
the bare minimum routing requirements, you can still have the 
justification behind each requirement as in the home automation ID. So 
for example: The routing solution MUST be implementable in a cheap 8-bit 
microcontroller with 4 kB or RAM and 32 kB of flash. You already had one 
like that. Now just explain before the requirement why it is there (the 
economics and current technical SOTA). So organizing each requirement 
into its own subsection rather than in a (PDF) table would enable you to 
do that.

>  These 15 devices however are nearly completely independent from the 
> next meeting room down the hall.  So yes flattening the network is a 
> great thing if it doesn't deleteriously affect the network bandwidth. 
>  The current hierarchical topology provides this nature segmentation. 
>  So we want to flatten the physical network, yet not the logical 
> network.  I tried to note that run-time discovery of devices and objects 
> are required.  Again, I would like to be able to scope the discovery 
> domains.

Logical topology can definitely stay, and with a flat physical topology 
(server, routers, nodes) you can also completely partition your network 
using different channels, PAN IDs and even encryption codes. The network 
can also be physically partitioned from the IT network. Ethernet 
switching can partition your areas. Scoping the routing domains is a 
very good requirement.

> interoperable application layer protocol of choice to sew the thousands 
> of disparate devices installed in a building into a synergistic 
> application solution as prescribed by the customer.  I hate to be so 
> blasphemous to the IETF on my first email, but the customer is way more 
> interested in a seamless interaction of his system components than 
> having IP temperature sensors.!!!  Something I forgot to note in my 
> document which might be enlightening is that the Facility Director is 
> king of the facility domain, in the same regard the CTO is king of the 
> IT domain.  These guys typically don't talk much and many times 
> (currently about 50%) don't even want to be on the same network 
> infrastructure.  I guess what I'm trying to say is the allure of IP 
> devices might be lost to the customer when you're selling a facility 
> management system.

As BACnet is an application layer protocol, what that boils down to is 
ROLL routing needs to support its traffic pattern, along with any other 
patterns envisioned in the network. So I recommend making a traffic 
pattern requirement which covers BACnet. Again, you can have the 
justification before the requirement regarding BACnet.

> field.  One size fits all.  They are not installed in a 'one off' 
> fashion.  This means that the system must innately support the entire 
> gamut of requirements.  They are then selected in the field to match the 
> customer requirements.

> I hope this adds a touch more insight into the needs.  Again, I realize 
> I overshot the mark, but thought it best to capture the entire picture 
> and whinny it down then to provide a brief outline that might miss the 
> salient points.

Your approach is clear, and it doesn't hurt. Next step is to squeeze out 
the essentials without loosing the important justifications behind each 
requirement. Try out the subsection approach (which also lets you make a 
txt version!).

- Zach

> *Zach Shelby <[email-masked]>*