Subject: [OPSAWG] Help with a MANET management draft please

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Feb 2014 23:40:29 -0000

Hi OPSAWG,

The MANET working group develops protocols for mobile and ad-hoc networks (some
of which are less mobile or less ad hoc than others).

After discussion with the IESG and specifically the OPS ADs, the WG has agreed
to try to put together some thoughts on management of these networks.

It's early days and the authors are not experienced in these ideas (so be
gentle!) but it seems important at this stage to see whether the work is going
in the right direction.

Could any of you find time to review and comment (on this list, on the MANET
list, direct to the authors, channelled through me)? All contributions will be
gratefully received.

The document is:
http://datatracker.ietf.org/doc/draft-clausen-manet-olsrv2-management-snapshot/

Thanks,
Adrian

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 26 Feb 2014 21:59:35 -0500

Hi,

The document claims to be a snapshot of how MANET networks are being managed
now.
I'm not quite sure what types of comments you want on the document, since
the authors have researched and are presumably knowledgeable about current
management practices for MANETs.
Are you looking for comments from operators of other MANET networks to
expand the documentation of existing management techniques?
Or are you looking for suggestions of ways that MANETs *could* be managed
differently?

RFC5706 may contain ideas regarding management and monitoring of protocols,
that could apply for eliciting additional input from operators about current
practices, or for eliciting suggestions of management approaches that might
apply to further work on management techniques that could be applied to
MANETs.

Given the "startup" nature of much of the MANET config, it definitely looks
like Netconf/YANG might be a better choice than RW MIB modules for
configuration (I suggest attending the OPSAWG meeting in London, since that
is already a planned topic of conversation).
Section 3 appears to be mostly about IP configuration and interface
configuration; there are netmod YANG modules for this purpose. 

Using standardized management would likely improve interoperability, if
interoperability is important. It may not seem that important for deployment
for internal management, but having a consistent management interface for an
NMS to use to debug internal deployments could be awfully helpful to
operators.

David Harrington
[email-masked]
+1-603-828-1401
> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Adrian
> Farrel
> Sent: Wednesday, February 26, 2014 6:40 PM
> To: [email-masked]
> Cc: [email-masked]; draft-clausen-manet-olsrv2-management-
> [email-masked]
> Subject: [OPSAWG] Help with a MANET management draft please
> 
> Hi OPSAWG,
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Feb 2014 08:07:00 +0100

On Wed, Feb 26, 2014 at 11:40:29PM +0000, Adrian Farrel wrote:

> Could any of you find time to review and comment (on this list, on
> the MANET list, direct to the authors, channelled through me)? All
> contributions will be gratefully received.

Out of curiosity, I would like to understand what the background
behind these statements is:

   "protocols such as SNMP (or possibly other, less "chatty",
    protocols)."

   In some deployments, the NMS communicates with individual routers by
   way of SNMP - and, more commonly, by way of "proprietary" simpler,
   less verbose and (often) less secure protocols, and over UDP.

Any pointers to such proprietary protocols? I am just wondering what
the network management communication patterns are that take place in
MANETs.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 27 Feb 2014 14:29:15 +0100

Hello David,

Thank you for your remarks, and for engaging with & educating us here. It's really appreciated. Comments below....

> The document claims to be a snapshot of how MANET networks are being managed

More specifically, how MANETs running OLSR(v1 or v2) as routing protocol are being managed.

> management practices for MANETs.

We actually do not claim to document what is done in MANETs in general - there are routing protocols other than OLSR(v1 or v2) out there, albeit less widely deployed, which are operating with a very different architecture, and which the authors of this document suspect would have (in some cases, significantly) different management practices.

> Or are you looking for suggestions of ways that MANETs *could* be managed

Good question ;)

