Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
draft-ietf-ipfix-protocol-rfc5101bis-10

The opsdir review of the latest draft is extensive...

Thanks sue for doing it


Appendix A.  Operations and Management Review Checklist
Well written.  Only a few technical questions/considerations:

a) What happens when different observation points of an observation domain have different levels of timing (nano-second vs. second)? Does the second timing data get put in a different queue than nano-second data? 
b) Is there key rotation with DLTS using 2-way/3-way/ or 4-way handshake?
c) What happens if the transports switch rapidly (UDP to TCP to STCP and rotate (UDP to TCP to UDP)? Are these denial of service attacks? 

Editorial: 
page 8 Flow key – could use an example. 
           
page 25 – 4.1 end of sentence change from: ; see (IPFIX-IANA] for their definitions”  to: defined in [IPFIX-IANA]:
p. 36 Section 8.0 last paragraph – could use an example.
p. 50 section 11.1 – Last paragraph the offset by commas that starts “,i.e., a true and ends (and/or TCP), this” is confusing.  Please reword 

p. 51  11.2 para. 1 “[RFC5246] and [5347],” to [RFC5246] and [5347]” otherwise sentence does not have strong sense of while.’

p. 52  section 11.4, para. 2 change “or scope information, a large amount” to “or scope information, or a large amount” 

p. 53 “section 11.4 para 5 change “a Collecting process; if provided, the” to “a Collecting process; and if provided, the”

 
          
A.1.  Operational Considerations
1. Has deployment been discussed: 
a. Does the document include a description of how this protocol or technology is going to be deployed and managed?

Actual Deployments are not discussed in depth. Management and operational conditions for multiple transport, DOS, and scaling issues are discussed. 


 
b. Is the proposed specification deployable?  If not, how could it be improved? 

This solution has description of scaling and management concerns. Any solution that monitors at per interface or more refined will run into issues with scaling. 

Improving the deployment would take another approach to the problem of store/forward or trigger updates. However, this document is about updating an existing process. For this approach, the authors have done a good job at working through possible refinements. If IETF wants 

c. 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?

Most issues have been mentioned. A few things that should be considered: 1) fluctuations between times and queuing for different observation points or different data and 2) fluctuations if the transport failures cause the implementation to rate between transports. 

d. Are there any coexistence issues? 

Coexistence issues in transports or IDs are clearly stated. The document specifies it is interoperable with previous version of protocol [RFC101]

   2.  Has installation and initial setup been discussed?   
* Is the solution sufficiently configurable? Are configuration parameters clearly defined? Are configuration parameters normalized?  Does the configuration have a reasonable default value? 

Solution appears to be configurable, defined, and normalized, with default values, but that configuration is dealt with elsewhere, and it is not the topic of this draft.  
o Configuration: RFC6615 (MIB), RFC627 (NETCONF), 
o Implementation guidelines [RFC5153], testing [RFC5471] 
 
* Will configuration be pushed to a device by a configuration
          manager, or pulled by a device from a configuration server?

The MIB and NETCONF options allow either configuration manager to push the information. It is not clear if the IPFix device, exporter, collecting process or collector can pull global configuration.  Since the TLVs in a sense self-configure, this is in a sense pulling the configuration.   


* How will the devices and managers find and authenticate each other? 
    
The devices and managers appear to find each other in an a priori manner via configuration. Group functions exist for observation point to observation domain, collecting processes to collecting hosts, and exporter processes to exporters.  However, it does not appear that these grouping processes self-detect. The data within these monitoring flows self-detect but the identity does not appear to find each outside of configuration. If I have missed this, you might consider that I re-read RFC3917, RFC5470, RFC6615(MIB), RFC6728(netconf), RFC6727 (MIB), and RFC5102bis (MIB).

RFC6728 indicates that the following trees/substrees contain sensitive information and write operations can have an impact:
a) /ipfix/Observation 
b) ipfix/cache
c) ipfix/exportingProcess
d) ipfix/collectingProcess

Due to these statements and section 11 that states an IPFIX collecting process (or processes) must prevent collection from an unauthorized Exporting Process or the export of data to an unauthorized collected process.    

This implies that the “discover” each method would need additional security mechanisms. 

3. Has the migration path been discussed?  Are there any backward compatibility issues?

The document states the protocol is interoperable with RFC5101. The self-defining mechanism seems to provide this. 

4. Have the Requirements on other protocols and functional
       components been discussed? 

In quick summary – Yes. The smorgasbord of options and parameters has been described, 

