Last Call Review of draft-ietf-behave-ipfix-nat-logging-06
review-ietf-behave-ipfix-nat-logging-06-opsdir-lc-romascanu-2016-02-13-00

Request Review of draft-ietf-behave-ipfix-nat-logging
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-02-12
Requested 2016-01-17
Authors Senthil Sivakumar, Reinaldo Penno
Draft last updated 2016-02-13
Completed reviews Genart Last Call review of -06 by Paul Kyzivat (diff)
Genart Telechat review of -11 by Paul Kyzivat (diff)
Secdir Last Call review of -06 by Phillip Hallam-Baker (diff)
Opsdir Last Call review of -06 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-behave-ipfix-nat-logging-06-opsdir-lc-romascanu-2016-02-13
Reviewed rev. 06 (document currently at 13)
Review result Has Nits
Review completed: 2016-02-13

Review
review-ietf-behave-ipfix-nat-logging-06-opsdir-lc-romascanu-2016-02-13






Hi,




 




I have reviewed draft-ietf-behave-ipfix-nat-logging-06 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.




 




The I-D 

This document describes the formats for logging of NAT events using IPFIX Information Elements




 




I believe the document is 'Almost Ready' for publication. The document is detailed, the content is clear and seems accurate. Better detailing some of the operational issues can improve the quality of the document. There is also a need
 for language and grammar improvement, I did not enter on details from this respect, but I trust that the RFC Editor will do his job.





 




Below please find my RFC 5706 review. 




 




1.  Has deployment been discussed?  See Section 2.1.




 




       *  Does the document include a description of how this protocol




          or technology is going to be deployed and managed?




 




       *  Is the proposed specification deployable?  If not, how could




          it be improved?




 




       *  Does the solution scale well from the operational and




          management perspective?  Does the proposed approach have any




          scaling issues that could affect usability for large-scale




          operation?




 




       *  Are there any coexistence issues?




 




There is an Applicability Section which while it really does not seem to be about Applicability (maybe it should be renamed) provides some information about deployment. Scalability may be an issue if the collectors are overloaded by a large number of events simultaneously, this is dealt with a recommendation for a throttling mechanism.




 




   2.  Has installation and initial setup been discussed?  See




       Section 2.2.




 




       *  Is the solution sufficiently configurable?




 




       *  Are configuration parameters clearly identified?




 




       *  Are configuration parameters normalized?




 




       *  Does each configuration parameter have a reasonable default




          value?




 




       *  Will configuration be pushed to a device by a configuration




          manager, or pulled by a device from a configuration server?




 




       *  How will the devices and managers find and authenticate each




          other?




 




The solution is configurable, and there are some indications in Section 9 (Management Considerations). Initial configuration and authentication between devices and collectors are not discussed, it may be useful to specify that considerations in IPFIX apply. 




 




   3.  Has the migration path been discussed?  See Section 2.3.




 




       *  Are there any backward compatibility issues?




 




N/A – the logging mechanism is new. 




 




   4.  Have the Requirements on other protocols and functional




       components been discussed?  See Section 2.4.




 




       *  What protocol operations are expected to be performed relative




          to the new protocol or technology, and what protocols and data




          models are expected to be in place or recommended to ensure




          for interoperable management?




 




Support for IPFIX and IEs is discussed. 




 




   5.  Has the impact on network operation been discussed?  See




       Section 2.5.




 




       *  Will the new protocol significantly increase traffic load on




          existing networks?




 




       *  Will the proposed management for the new protocol




          significantly increase traffic load on existing networks?




 




       *  How will the new protocol impact the behavior of other




          protocols in the network?  Will it impact performance (e.g.,




          jitter) of certain types of applications running in the same




          network?




 




       *  Does the new protocol need supporting services (e.g., DNS or




          Authentication, Authorization, and Accounting - AAA) added to




          an existing network?




 




