Subject: [6lo] lobac draft review

From: peter van der Stok <[email-masked]>
Date: Wed, 17 Jun 2015 12:11:26 +0200

Hi Kerry,

Below my review of the Lobac I-D.
Most of the document reads quite easily. Some comment below show where 
my understanding of the document needed a 2nd reading of the text.
I follow the page numbering of the ietf lobac-1 document.

page 2 section 1. 2nd par. I don't see where the small address space 
comes in. 32 bits or 64 bits address spaces are not that small. May be 
you want to refer the lwig classes?
When power (energy) is not an issue, small communication delays are, as 
suggested later in the text when you refer to small baud rates. I 
suggest that you make that more explicit here.

Page 5 , top ..... different types of MS/TP COBS frames, instead of MAC 
frames (is there a MAC?)
page 5, section 1.4. Non-goals? What do you mean? No changes should be 
made to MS/TP frame headers? The phrase is not clear to me.

page 6, section 3 MS/TP link layer addresses  are different from MS/TP 
addresses? May be specify in section 1.3 that MS/TP is a link layer 
protocol.
page 6, section 3: remove: ".. or a mis-configuration condition exists". 
Does not add anything and one wonders about other mechanisms to make 
things go wrong.

page 6, section 3, par 3: , therefore all IPv6 multicast ......IPv6 
layer. That is a bit strong. IPv6 multicast may use unicast.
Suggest: IPv6 multicast protocols MAY use the link layer broadcasts.

page 6, section 3, par 4: IPv6 prefix (remove the subnet), unless I miss 
something.

page 6, section 4, par 2: The relatively .... compression. Move to the 
introduction.
page 6, section 4, par 2: An adaptation layer.....section 10. Is this 
the right place to explain the sections?

Page 6, section 5: The LoBAC adaptation layer is placed between IPv6 
network layer and MS/TP link layer? May be make explicit.

page 7, section 5.1 header: IPHC Dispatch value. (in the following text 
I become terribly confused about IPHC dispatch and Dispatch.
page 7, section 5.1 line 1: The LoBAC Dispatch value -> The IPHC 
Dispatch value begins with a "0" bit followed by a "1" bit followed by 
the Dispatch value and the header value.

page 8, section 5.1, figure: Dispatch identifies type of header 
following the dispatch (recursive definition?)
page 8, section 5.1, figure title: suggest: IPHC Dispatch structure

pahe 8, section 5.1, figure 3: Pattern includes 2 bits + Dispatch?

page 8, figure 3, title: IPHC Dispatch value Bit patterns

page 8, NALP: Dispatch value of 00xxxxxxx is impossible because only 6 
bits.

page 11 section 9: see earlier remark on multicast.

page 14 appendices: MAC-layer -> link-layer; use of MAC is not quite 
clear. Often MAC is not equal to link.

Hope this helps. My misinterpretations above may help to clarify text.

Peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: peter van der Stok <[email-masked]>
Date: Thu, 18 Jun 2015 08:59:28 +0200

Hi Kerry,

>> page 6, section 4, par 2: An adaptation layer.....section 10. Is
>> this the right place to explain the sections?
> 
> Not sure I understand.  What do you suggest?

My remark is purely editorial.
The phrase provides a handle to navigate through the sections.

And, it breaks the flow of the argument.
Usually these navigation discussions are done earlier.

You can completely ignore my remark; it does not really influence the 
meaning of the text.

Peter

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 17 Jun 2015 21:59:47 -0400

Hi Peter,

Thanks very much for your review - I appreciate your time.  I'll address
your comments
in the next revision...

On Wed, Jun 17, 2015 at 6:11 AM, peter van der Stok <[email-masked]>
wrote:

> Most of the document reads quite easily. Some comment below show where my
> understanding of the document needed a 2nd reading of the text.
> page 2 section 1. 2nd par. I don't see where the small address space comes
> in. 32 bits or 64 bits address spaces are not that small. May be you want
> to refer the lwig classes?
>

I am referring to the small MS/TP address size, which is eight bits (of
which seven are
usable).  This constrains the theoretical size of an MS/TP network (though
the practical
size is likely to be ~ 32 nodes).  6lo techniques are needed to expand this
into a 64-bit IID
for SLAAC.

> suggested later in the text when you refer to small baud rates. I suggest
> that you make that more explicit here.
>
> I refer to "low speed MS/TP networks" at the end of the Introduction, but
I mean in relation
to ethernet and wifi.  I'm not suggesting that anyone should deploy  6lobac
at < 115,200 baud.
Yes, latency is an issue even at that rate.  Every extraneous byte takes 86
uSec to transmit.
I will probably be more aggressive about suggesting compression.

> frames (is there a MAC?)

COBS is used to encode data payloads.  The frames at the top of page 5 are
MAC frames.
MS/TP is the MAC.  Unlike other data links, it is not specified by IEEE,
ITU, etc. but by BACnet.
It is used today only for BACnet network messages, but my work amending
that specification
generalized it to carry IPv6.

> I mean "off limits".  I will re-work this section to emphasize that 6lobac
frames must co-exist
with other network layer (BACnet) traffic.

> addresses? May be specify in section 1.3 that MS/TP is a link layer

I assumed people would equate "access method" with "MAC", but maybe not.
I'll
spell it out.

> Does not add anything and one wonders about other mechanisms to make things
> go wrong.
>
> I'm just trying to say that choosing the MS/TP address is out of scope for
this spec.  Maybe I
should just say that.  Frankly, if duplicate addresses are selected on
MS/TP then the token
doesn't even circulate and no data traffic is happening.

> page 6, section 3, par 3: , therefore all IPv6 multicast ......IPv6 layer.
> That is a bit strong. IPv6 multicast may use unicast.
> I see your point, but I was coming at it from a different angle.  The only
way in MS/TP to
send one packet to multiple nodes is by broadcast to all nodes on the local
link.

> OK.

> page 6, section 4, par 2: The relatively .... compression. Move to the

I have to re-work the entire document to make IPHC mandatory.  Still, I
want to leave open
the option to carry full addresses in situations where that makes sense.

> page 6, section 4, par 2: An adaptation layer.....section 10. Is this the
> right place to explain the sections?
>

> Yes, just like every other 6lo proposal.  I think this section generally
follows the wording
of 6LoPAN, etc.

> page 7, section 5.1 header: IPHC Dispatch value. (in the following text I
> become terribly confused about IPHC dispatch and Dispatch.
> page 7, section 5.1 line 1: The LoBAC Dispatch value -> The IPHC Dispatch
> value begins with a "0" bit followed by a "1" bit followed by the Dispatch
> value and the header value.
>
> page 8, section 5.1, figure: Dispatch identifies type of header following
> the dispatch (recursive definition?)
> Yes, join the club (see the recent list discussion on the RFC 6282
errata).  All of these values
will be reduced to one: IPHC.

> It is only to show developers how MS/TP can be made to look conceptually
like
ethernet, etc.  The abstract MAC interface is documented here because it
isn't
documented anywhere else.  It always seemed to me that "MAC layer" and "link
layer" are used interchangeably in IETF, but perhaps I'm mistaken.  The
irony
is that BACnet is one of the few specifications I'm familiar with that
distinguishes
the terms.

> Yes, thanks again.

Kerry