Hi Joel, Thanks for your review. Comments inline...
On Thu, Dec 1, 2016 at 2:51 AM, Joel Jaeggli <[email protected]> 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 <[email protected]> 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 > [email protected] > > > > > > _______________________________________________ > OPS-DIR mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ops-dir > > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