Impact on performance and traffic level is discussed and addressed. 




 




   6.  Have suggestions for verifying correct operation been discussed?




       See Section 2.6.




 




       *  How can one test end-to-end connectivity and throughput?




 




       *  Which metrics are of interest?




 




       *  Will testing have an impact on the protocol or the network?




 




N. Probably not needed.




 




   7.  Has management interoperability been discussed?  See Section 3.1.




 




       *  Is a standard protocol needed for interoperable management?




 




       *  Is a standard information or data model needed to make




          properties comparable across devices from different vendors?




 




Yes. IPFIX and IEs are assumed.




 




   8.  Are there fault or threshold conditions that should be reported?




       See Section 3.3.




 




       *  Does specific management information have time utility?




 




       *  Should the information be reported by notifications?  Polling?




          Event-driven polling?




 




       *  Is notification throttling discussed?




 




       *  Is there support for saving state that could be used for root




          cause analysis?




 




Yes. Dealt with in detail, as this is about logging based on conditions




 




   9.  Is configuration discussed?  See Section 3.4.




 




       *  Are configuration defaults and default modes of operation




          considered?




 




       *  Is there discussion of what information should be preserved




          across reboots of the device or the management system?  Can




          devices realistically preserve this information through hard




          reboots where physical configuration might change (e.g., cards




          might be swapped while a chassis is powered down)?




 




No. This should be added. 




 




A.2.  Management Considerations




 




   Do you anticipate any manageability issues with the specification?




 




   1.  Is management interoperability discussed?  See Section 3.1.




 




       *  Will it use centralized or distributed management?




 




       *  Will it require remote and/or local management applications?




 




       *  Are textual or graphical user interfaces required?




 




       *  Is textual or binary format for management information




          preferred?




 




Binary format is used, and the justification is present in the text. Also mentioned is the need for a management application to translate into human readable format – but no details are provided. Maybe same considerations as with IPFIX apply and this should be added. 




 




   2.  Is management information discussed?  See Section 3.2.




 




       *  What is the minimal set of management (configuration, faults,




          performance monitoring) objects that need to be instrumented




          in order to manage the new protocol?




 




Yes. 




 




   3.  Is fault management discussed?  See Section 3.3.




 




       *  Is Liveness Detection and Monitoring discussed?




 




       *  Does the solution have failure modes that are difficult to




          diagnose or correct?  Are faults and alarms reported and




          logged?




 




Yes.




 




   4.  Is configuration management discussed?  See Section 3.4.




 




       *  Is protocol state information exposed to the user?  How?  Are




          significant state transitions logged?




 




 




Yes.




 




   5.  Is accounting management discussed?  See Section 3.5.




 




No. Only the Abstract mentions ‘accounting’ and this seems out of context – maybe the words ‘and for various other purposes of accounting’ should be deleted. If not I would be curious to know what these words refer to. 




 




   6.  Is performance management discussed?  See Section 3.6.




 




       *  Does the protocol have an impact on network traffic and




          network devices?  Can performance be measured?




 




       *  Is protocol performance information exposed to the user?




 




Performance is not manage, but means to avoid congestion. These seem sufficient. 




 




   7.  Is security management discussed?  See Section 3.7.




 




       *  Does the specification discuss how to manage aspects of




          security, such as access controls, managing key distribution,




          etc.




 




There is one reference to privacy which is correct. The Security Considerations section mainly points to RFC 7011. I will leave to the security review to assess if this is sufficient.





 




A few more observations: 




 




1.

      


A few terms need explanation and a short ‘Terminology and Abbreviations’ section may be useful. For example expand and explain BIB, VRF / VRFIF. Provide a reference for Carrier Grade NAT (CGN).





2.

      


In Section 5 there is a reference to a Section 4.1 which does not exist.





3.

      


The language in the IANA considerations section should be more clear about what is requested to be added to the IANA IPFIX registry. Expert review from IPFIX is required, I assume it was / will be performed.





 




I hope this helps. 




 




Regards,




 




Dan