Hi,
One point regarding MANET.
I believe that it deserves its own document: "MANET network management
considerations". Actually, when looking at draft-ietf-manet-nhdp-mib
part of the IESG review, one of the outcome was that such a document was
required.
I cleared my DISCUSS on draft-ietf-manet-nhdp-mib with this COMMENT
Note regarding the applicability statement: This is solved, as we
discussed, but I'll keep this little sentence in one
corner of my head "A fuller discussion of MANET network management use
cases and challenges will be provided elsewhere."
How/If this "MANET network management considerations" draft relates to
the draft-ersue-constrained-mgmt, I'm not sure at this point in time.
Regards, Benoit
Hi Ulrich,
see my comments below.
Cheers,
Mehmet
*From:*ext Ulrich Herberg [mailto:[email protected]]
*Sent:* Saturday, October 20, 2012 1:46 AM
*To:* Ersue, Mehmet (NSN - DE/Munich)
*Cc:* [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>
*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 protected] <mailto:[email protected]>> wrote:
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 protected] <mailto:[email protected]>
[mailto:[email protected] <mailto:[email protected]>]
Sent: Monday, October 15, 2012 9:59 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Cc: [email protected] <mailto:[email protected]>;
[email protected]
<mailto:[email protected]>
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
_______________________________________________
coman mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/coman
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
