Hi, Tony:
From: [email protected] <[email protected]> On Behalf Of Tony Li Sent: Thursday, January 20, 2022 11:23 PM To: Aijun Wang <[email protected]> Cc: lsr <[email protected]> Subject: Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt Hi Aijun, You are proposing to use the Out of Band channel to solve the IGP problem. There are already existing such channel, why we bother IGP to establish new one? You’re missing the point completely. I’m proposing an entirely new subsystem. That’s architecturally necessary. One of the things that we’ve learned over the years is that modularity is a necessity. If you don’t modularize, then you keep adding things onto the main structure and it grows in weird ways and becomes unmaintainable and fragile. A fine example from early operating systems was the monolithic monitor. We would not dream of architecting things that way today. To avoid this, as we add functionality, we need to respect the architectural boundaries of the systems that we’ve created and create alternate subsystems that interface with other subsystems but are largely independent. In this case, liveness information can be extracted from the IGP completely locally and flow into the pub-sub system for distribution subsystem. [WAJ] Then I think it is not the subject that the LSR should discuss. There are many modules on the routers. They may all relevant to the IGP modules. You are trying to accomplish the work that has been done via the management system, for example https://datatracker.ietf.org/doc/html/rfc8639 (Subscription to YANG Notification) And, don’t’ you think you open the gate for DDoS attack of the ABR, or all of the ABRs within the network? You need to consider various methods to mitigate it. Every L2 point of attachment to the network is a DoS target. We know how to deal with those things. Management ports are DoS able. SSH ports are DoSable. This is not news. This is just one more in a very long list. We have techniques for DoS mitigation. They are well known. This was mentioned in the security considerations section. [WAJ] What was said in your “Security Consideration”(https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness-01#section-6) is the followings: “This document creates no new security issues. Security of transport protocol connections are addressed by the use of conventional transport protocol security techniques, such as TLS. IGP advertisements are not expected to have privacy, so the advertisement of the service is not a security issue.” What I think is that you introduce new security issues, or one new issue on your mentioned “long list”. And, you should configure on all the clients and ABRs the communication key, or authenticate each other. And for the massive failures scenario, as that you argued for other proposed solutions, all the registered clients will also receive the massive notification information unless you do some filter action on the ABRs. Each client will receive exactly the notifications that they registered for (modulo the discussion on registering for less specifics). If there is a massive outage, it does not affect the IGP. At all. The LSDB is unchanged. Only the notification subsystem will be affected by the scale. And all of the notificiations should be delivered, eventually. Under stress, it will undoubtedly delay, but not drop information. That’s what we want. [WAJ] The key point to stress the router is that the tasks it should be executed at the same time. You just divide the work into separate modules, I think it is same challenge to the router. Then what the advantages that your proposal when compared to the PUA/PULSE solution? The pub-sub proposal is an architecturally clean way of solving the problem, as I understand it. It does not have the step function scale nightmare. [WAJ] There is existing such clean way, why you invent another? And why in IGP/LSR WG? Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
