[6lo] Joel Jaeggli's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT)

Joel Jaeggli has entered the following ballot position for
draft-ietf-6lo-6lobac-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Mahesh Jethanandani <mjethanandani@gmail.com> performed the opsdir
review

it would probably be good to discuss these concerns before it gets out
the door.

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@gmail.com

_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir