On Thu, Jan 16, 2014 at 10:29 AM, Juergen Schoenwaelder < [email protected]> 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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > -- James Nguyen Email: [email protected]
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
