Subject: [nmrg] New Use Case Document: Autonomic Network Bootstrap

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 9 May 2014 13:27:33 +0000

NMRG, 

As discussed previously, here a use case contribution on Autonomic Networking:

http://www.ietf.org/internet-drafts/draft-behringer-autonomic-bootstrap-00.txt 

While writing this document, I realised that we need to adapt the use case template further. At least in my use case, the template didn't flow perfectly yet. Here my main points: 

1) We should bring out very explicitly why an autonomic (ie, distributed) solution is preferred or required. In my use case I therefore added a section "Benefits of an Autonomic Solution". As you can see, it's a very short paragraph, but I think we should be explicit about it. After all, this is what our use cases are all about.

2) The title "Parameters each device can decide for itself" doesn't really gel well in my doc. The issue is the word "decide". My original proposal was "Self-knowledge", which doesn't really capture is fully either. I decided in my version to call this section "Device Based Self-Knowledge and Decisions".  I think that captures both thoughts.

3) The separation of parameters (old section 4) and Interactions (old section 5) didn't really work out too well either for my use case. In 4 we say "parameters needed" and in 5 "information needed from neighbour devices". In my use case the following slightly re-shuffled structure worked better: 

   1.  Introduction  
   2.  Problem Statement 
   3. Benefits of an Autonomic Solution
   4.  Intended User and Administrator Experience 
   5.  Analysis of Parameters and Information Involved
     5.1.  Device Based Self-Knowledge and Decisions
     5.2.  Interactions with other devices
     5.3.  Information needed from Intent 
     5.4.  Monitoring, diagnostics and reporting
   6.  Comparison with current solutions

Thoughts? 
Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 May 2014 08:23:48 +1200

Hi Michael,

Thanks for that. I will find the time to read your draft carefully
rather than replying in the abstract, but I guess we should not be
too rigid about the format anyway - after all, the goal is not the
format, but to understand and extract the requirements. Indeed, as
you have experienced, each use case raises its own topics.

(I recently reviewed the RTCweb use cases document. Their aproach
is quite relaxed about the description of each use case, but very
systematic in the description of the requirements. See
draft-ietf-rtcweb-use-cases-and-requirements.)

Everybody: we are just starting a discussion with the IETF Area
Directors about a BOF in Toronto based on various AN use cases. More
news later, but now would be a good time to post one or two more use
cases.

Regards
   Brian Carpenter

On 10/05/2014 01:27, Michael Behringer (mbehring) wrote:
> _______________________________________________
> nmrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nmrg
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 May 2014 11:13:27 +1200

Hi everybody,

I find this use case clear and have no objections to
the changes in format compared to the other two. In the end
it's more important (IMHO) to capture the essentials of the use
case than to follow a rigid format, so I think I'd be happy
with use case authors varying the format as long as the main
points are covered. What do other people think?

> 1) We should bring out very explicitly why an autonomic (ie, distributed) solution is preferred or required. In my use case I therefore added a section "Benefits of an Autonomic Solution". As you c…

Yes, although in a sense the high-level benefit is always the same: get
as close as possible to plug-and-play. So we would need to be stating
something more specific than that.

> 2) The title "Parameters each device can decide for itself" doesn't really gel well in my doc. The issue is the word "decide". My original proposal was "Self-knowledge", which doesn't really captur…

Yes, and of course they are closely related. For example a router could
detect that it has 3 interfaces (self knowledge), one of which has another
router already announcing a prefix (discovery), so it can decide that it
needs to request 2 more prefixes.

> 3) The separation of parameters (old section 4) and Interactions (old section 5) didn't really work out too well either for my use case. In 4 we say "parameters needed" and in 5 "information needed from neighbour devices". 

I see the point, but it is a bit harder in this document to extract
the list of parameters that might be the object of negotiation
with neighbors. I think that will be important when we try to
extract requirements. Very possibly, the description of the
interactions should preceded the identification of the parameters.

   Brian

> In my use case the following slightly re-shuffled structure worked better: 
>    1.  Introduction  
>    2.  Problem Statement

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 12 May 2014 16:48:20 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 12 May 2014 01:13
> To: Michael Behringer (mbehring)
> Cc: [email-masked]
> Subject: Re: [nmrg] New Use Case Document: Autonomic Network Bootstrap
[...]
> > While writing this document, I realised that we need to adapt the use case
> template further. At least in my use case, the template didn't flow perfectly
> yet. Here my main points:
> >
> > 1) We should bring out very explicitly why an autonomic (ie, distributed)
> solution is preferred or required. In my use case I therefore added a section
> "Benefits of an Autonomic Solution". As you can see, it's a very short
> paragraph, but I think we should be explicit about it. After all, this is what
> our use cases are all about.
> 
> Yes, although in a sense the high-level benefit is always the same: get as
> close as possible to plug-and-play. So we would need to be stating

Over the last years I've been facing the same argument over and over: Why not have this simplification done on a central controller? And, given the current buzz around SDN, we'll have to answer the same question. So I suggest we start articulating the reasons from the outset. 

