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

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: 12 May 2014 01:13
> To: Michael Behringer (mbehring)
> Cc: nmrg@irtf.org
> Subject: Re: [nmrg] New Use Case Document: Autonomic Network Bootstrap
[...]
> On 10/05/2014 01:27, Michael Behringer (mbehring) wrote:
> > NMRG,
> >
> > As discussed previously, here a use case contribution on Autonomic
> Networking:
> >
> > http://www.ietf.org/internet-drafts/draft-behringer-autonomic-bootstra
> > p-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.
> 
> 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.

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.
> 
> 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.

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

>    Brian
> 
> > 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
> >
> >
> > _______________________________________________
> > nmrg mailing list
> > nmrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/nmrg
> >