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. > 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. > 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. > 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. Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
