> [ME]: There is no intention to exclude non-mobile devices.
s/non-mobile/mobile/ Cheers, Mehmet From: [email protected] [mailto:[email protected]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich) Sent: Monday, October 22, 2012 12:55 PM To: ext Ulrich Herberg; Carsten Bormann Cc: [email protected]; [email protected] Subject: Re: [OPSAWG] [coman] FW: New Version Notification fordraft-ersue-constrained-mgmt-02.txt 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]; [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]> 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]] Sent: Monday, October 15, 2012 9:59 PM To: Ersue, Mehmet (NSN - DE/Munich) Cc: [email protected]; [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] https://www.ietf.org/mailman/listinfo/coman
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