This document came to be as the OPS ADs asked us to "document how you're actually currently managing MANETs", as part of their processing of MIBs for the different protocols (notably OLSRv2 and NHDP - which is a constituent, but independent, protocol to OLSRv2). One of the triggering comments was from Benoit Claise (can't find a public link to quote him, so it may have been in a conversation), another was Ron Bonica's (which is in the tracker for what became RFC6779 here: https://datatracker.ietf.org/doc/rfc6779/ballot/):

	This document fails to provide use cases. Because it doesn't provide use cases,
	it is not clear that any/all of its objects are useful.

	While this comment might be leveled concerning regarding MIB, it is
	particularly applicable in this case because we have so little operational
	experience with ad hoc networks. Will the ad hoc network include a NOC? What
	policy will that NOC attempt to enforce? What information/control will the NOC
	need to enforce that policy.
So, we set forth to document what we know about how the ad hoc networks that we know are actually being managed, asking those building/operating such networks, and trying to generalise from that. There are actually quite a few operators of "highly managed ad hoc networks" out there - sadly, those networks are typically "tactical networks" and so it is rather difficult to get their operators to be particularly forthcoming about specifics...

Therefore, in part, the question that we would like to ask from the OPS experts is: does this document make any sense to you? Is what's in there of any (educational, or otherwise) value? Anything that you feel is missing, or where more information would be helpful? With reference to Ron's comment quoted above, does this document provide necessary context for understanding what may come out of the MANET wg in an operational frame?

Now, if opsawg has a bunch of stealthy MANET operators subscribed, whom we do not know about already, then we'd *love* to make friends get comments and feedback as to how they're doing things. So please, anyone with MANET experience do come forward....

And yes, any suggestions as to "how can we do better/differently?" are always highly welcome. We're just routing guys, who recognise the need for network management - but, who also recognise that we just are routing guys and that we better be attentive to domain-expert advice.

> apply to further work on management techniques that could be applied to

Now, THAT was an RFC that I wasn't aware of, but which seems (after a quick skim-through) to be hugely interesting. I'll definitely give that a careful read-through on my way to London. Thank you for that pointer. 

> is already a planned topic of conversation).

And again, that was a very good pointer, and I'll make sure to be there. Thanks.

Now, there's something to be said for the way in which we designed OLSRv2: essentially, ad-hoc networks are intended to be very "autonomous", that's how they often are deployed. 

There's very little that *requires* global agreement (off the top of my head, three things: the value of C, cryptographic material, and interface address configuration) for correct operation of a network. The protocol is designed to be accommodating to heterogeneity of pretty much everything else. Of course, for *efficient* operation, one will want if not global agreement, then at least a way of affecting other parameters in the routers - and this over time, as the network evolves (e.g., devices start to move about, or settle down, or the environment changes, etc.).

So yes, while all the "required config" probably is startup config, there is a need for also being able to configure (and, certainly, monitor) the network while in continued operation.

> configuration; there are netmod YANG modules for this purpose. 

I have actually only passing familiarity with YANG, so I will have to go look at that in more details, also, in preparation of London.

> NMS to use to debug internal deployments could be awfully helpful to

Interoperability is hugely important (otherwise, we'd not bother going through the hoops, expenses, and frustrations, of standardising).

The back-story (which we kinda allude to, but which really is not worth telling in detail in the document, since I expect that it's quite classic) is, that in the past we had no standardised ways of a NMS interacting with an OLSR instance. Consequently, we saw each implementation of OLSR come with its own (if any, that is) more or less wicked "interface" (examples include using Java RMI, Sun RPC, a TCP socket with 'untraditional' textual commands, ...) and exposing/expecting data in more or less wicked formats and amounts, and towards "custom" NMSes, visualisation tools, etc. Not throwing any stones here - I believe that my initial implementation of a "management interface" to an OLSR instance takes the price of being "the most wicked of the bunch" - just observing how it was.

Operationally, that's not good - and, even for our interop events, that has occasionally been a difficulty - or, at least, it would have simplified life greatly had we all had identical interfaces and information exposure. That's what motivated us to dig in and develop MIB modules and the likes.

Again, thanks for your interest and guidance, it is hugely appreciated, and - I think I can speak for both the authors - we're eager to learn from all y'all.

Best,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 27 Feb 2014 15:17:26 +0100

Dear Juergen,

> the network management communication patterns are that take place in

I would love to be able to provide a pointer, but that's unfortunately the nature of "proprietary": I can't. I actually do not believe that there's any "de-facto standard" or "commonly used proprietary protocol" out there, more a matter of each implementer of OLSR (v1 and v2, both) set out realising the need for interacting with a running OLSR instance, and coming up with his/her own approach depending on ad-hoc needs.  Heck, I don't think I've actually seen a written documentation of these "proprietary" protocols, except for their code....

Initially, what we saw was in the numerous OLSR interop's we've held, where we saw a remarkable number of visualisation tools, for example, depicting the evolution of the network topology (caveat: routers in a MANET are likely to move about), or tools permitting to temporarily provoke a "failure-like event" in a router to be able to observe how the surrounding network behaves - with instrumenting routers to record and reflect their behaviours. Tools, that is, communicating with the protocol instance in whatever way the implementer saw fit to build, since there was no commonly agreed-upon, documented, way.

But, you do make a good point which is - I think - that it might be helpful to document what the (management) communications patterns may look like in an operating (post-startup) network. I think that that probably is a good idea, so we'll definitely see about that in a coming revision of the document, thank you for that suggestion!

I'll throw a few thoughts - without claiming to be exhaustive - out below as what I see in the networks that I know of and know very well,  that happens "often" - note, this is just in what *I* see, not what *everybody* sees or what everybody may wish to see happen:

	a)	Inquire the state (complete topology graph, link states, local links even if not part of topology graph) of a router
		Often, this is getting "up to a few KB worth of data" back
		It's not a very common operation.

	b)	Inquire the history/statistics of a router
		This is typically something tiny, like "how many local link changes have you seen within the past n minutes/seconds/hours"
		This may be very rare, or it may be several times per minute per router for a while: if my NMS is trying to "tune" message 
		intervals and timers, it may be a case of "doing this to a group of topologically close routers" - until, that is, the NMS decides
		that it's happy with what it sees and will ease up

	c)	Change the configuration of a router
		Other than in the above case (tuning) this really happens only when somehow I get a new uplink to an external network,
		and I either need to throw a new gateway into the network, and/or I need to get a new prefix out to the routers.

	d)	Visualising the network as a router sees it.
		Note that as in a MANET, routers do move about, this may mean that the topology changes frequently. In a naive way, this would
		essentially be the NMS setting up a connection to the router in question, and "getting a copy of all routing protocol
		control messages" to construct its own topology graph as would have done that router. Typically, it consists of the router sending a 
		notification to the NMS when a topological change happens, i.e., when either of its information bases change. Even better, it
		consists of these notifications being "filtered" to only send for those changes that actually impact the usable topology.

	e)	Rekeying - we do not actually have a (standard) mechanism for AKM, and I maintain that it probably is not possible to come
		up with a single such that will satisfy the requirements for all the different deployments, but it's still something that we do play with.
		I'm actually doing that as part of a management operation and schlepping it around as I would any configuration parameter
		(not saying that it's the right thing to do, though, just what I'm playing with). The particularity of this is, that it often is a "broadcast
		configuration operation" where you want to get new material to everybody, and not just a single device.

