Subject: [OPSAWG] FW: New Version Notification for draft-ersue-constrained-mgmt-02.txt

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 17 Oct 2012 10:17:48 +0200

Hi All,

we submitted an update for the constrained-mgmt draft on the "Management
of Networks with Constrained Devices: Use Cases and Requirements". The
draft hopefully addresses most of the issues we discussed in the last
meeting. 

I think it is already time to split the draft into three; e.g. problem
statement, use cases and requirements. But this can be done after
getting your feedback before and during IETF 85.

I would highly appreciate your comments and any kind of discussion on
the draft content especially on the requirements section. Thank you.

Cheers, 
Mehmet 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for
draft-ersue-constrained-mgmt-02.txt

A new version of I-D, draft-ersue-constrained-mgmt-02.txt
has been successfully submitted by Mehmet Ersue and posted to the
IETF repository.

Filename:	 draft-ersue-constrained-mgmt
Revision:	 02
Title:		 Management of Networks with Constrained Devices: Use
Cases and Requirements
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 78
URL:
http://www.ietf.org/internet-drafts/draft-ersue-constrained-mgmt-02.txt
Status:
http://datatracker.ietf.org/doc/draft-ersue-constrained-mgmt
Htmlized:
http://tools.ietf.org/html/draft-ersue-constrained-mgmt-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ersue-constrained-mgmt-02

Abstract:
   This document raises the questions on and discusses the use cases and
   requirements for the management of networks with constrained devices.

The IETF Secretariat

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 20 Oct 2012 08:45:59 +0200

On Sat, Oct 20, 2012 at 06:33:20AM +0200, Carsten Bormann wrote:
> 
> The classes have been defined the way they are because they mirror a
> step function in capabilities.
> (They also haven been defined on approximate orders of magnitude
> because you can't nail these steps down to a kilobyte.)
> 
> What do you think is missing?
> 

Hijacking the thread, I do actually think we should have some more
classes. For coman, in the use cases also devices included that have
the memory to run embedded linux. I think we would do well to cover
devices such xports or even raspberrys. Yes, those boxes probably are
not the target of lwig but they will exist in the internet of things
and some of them will exhibit properties (like mostly sleeping) that
coman I think needs to address.

/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: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 22 Oct 2012 12:55:23 +0200

Hi Ulrich,

see my comments below.

Cheers, 
Mehmet 

From: ext Ulrich Herberg [mailto:[email-masked]] 
Sent: Saturday, October 20, 2012 1:46 AM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: Re: [coman] FW: New Version Notification for
draft-ersue-constrained-mgmt-02.txt

Hi Mehmet,

thank you for updating the draft. There is a huge amount of great work
in it, and I think this will provide a great basis for further
discussions. Indeed, splitting up the document would be required at some
point.

Some high-level comments:

  - Section 1.2 (Terminology): The definition of MANET and Intermediate
entity (in COAP) come a bit surprising, since there has been no
discussion before. Also, it seems inconsistent to define MANET, but not
all the other use cases, such as AMI.

[ME]: The terminology section is incomplete and should be extended e.g.
with AMI.

  - Section 1.3 (Constrained Device Classes): I know that this
definition is taken from Lwig, but I doubt that it is of much use. The
absolute values will change. While now there are still many C0 devices
out, in five years, they will not exist (or rather, the number 10KB
would need to be replaced by a larger number). I think I would prefer a
classification based on the capabilities (e.g. can support full IP
stack, or not)

[ME]: The definition was actually first introduced by Carsten in the
Smart Object workshop before IETF 80 in Prague. This is an important
point. See my other mail.

  - Section 1.4 (constrained networks): I don't think this is a very
consistent classification of networks. First, CN0 seems to be the least
constrained network, whereas C0 devices are the most constrained. I
would suggest the remain the same ordering (0 the most constrained up to
a positive number).

[ME]: The "0" in CN0 and C0 don't relate to each other. The
constrainedness of a network is mostly dependent on the wireless
technology used. I found it more useful to differentiate the type of the
network, where the wireless technology can be manifold.

More importantly, there is a mixture with constrained devices in this
definition. Since we talk about the network only, we should only talk
about topology, lossy links, multi-hop, mobility etc. but not
constrained devices. 

[ME]: I agree, we should talk here on devices only.

I don't understand why MANETs are not supported. Several of the use
cases, such as the military use case, community networks and AMI are
multi-hop networks with dynamic topology and lossy links. That is what I
call a MANET. 

[ME]: The agreement in our last f2f meeting was that we want to include
the MANET use case to highlight what it is but exclude from the
requirements discussion. The reason is that MANETs can be based on very
distinct scenarios and have specifics which are unique compared to other
networks. The essential point is that MANETs are infrastructureless
(i.e. without any hierarchy), which seems to be not the case in other
network types the draft describes and makes network management
essentially different.

Even the definition of CN1 is, IMO, entirely a MANET; you even mention
Mesh networks, which are nothing else than MANETs (only difference is
that routers are usually non-mobile; nevertheless, the topology is still
dynamic because of fluctuating links.). 

[ME]: There might be similarities between a MANET and a Mesh network,
however they are not the same thing. I have to admit we don't conceive
sufficiently the special MANET use cases for frequent movement of
routing devices without infrastructure. If we agree that a Mesh network
covers the essential part of a MANET then I would suggest to focus on a
Mesh network instead of trying to cover everything.

Is the intention to focus on non-mobile devices?

[ME]: There is no intention to exclude non-mobile devices. The draft
currently assumes that, from the "network management" pov., both mobile
and non-mobile devices have similar characteristics (I think we should
describe this somewhere). The draft further assumes that the managing
entity is not moving.

I might be wrong in this. Please describe which mobility aspects you
think should be covered from "network management" pov. Managing the IP
mobility itself, e.g. the IP address etc., is not network management per
se.

Constrained networks are more difficult to define, as there are several
aspects: bandwidth, loss rates of the channel, MTU, topology, etc. I
think that we need more discussion (but maybe after a BOF has been
initiated?)

[ME]: We can start such a discussion already today. However, I assume it
is mostly following the capabilities and limitations of the wireless
technology. What would be your proposal for a classification of
constrained networks?

- Section 1.5: (Network Topology Options): I think there is a mix
between the topology (i.e., the graph that represents routers and
communication links), traffic flows (which devices communicate with
which other devices), and application layer (proxies and NMS).

- Section 1.6: I like that.

- Section 1.7: There is mixture of constrained networks (first bullet);
I thought that constrained devices only means that they have little CPU
power and memory. Can't that device still use cable connectivity (i.e.
unconstrained network)? Or is it necessarily linked?

