Last Call Review of draft-ietf-6lo-6lobac-06
review-ietf-6lo-6lobac-06-opsdir-lc-jethanandani-2016-12-12-00

I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-6lo-6lobac-06

Summary:

The abstract of the document says “This specification defines the frame format
for transmission of IPv6 packets and the method of forming link-local and
statelessly autoconfigured IPv6 addresses on MS/TP networks. This document is
on a standards track.

Operational Considerations
Operations. The document does talk about existence of legacy Master Slave/Token
Passing (MS/TP) along with nodes that will implement this new MS/TP frame
format. It says that if these legacy nodes are present, they will ignore the
frame format defined in this specification. It also says that co-existence with
legacy implementations is only a secondary goal. To enable this, no changes are
permitted to the MS/TP addressing modes, frame header format, control frames,
or Master Node state machine. From an operational perspective, everything that
can be configured can also be misconfigured. One way to simplify configuration,
would be by specifying reasonable defaults, including default modes and
parameters. Are there default parameters? If so, what are they? It appears from
the draft that the deployment scenario in consideration is a green field
opportunity. That only nodes that implement the new MS/TP frame format will be
able to communicate with each other. So there is no consideration outlined for
a migration path. In other words, even though co-existence with legacy
implementations is one of the goals, it is not clear how that will enable a
migration from that implementation to the new format. It is also not clear on
what the impact if any this new format may have on existing legacy
implementations. For example, for multicast frames, it states that multicast is
not supported in MS/TP. That all multicast frames are broadcasted at the MAC
layer and filtered at the IPv6 layer. What impact could this have on the nodes
that have to process these multicast packets that are broadcasted to all the
nodes? How is the node with the new MS/TP frame format expected to verified for
correct operation? Is it by actively monitoring the node, and if so what are
the elements that can be verified for correct operation. Are there events
generated as part of protocol operations that can be used to verify its
operation?

Management Considerations:
Will the nodes with this new MS/TP frame format need to be configured, or
monitored? What are some of the management operations that are needed? How are
these operations performed, e.g. locally, remotely etc. Where is this
management interface defined? Are there any new faults or health indicators
associated with this new frame formats? How are the alarms and events exposed?
Will they be pushed or do the devices have to be polled? Similarly, if one of
the nodes in the network is not behaving correctly, how would an operator be
able to determine which node it is? Are there counters maintained by each node
that can be monitored to see what each node is doing? Anything that can be used
to do a root cause analysis, and or fault isolation is helpful. Are there any
performance considerations that an operator should be aware of with this new
frame format? Certain properties of this new frame format can be useful to
monitor. For example, the number of packets received with the frame format or
the number of packets sent. Are there particular counters that can be used for
monitoring?

Accounting Considerations
Is it appropriate to collect usage information related to this new frame
format? If so, what usage information would be appropriate to collect?

A run of idnits reveals one misc. warning that might be worth looking at.

    Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.

Thanks.

Mahesh Jethanandani
mjethanandani at gmail.com