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

[joel jaeggli <[e-mail]>]

Thanks, sounds like you have it under control.

On 2/28/17 2:55 PM, Kerry Lynn wrote:
> Hi Joel,
>
> Thanks for your review.  Comments inline...
>
> On Thu, Dec 1, 2016 at 2:51 AM, Joel Jaeggli <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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
>     <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/
>     <https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/>
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     Mahesh Jethanandani <[e-mail]
>     <mailto:[e-mail]>> 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.
>
>
> <kel>
> Section 1.4 has been reworked to promote the importance of co-existence
> (it allows MS/TP networks to be incrementally upgraded to IPv6).  The
> constraints on making any changes to the L2 frame header are necessary
> to meet the co-existence goal.
> </kel>
>  
>
>         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?
>
>
> <kel>
> I expanded Section 2 to include constants and configuration parameters
> (with default values for the latter) that are required for implementation.
> The mechanism for changing default values is outside the scope of this
> I-D.
> </kel>
>  
>
>         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.
>
>
> <kel>
> This is similar to the way Ethernet and 802.3 frames co-exist on the
> same media without interoperation.  Prior to this work (and I include
> [Addendum_an]), MS/TP could only be used by the BACnet network
> layer.  As BACnet eventually migrates to IPv6 as the transport, it may
> be that a mix of old and new BACnet MS/TP devices exist on the same
> link, in which case they will have to communicate with each other through
> a router or application layer gateway. But I think this discussion is well
> outside the scope of the I-D.
>
> What 6LoBAC enables is a true green field opportunity; for constrained
> IPv6 devices running arbitrary applications to use a wired datalink that
> can reliably cover distances up to 1Km at relatively low cost.
> </kel>
>  
>
>         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?
>
>
> <kel>
> As stated in Section 1, "If present on the link, legacy MS/TP
> implementations
> (including any slave nodes) will ignore the frame format defined in this
> specification."  This is handled by the MS/TP Receive Frame state machine,
> which includes a SKIP_DATA state.
> </kel>
>
>         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?
>
> <kel>
> My understanding is that management of 6lo hosts is being considered by
> another WG.  Definition of a MIB, etc. is outside the scope of this
> I-D.  I
> think this applies to most of the questions below...
> </kel> 
>
>
>     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?
>
>
> <kel>
> [BACnet] Clause 9 defines Test_Request and Test_Response frame types,
> which can be used for local loopback tests at L2.
> </kel>
>  
>
>     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.
>
> Done.
>
> Thanks again, Kerry
>  
>
>     Thanks.
>
>     Mahesh Jethanandani
>     [e-mail] <mailto:[e-mail]>
>
>
>
>
>
>     _______________________________________________
>     OPS-DIR mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ops-dir
>     <https://www.ietf.org/mailman/listinfo/ops-dir>
>
>
>