Tony & Les, I do think we should be signalling node's enabled/active capabilities including the ability to process various types of encoded PDUs in band.
I do not believe in live management planes. Sure getting stats, config push etc ... it is all doable and deployed. But dynamic configuration based on nodes activated capabilities via mgmt plane is hard as we keep adding stuff to protocols. Even if one builds such tool today tomorrow it is obsoleted. I do however consider Les's points as valid too. Especially insertion of node anywhere in the area which may not be capable of handling some encoding (and does not need to operationally) yet his signalling if we act on it in the protocol operationally would have a potential to break existing features. So to do this right such capability signalling would need to contain scope. But I see no harm in having such info available as mgmt information. After all this is all pretty static and so little that I am not sure why we are even spending time to discuss it so long. > The thought of someone keeping all of this in their heads is simply naive. Or maybe it is actually smart :) Maybe the goal here is to make networks so complex that only a few can safely operate them. Otherwise just outsource it and use "...as-a-service". Best, R. On Tue, Oct 4, 2022 at 6:16 PM Tony Li <tony...@tony.li> wrote: > Hi Les, > > *Folks may well complain that management tools are not as good as they > need to be, but trying to compensate for this by adding management > information into the protocol itself isn’t a good solution.* > > It is not a good solution. But it is the only practical solution > available. At scale, we need automation. We have tried and failed (again) > to get broad adoption of a management infrastructure. We continue to reject > alternative approaches. The thought of someone keeping all of this in their > heads is simply naive. > > We have already painted ourselves into this corner. There is no good way > out. > > Tony > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
