Thomas and Ulrich: 

 

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.

 

Status of Draft: Not ready for publication / Worthy of going through a editing phase  

Number of operational issues: Issues in 10+ categories

Number of Technical comment from routing: 15 technical comments (5-10 major )

Number of editorial comments: 4-5 (in attached document) 

 

Summary of Situation:

  Thomas and Ulrich – this draft is tremendous undertaking and a great step forward toward provide to others what you have gathering from your own experience.   However,  it could be so much useful if you took the approach of re-editing this to focus it toward the user.  

 

Your outline goes through a natural course: 

1)

      

Pre-deployment

2)

      

Deployment management

3)

      

What to manage and monitor.  

4)

      

What not to constraint

 

After having struggled with some management of early OLSR and ADOV deployments, I know you are bring useful comments that the NM-OPS of the OLSR-NHDP-OLSR-v2.  However, it difficult to dig out of the “travel adventure” style of writing.    Once you focus on the users side in a clear manual (not pushing a single form but informing), I think you both can put even more details from your experience in.  The structure is actually keeping you from providing more hints and technical points. 

 

This review is operational – so I am going to provide you with two variants of the review:  a) OPS directorate review, routing-technical review, and editorial nits. 

 

Thank you for letting me help improve this text. 

 

Sue 

 

=========

 

Operational 

 

1.  Has deployment been discussed?  Yes – but the discussion is clouded with a travel-log instead of clear diagrams and issues 

 

 1a) Does the document include a description of how this protocol or technology is going to be deployed and managed?  The protocol/technology is described in narrative form, but it lacks clear pictures and examples that would make this readable. 

 

1b) The OLSR/NHDP/OSLR-v2 has many tests, trials, and small deployments – so the wisdom is there from there from the deployments.  However, I would really have to work to figure out all the necessary details form specification.  80-90% of the details are there – just hard to dig out from the narrative.   OPS/NM specifications need to be easy to pull out the details.  The authors simply need to take a full rewrite to turn this into a user/manager oriented specifics + examples use – much like a text book.  

 

OLSR/NHDP/OSLR-v2 – protocol scales.  It is unclear from the details as the text is written whether it can scale or not.  The manager simply doesn’t have the right ways to test or check his approach.  The document could be re-written from the operators viewpoint to say: 

1)

      

What do I have to do pre-deployment to configure and plan my network

2)

      

What managements do I have now – standard and proprietary, and what strengths/weakness. 

3)

      

Will this tools change in the future, and what should I watch for. 

4)

      

How do I tell if my network is working – simply step by step – with clear examples, 

5)

      

What happens if underlaying L2 fluctuates in sample case (mobile radios, wifi, Ethernet) or if one part fluctuates and the other doesn’t.

6)

      

How do I track availability of the network for my customers? 

7)

      

When do I re-key?  What are the pro/cons of pre-shared key, group keys, re-keying automatically. 

8)

      

How do I tell if my MPR are not working right. 

And I’m sure Thomas and Ulrich know more

 

The real answer is proprietary tools may scale better than SNMP.  The statement proprietary NMS works well – does not really help if you are not reviewing those NMS. But enhancements with netconf/yang or I2rs or other standards work may help.  

 

1c) cannot tell if co-existent implementations other the OLSR, NHDP, OLSR-v2 with v4/v6 will work. 

 

 

   2.  Has installation and initial setup been discussed?   Pre-deployment is discussed and initial setup in general, but the general text may be to general.   The key configuration “C” is defined and discussed, but with different Layer-2 mobile radio, wifi, wired things may work poorly. It is not clear this gives the operator the help to configure.  The configuration “C” parameter is given, but the SNMP parameters (or a Yang module parameters) would be helpful reference. 

 

This is not presenting the MIB variable, and so it is unclear from this document what is normalized (other than the “c” variable) or given as a default.   The configuration is pushed by a proprietary NMS, or a SNMP.  Configuration does not appeared to be pulled from a remote server except for rekeying.  Security keys are either Pre-shared keys (manually distributed or distributed in a mechanism outside this protocol. 

 

   3.  Has the migration path been discussed?  General migration, but more details at OLSR-OSLRv2 migration or the migration from NMS/SNMP to netconf/yang or i2rs/yang might be worthwhile at this point.  No backward protocol issues are discussed in the document.  However, I thought there were some restrictions. 

 

 

   4.  Have the Requirements on other protocols and functional

       components been discussed?  Some, at a higher level.  (see comments 1 and 2) 

 

                This has been discussed in 

draft-ietf-manet-olsrv2-multitopology-05

, RFC7181, RFC6130, but

             More information. 

 

   5.  Has the impact on network operation been discussed?  Different hello rates have been discussed, but the impact of the following was not discussed: a) different computation speeds due to processors, b) self-synchronicity /(fractal waves of compute, distribute, compute), c) impact of different levels of errors in the media, d) impact of MPRs working poorly/well,  and e) good or poor interactions with Broadcast, Broadcast unknown, and multicast. 

 

