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 <[email protected] > <mailto:[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 > <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 <[email protected] > <mailto:[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] <mailto:[email protected]> > > > > > > _______________________________________________ > OPS-DIR mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ops-dir > <https://www.ietf.org/mailman/listinfo/ops-dir> > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
