Re: [OPSAWG] Comments on draft-opsawg-ersue-coman-probstate-reqs

[James Nguyen <[e-mail]>]

On Thu, Jan 16, 2014 at 10:29 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Thu, Jan 16, 2014 at 09:38:30AM -0500, James Nguyen wrote:
> > >
> > >> (2) Section 3.3 Configuration Management
> > >>
> > >>     Session-oriented configuration protocol may be expensive for
> managing
> > >> a large number of similar devices.  In a case when common redundant
> > >> configurations is issued, reliable multicast with negative
> acknowledgement
> > >> (e.g. Negative ACKnowledgement (NACK)-Oriented Reliable Multicast
> (NORM))
> > >> would work best.  I suggest to add a reliable transport requirement
> in this
> > >> section.  Moreover, a common data model would be needed.
> > >>
> > >>     Stateless configuration update solution would also work well for
> > >> constrained networks.
> > >
> > > My assumption is that reliable multicast protocols are not simple and
> > > bring their own can of worms. Can you point to prototype systems that
> > > do successfully use reliable multicast to configure constrained
> > > devices?
> >
> > I certainly can list a couple of scenarios:
> >
> > I assume that military radios could be categorized as constrained
> > devices as they're often on the move and operated in unreliable
> > networks with lossy links and/or highly disrupted environment.
> > Military radios or military devices seem to fit the definitions that
> > are listed in Section 1.6.
> >
> > (1) In military theater or emergency disaster incident, a group of
> > soldiers or a group of search-and-rescuers need to switch frequency of
> > their radios to join other group's communication network.
> >
> > (2) In battlefield, soldiers' need to be zero-outed (of
> > configurations) to prevent these radios/comms devices to fall in
> > enemies' hands.
>
> Luckily, I am not familiar with any of this. But my concern remains
> and in such scenarios, I would have serious trouble to define what
> 'reliable' means given that the group membership is open ended.
>

I see that Req-ID 4.10.003 is about best-effort multicast.  Would
"best-effort" be good enough instead of reliable?  We can assume that
developers have an option of how to implement.


>
> > > Can you also elaborate what "stateless configuration update solution"
> > > means to you?
> >
> > I meant stateless configuration management.
> >
>
> And that means what to you? What is 'stateless'?
>
>
Let's take NETCONF as an example of stateful management protocol that
requires many message exchanges.  This might be inefficient in constrained
networks.  A less chatty management protocol fits better in this case.


> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>



-- 
James Nguyen
Email: [e-mail]