From: Tony Li [mailto:[EMAIL PROTECTED] <snip>
>|I agree that managers cannot know anything about structures that occur >|at a different recursion layer than themselves. However, this is only >|one of a large repertoire of problems that make network management very >|challenging. The current state of network management for the Large End >|User is very troubling -- ditto for highly mobile networks. I've always >|viewed this as an inherent failing of network management itself (i.e., >|the foundation is inadequate) but I concur that map and encaps makes it >|worse. > > >Is it really the failing of management? >Or is it concurrent with the addition of a layer? >If you add a layer of abstraction, then how is management supposed to work given that it is prohibited about knowing about the lower layer? >In my book, this is exactly the architectural failing of having an additional network layer. >Yes, we live with it today for the sake of VPNs and the like, but is that really what we want for everyday life? My opinions about IP network management and SNMP were frequently not popular in the IETF SNMP community, but my firm opinion is that network management for IP systems has **never** worked well for the large end user. It suffers in several ways, notably including (sometimes subtle) schema mis-matches between different products, poor scaling, demonstrably inadequate security (hopefully the ISMS WG is fixing this), and a desperate need for better information fusion. It is conceivable to me that deployments with only a few different types of nodes may not have trouble with network management, but my observation with vast deployments is that the IP network management technology verges on broken. This was the case well before maps-and-encaps became popular -- though map-and-encaps has definitely not improved an already problematic system as you observe. Regardless, map-and-encaps can't be blamed for a system that is inherently flakey. _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