I am unclear about the purpose of this whole section. What does it serve
for?

[ME]: Section 1.7 in general tries to list and discuss the issues a
constrained device might have and how these issues influence the
management of such a device. As described in section 1.4 and 2. we
include non-constrained networks with constrained devices.

- Section 2: I think that the problem statement is not quite clear yet.
It is hard to identify what the problems are; there are so many useful
requirements in section 4, so maybe it could be better matched to these
requirements. It would be nice to read section 4, and then say "ah,
requirement x indeed logically follows from the problem y that has been
described in section 2".

[ME]: I agree the problem statement in section 2 (which I didn't have
time to update yet) could benefit from a revision aligning it with the
new sections 1.7 and section 4.

- Section 3: I like the diverse use cases. That can be very useful to
identify different requirements and problems.

- Section 4: I very much appreciate the enormous effort for gathering
the requirements. There will be detailed discussions about them
(hopefully), but this is a very good list to start from. 

We have to define if the security related requirements also fit in this
discussion, or better some place else (SOLACE?). 

[ME]: We see authentication and access control (to the extend it
matters) as part of network management. This is probably the part where
Coman and Solace can profit from and complement each other.

Again, I appreciate the effort of the authors, and hope that we can
continue the discussions in Atlanta. I apologize that I only provided
this high-level review, but the last weeks were very busy for me. If you
need help authoring the documents once they are split up, I could help
out.

Is there a meeting already planned? 

[ME]: Yes, there will be a meeting on Thursday. I wanted to announce it
once the room is known. Stay tuned.

Best regards

Ulrich 

On Wed, Oct 17, 2012 at 1:17 AM, Ersue, Mehmet (NSN - DE/Munich)
<[email-masked]> wrote:

Hi All,

Cheers,
Mehmet

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for

Abstract:

The IETF Secretariat

_______________________________________________
coman mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/coman

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 22 Oct 2012 16:19:13 +0200

> [ME]: There is no intention to exclude non-mobile devices.

s/non-mobile/mobile/

Cheers, 
Mehmet 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, October 22, 2012 12:55 PM
To: ext Ulrich Herberg; Carsten Bormann
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSAWG] [coman] FW: New Version Notification
fordraft-ersue-constrained-mgmt-02.txt

Hi Ulrich,

see my comments below.

Cheers, 
Mehmet 

Hi Mehmet,

Best regards

Ulrich 

Hi All,

Cheers,
Mehmet

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Subject: New Version Notification for

Abstract:

The IETF Secretariat