6. New protocol will increase traffic and calculations as well as potential errors. This has not been discussed.  The new protocol (OLSR-v2, MT-OLSR-v2) will increase load on MANET networks. 

 

6a. It is unclear what the proposed management will do within each case.  The dialog suggest some problems – but because the authors are avoiding the pro/cons of NMS vs. SNMP vs. yang vs. I2rs or anything else – you still have problems. 

   

6b. OLSR with other protocol – will cause spots in the connectivity if the hello, calculation or others has spotty responses.  Detecting, managing and handling this performance issue – had some good initial hints.  However, I felt only because I had done this type of management of networks 10 years ago – did I know what I was getting into.   The critical thing is what happens with OSLR has these fades (normal if the L2 fades) – what happens to detect DNS, AAA and other failures. 

 

6c. No specific conformance presentation have been suggested.  General how to get topology or router problems.  ETE connectivity was not given.  One metric “C” was described.  Testing will have problems on the protocol, but I cannot say that was clearly laid out

 

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

 

       7a -   Is a standard protocol needed for interoperable management? SNMP has some, but a better interoperable protocol is need for queries (E.g. optimized flooding of queries) or of specific configuration. 

     7b) MIB model exists for configuration/ state – but it is not implemented. “C” parameter used 

 

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

       See Section 3.3.

 

       8a) Does specific management information have time utility? – Time is focused on 

 

       8b) Should the information be reported by notifications?  Polling? Event-driven polling? – while this is discussed, it not clear what recommendations for notifications or polling or event-driven are given. 

      8c) notification throttling is not discussed directly – but the problem of overloading the L2 wifi, mobile radios, and limited data is. 

     

       8d)  Is there support for saving state that could be used for root cause analysis?

         Desire –for root cause is vaguely hinted but not discussed 

 

   9.  Is configuration discussed?  Configuration pre/post deployment is discussed. Keeping things on reboot is not.  Devices can only keep so much if they are power-poor or small equipment 

       

 

A.2.  Management Considerations

 

   Do you anticipate any manageability issues with the specification?

 

   1.  Is management interoperability discussed? Centralized (NMS) is discussed, remote/local is briefly discussed, graph of topology of network is discussed as useful.  Format of management data is not discussed. 

 

   2.  Is management information discussed?  Minimum configuration is discussed. 

 

   3.  Is fault management discussed?  Methods of detect faults is discussed in a narrative. 

Liveness detection via hellos is discussed. Monitoring mechanisms are discussed, but not specific monitoring protocol other than SNMP.  TRAPs and Events from SNMP are discussed. 

 

   4.  Is configuration management discussed?  The ways of pulling protocol state are discussed.  However, it is a problem to pull too much state information.  It is not discussed how to pull significant state transaction. The authors may assume that SNMP MIB was sufficient detail on this point. 

 

   5.  Is accounting management discussed?  Account management is not discussed. 

 

   6.  Is performance management discussed?  Some performance is discussed, and some measurements.  However, there is more performance to discuss regarding the protocol and the data.  This is an area where the authors have use their wisdom on what is enough.  Unfortunately, I think the narrative form hides their wisdom here. 

 

   7.  Is security management discussed?  Security initial key and re-keying is discussed.  However, issues regarding broadcast, and Broadcast unknown traffic are not discussed.  Access control is not discussed. 

 

A.3.  Documentation

 

   Is an operational considerations and/or manageability section part of

   the document?  Yes –a whole document, but it see major issue. 

 

   Does the proposed protocol have a significant operational impact on

   the Internet?   As wifi and mobile network expand – MANET has a potential to grow outward. 

 

   Is there proof of implementation and/or operational experience?  The authors do not clearly state their background or operational experience. Only by having watched their work do I know this has operational experience. 

 

Routing issues 

 

Ok – I have noted 15 operational concerns in the attached document.  I thought it would be better to provide you with in-depth comments at the point of your document.  If you wish me to push these to an email – I will be glad to. 

 

Again – let me emphasize the work is good – it is just the form fights you.  I think if you re-adjust this like other document from either of the authors – it will be ok. 

 

Editorial nits – 3-4 comments in text 

 

 

 

 

 

 

 

Attachment:


draft-ietf-manet-olsrv2-management-snapshot-03-sue.pdf




Description:

 Adobe PDF document