Early Review of draft-clausen-manet-olsrv2-management-snapshot-01
review-clausen-manet-olsrv2-management-snapshot-01-opsdir-early-hares-2015-06-11-00

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