The impact of the ipfix process on the underlying carrying protocols (UDP, TCP, STCP), the device/node in the being sampled, the exporters impact, the collectors impact have been carefully specified. New protocol functions are either specified or reference by RFC. The NETCONF/YANG or MIB models are given as Management. 



   5.  Has the impact on network operation been discussed?   

	This document does discuss:
o how ipfix increases traffic load and choice the network operator has in managing, 
o how ipfix will increase traffic load on existing networks and how to manage it,
o how the protocol use impacts exporting processes and exporter, collecting processes and collector, 
o how the device impacts the behaviors of other protocols by sending traffic load and how to manage it,
o how the device requires security.

Since the IDs are self-defining, it does not appear that the DNS service has a critical impact on these. The DNS-ID is mutual authentication process which requires the DNS-ID as specified in section 6.4 of RFC6125. The security requires that the Common-Name (CN-IDs) not be placed in identifiers.   

6. Have suggestions for verifying correct operation been discussed?

The Testing operations exists RFC5471 and RFC5153. Since the protocols are interoperable only the differences need to be examine. 

The only differences that section 1.1 notes that impact implementation and testing are the timer encodings link to epochs or rollover, and template management relaxation. 

While section 5 and section 8 cover this information to one skilled in the art, it may be worthwhile to update both RFC5471 and RFC5153 with the appropriate information. 


7. Has management interoperability been discusses? 

In short, yes.  This protocol is a model protocol for information models, data models, and choices across platforms. 

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

This management information has timing implications and ties to a timing utility.  The information is reporting on a constant stream. There does not appear to be any notifications defined in MIBs. This is not(!!) a polling application for event-drive. 
Overload alarms/notifications might be useful, except they might further provide a DOS attack.  

State saving, caching, template definition keeping are described carefully and thoroughly.





   9.  Is configuration discussed?  See Section 3.4.

       *  Are configuration defaults and default modes of operation
          considered? Defaults are described in MIB. Default process 
          in this document. The discussion seems sufficient. 

       *  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)?

Topics regarding reboot are not covered in this document. The word restart is only used regarding restarting the UDP. The word reboot is not used. 

A.2.  Management Considerations


   Do you anticipate any manageability issues with the specification?

1. Is management interoperability discussed?   

The management may be centralized or distribution or a combination. The collector processes are considered to be remote from the exporting processes. However, the exportation/collection can be in the same virtual environment. 

No textual or graphical user interfaces are required. The format of the protocol utilizes TLVs. The internal data may be considered “sensitive” and may be encrypted due to its sensitivity whether it is textual or binary. 

   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?

	This is not discussed in this document.  
	

   3.  Is fault management discussed?  See Section 3.3.

* Is Liveness Detection and Monitoring discussed? For the liveness indications for the transport protocols (STCP, UDP, TCP) and the exterior needs for liveness/monitoring neded when UDP is issued.   

* Does the solution have failure modes that are difficult to diagnose or correct? Faults and alarms are logged. However, if errors reoccur the mere keeping of the faults may overload. An overload mechanisms on exporting was discussed in 4.2 (Metering process)and 4.3 exporting process.

4. Is configuration management discussed? 

* Is protocol state information exposed to the user?  MIBS and YANG/netconf model expose state and tables to user. 

* Significant failures of transport, stopping metering (4.2), stopping export (4.3) are discussed. 
          


5. Is accounting management discussed?  
Only in terms of the link between performance data and accounting.

   6.  Is performance management discussed?  See Section 3.6.

* Protocol impacts performance of nodes (exporter load, collector load) and the network data passage (due to amount of data sent. This is discussed. 
* Protocol performance information is exposed when the information is dropped (metering 4.2, exporting, 4.3).  The performance issues are discussed, but the performance metrics 

       *  Is protocol performance information exposed to the user?

7. Is security management discussed?  
Security features required to support IPFIX are discussed in section 11. This section discussed the security features the protocol requires, the applicability of TLS and DTLS, the usage of a unique secure channel, the mutual authentication, protection against DOS, and security issues with UDP only, requirement to log IPFIX attack, how to secure the collector, and the need to secure the data collected.

A.3.  Documentation
* Is an operational considerations and/or manageability section part of the document?  Security section is. The document weaves the operational considerations and management within the whole document since this is a protocol that impacts monitoring. The actual management and monitoring of the protocol doing the flow monitoring is part of this discussion. The configuration and data models are (thankfully) elsewhere described. 

* Does the proposed protocol have a significant operational impact on the Internet?  Yes, yes, and yes!

* Is there proof of implementation and/or operational experience? Significant lessons learned are causing the update.  No specific implementation or operational experience is noted.