Tony - From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li Sent: Wednesday, October 5, 2022 7:57 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: Christian Hopps <cho...@chopps.org>; Robert Raszuk <rob...@raszuk.net>; Henk Smit <henk.i...@xs4all.nl>; lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt
Hi Les, Using the protocol to send what is best described as some subset of a PICS means that we propose to use the IGP flooding mechanism to send static information which the protocol itself cannot (and should not) use in its operation. This consumes space, bandwidth, gets periodically refreshed unnecessarily, and now a complete copy of the information from every node resides on every router in the network when it is only needed by an “NMS”. It would be hard to come up with a better example of “IGP isn’t a dump truck” than this. If you can’t beat ‘em, join ‘em. [LES:] Thanx for the honesty. 😊 Doesn’t make me like the idea though. If there is a belief that we can severely limit the amount of information that is sent/node, I’d have to say that I am skeptical. Once we allow this into the protocol, I don’t see any basis on which to separate what is allowed and what is disallowed. It would not be unreasonable for an operator to say that everything that is a candidate to be mentioned in a PICS is a legitimate candidate for being advertised using this mechanism. Which means the amount of information is likely to become very large – especially once it becomes the de facto way of providing protocol management information. The justification seems to be that we don’t have anything better – which represents a longstanding failure of the management plane. While I agree with you that management plane solutions are not adequate – not least because we can’t get the industry to converge on a single solution – this does not mean we should invest in the wrong solution. We would be better served spending time and effort working on the right solution - as difficult as that may be. If we despair of getting a management plane solution, my suggestion would be to use RFC 6823/6822 to define an IS-IS protocol management application that could support the advertisement of such information. This is technically straightforward to define/implement, easily extensible, and it separates the management information from the information used by the protocol. And because a separate topology can be used for the “management instance”, it would be possible to reduce the number of copies in the network. A blue dump truck is not an architectural improvement over a red dump truck and definitely not the right solution. [LES:] I agree – I don’t like the RFC6823/6822 solution – I want a management plane solution. But it is better than carrying the information in the routing instance – for all the reasons both of us have mentioned over the years whenever someone proposes to use IGP flooding for information not used by the protocol itself. What we need is a management plane mechanism that can be easily consulted, even by nodes not running the IGP. Or nodes not running any IGP. We should NOT require storing the management data on every node. That’s silly. Rather, we should have a set of distributed, synchronized servers that can be easily referenced and updated. We need an auto-discovery mechanism so that nodes can learn where these servers are. We need a common hierarchical data schema so that data is organized consistently. And we needed this in 1992. ;-) Even if you agree with this, I am not willing to stall the current work the decades that it will take for the IETF to make progress on this. [LES:] It is clear that we have different opinions on this – and there are multiple folks on both sides of this discussion. What I would hope we can agree on is to separate the discussion of adding advertisement of “feature supported” from the MP-TLV draft by writing a separate draft on this proposal. This would allow the two pieces of work to progress independently – as they should. This makes sense to me since the proposal to advertise feature support is clearly not limited to MP-TLV and has no bearing on how MP-TLVs are encoded. Can we agree on this? Les Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