Some of the proprietary stuff that has been done (and which I have done) in the past, can be explained easily by the above, and by the fact that in OLSR (v1 and v2) we have really efficient flooding operations in place. This can (and has) be used to do e) much much more efficiently (& reliably) than a bunch of unicasts. For b), too, in case we want to configure a "group of topologically close routers": unicast to one of them (topologically as central as possible) and then use scope-limited optimized flooding to reach the surrounding routers. As for d), the opportunities are endless for thinking up ways to do that...

Moving towards standardized data representations, such as the MIBs, as well as some of the interesting developments by Bob Cole (REPORT-MIB - http://tools.ietf.org/html/draft-ietf-manet-report-mib  - yes, it is expired, but we need to revive that, I think) are steps that we're trying to take to exit the world of "ad-hoc" management solutions.
 
Not sure if that's a useful answer to your question? I am sorry that I can't point to some neatly written up whitepaper, which clearly would have been a better answer.

Either way, your question is good and it might make sense to mull a bit on that and try to capture a more complete answer to it than what I provided in the above in the document?

Tschüß,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 27 Feb 2014 15:18:23 +0100

(Apologies for the double-posting to some of you; I realized that I had not subscribed to opsawg so I am resending)

Hello David,

Good question ;)

Best,

Thomas

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 27 Feb 2014 15:45:22 +0100

Hi,

this is useful input, in particular the description of the various
things NMSes in a MANET context like to do. Concerning the text in the
I-D, I would probably stay away from classifying other protocols as
"simpler" or "less chatty", in particular if they are all kept secret
(note that proprietary does not necessarily imply that a protocol is
secret - there are many proprietary protocols that are documented).

/js

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 27 Feb 2014 15:52:31 +0100

Dear Juergen,

On 27 Feb 2014, at 15:45, Juergen Schoenwaelder <[email-masked]> wrote:

> things NMSes in a MANET context like to do.

OK, we'll try to think of ways of reflecting that.

> Concerning the text in the
> "simpler" or "less chatty", 

OK, that's perhaps too colloquial, we'll pay attention to that.

> in particular if they are all kept secret

Agree. I note that "kept secret" is not really due to "don't want to share" but rather due to "nobody seemed to have bothered to document it".

Either way, thank you so much for your feedback.

Question to the OPSAWG chairs: 

	We'll probably spin a new revision within the IETF week. 
	As we're not regulars in OPSAWG we thought we'd ask permission rather than forgiveness, 
	as to how you run usually: shall we forward the announce to this list (and to MANET, of course),
	or is this noise you'd rather be without?

A bientot,

Thomas

---

From: Melinda Shore <[email-masked]>
Date: Fri, 28 Feb 2014 03:04:27 -0800

On 02/27/2014 06:52 AM, Thomas Clausen wrote:
> We'll probably spin a new revision within the IETF week. As we're not
> regulars in OPSAWG we thought we'd ask permission rather than
> forgiveness, as to how you run usually: shall we forward the announce
> to this list (and to MANET, of course), or is this noise you'd rather
> be without?

Speaking strictly for myself, as long as it's topical to opsawg
and it's productive discussion, it's signal, not noise, and I'm
good with it.

Melinda