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

From: Benoit Claise <[email-masked]>
Date: Fri, 02 Nov 2012 07:45:35 -0400

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-masked]]
> *Sent:* Saturday, October 20, 2012 1:46 AM
> *To:* Ersue, Mehmet (NSN - DE/Munich)
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[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] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Monday, October 15, 2012 9:59 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[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
>
>
> _______________________________________________
> coman mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/coman
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg