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

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-6lo-6lobac-06-opsdir-lc-jethanandani-2016-12-12

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