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

[Kerry Lynn <[e-mail]>]

Hi Joel,

Thanks for your review.  Comments inline...

On Thu, Dec 1, 2016 at 2:51 AM, Joel Jaeggli <[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
> 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 <[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]
>
>
>
>
>
> _______________________________________________
> OPS-DIR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>