Plug and play, seen from an end-user perspective doesn't really answer that. In the bootstrap use case, there is an actual MUST DISTRIBUTE, which I'm trying to articulate in this new section. You CANNOT centralise the function to establish a secure connection with the central entity. 

For many other use cases, in my experience, the differentiation to a centralised solution isn't black and white. We should still outline the advantages of a distributed approach. 

> > 2) The title "Parameters each device can decide for itself" doesn't really
> gel well in my doc. The issue is the word "decide". My original proposal was
> "Self-knowledge", which doesn't really capture is fully either. I decided in
> my version to call this section "Device Based Self-Knowledge and
> Decisions".  I think that captures both thoughts.
> 
> router already announcing a prefix (discovery), so it can decide that it needs
> to request 2 more prefixes.

So it sounds like this section title works for you? 
 
> > 3) The separation of parameters (old section 4) and Interactions (old
> section 5) didn't really work out too well either for my use case. In 4 we say
> "parameters needed" and in 5 "information needed from neighbour
> devices".
> 
> I see the point, but it is a bit harder in this document to extract the list of
> parameters that might be the object of negotiation with neighbors. I think
> that will be important when we try to extract requirements. Very possibly,
> the description of the interactions should preceded the identification of the
> parameters.

Let's leave that flexible for now. When it comes to requirements, we may need to be more precise. For the use case I think we're good. 

Michael

---

From: Olivier Festor <[email-masked]>
Date: Mon, 12 May 2014 22:14:25 +0200

Dear Michael and NMRG contributors,

comments inline.

> http://www.ietf.org/internet-drafts/draft-behringer-autonomic-bootstrap-00.txt 

(2) Security consideration:
 "An autonomic approach can used to make a bootstrap process secure. » -> "An autonomic approach can BE used to make a bootstrap process secure."

> 1) We should bring out very explicitly why an autonomic (ie, distributed) solution is preferred or required. In my use case I therefore added a section "Benefits of an Autonomic Solution". As you c…

An autonomic system is not limited to self-configuration. The other functions should be explicitly mentioned here as well (protecting, healing, …). 

> 2) The title "Parameters each device can decide for itself" doesn't really gel well in my doc. The issue is the word "decide". My original proposal was "Self-knowledge", which doesn't really captur…

Agreed.

> 
> 3) The separation of parameters (old section 4) and Interactions (old section 5) didn't really work out too well either for my use case. In 4 we say "parameters needed" and in 5 "information needed from neighbour devices ».

To bootstrap, a device  needs to set a couple of parameters. 
 -a- some can be found internally (no need to observe anything outside or interact with any 3rd party). The #of interfaces of a router mentioned by Brian in his mail
 -b- some can be « learned » by the device from observation of his environment. No need to interact with a 3rd party
 -c- some can be learned from interacting with the environment (like testing for duplicate addresses for examples)
 -d- some need to be obtained from 3rd party entities (like the cloud service you mention in the autonomic bootstrap.
 -e- and sometimes a few need to be pre-provisionned on the devices

The first 2 (a & b) correspond to your 5.1 subsection. -c- corresponds to 5.2. It is unclear to me if -d- are also to be described in 5.2 or elsewhere ? 
Where in your proposed structure should -e- appear ?

Monitoring, diagnostics and reporting should not be a subsection of the analysis of parameters & information involved but rather a section on its own. 

>   6.  Comparison with current solutions

/Olivier Festor

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 13 May 2014 13:24:17 +0000

Thanks for your mail, Olivier, responses inline...

>  "An autonomic approach can used to make a bootstrap process secure. > ->
> "An autonomic approach can BE used to make a bootstrap process secure."

Thanks, will be fixed.
 
> An autonomic system is not limited to self-configuration. The other
> functions should be explicitly mentioned here as well (protecting, healing,
> ...).

Completely agree, but I don't understand why you mention that. The text you reference doesn't mention configuration at all. Also the draft mentions "config" 4 times, and I believe in the correct context. Please point to some text that you believe needs fixing. 
 
> Decisions".  I think that captures both thoughts.

Tx

> "parameters needed" and in 5 "information needed from neighbour devices
> >.
> 
>  -a- some can be found internally (no need to observe anything outside or
> interact with any 3rd party). The #of interfaces of a router mentioned by
> Brian in his mail
>  -b- some can be < learned > by the device from observation of his
> environment. No need to interact with a 3rd party
> The first 2 (a & b) correspond to your 5.1 subsection. -c- corresponds to 5.2.
> It is unclear to me if -d- are also to be described in 5.2 or elsewhere ?

To me, your -d- falls into 5.2., "interaction with other devices". Where the word "devices" doesn't capture the spirit exactly either. 
 
> Monitoring, diagnostics and reporting should not be a subsection of the
> analysis of parameters & information involved but rather a section on its
> own.

Hmmm... Yes, that would be possible. No strong views here. To me, I saw it as a protocol interaction that has to happen, so it falls into section 5. 

Bottom line: There is no 100% right or wrong. As long as the information is there in the draft, and as long as the main points are covered (ie we haven't missed a main point), I think let's not over engineer this template either. Slight adaptations to specific use cases are legit. 

Michael