Hi Aijun, > Thanks for your clarification of the NLP mechanism during the meeting. > 1. Regarding to the PUB/SUB model within IETF, there are already some of > them: > 1) https://datatracker.ietf.org/doc/html/rfc8641 > <https://datatracker.ietf.org/doc/html/rfc8641> (Subscription to YANG > Notifications for Datastore Updates) > 2) https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09 > <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09> > 3) https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile > <https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile> > 4) https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09 > <https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09> > Why do we need to invent the new one again?
Thank you, I was unaware of these. If the WG is interested, I’m certainly willing to pursue using one of these. As far as I can tell from a quick perusal, none of these is intended to be generic. That is to say, none of them is a dump truck either. > And, if we prefer to the PUB/SUB model to solve the discussed problem, why > RFC8641 can’t be used? YANG is evil. :-) > 2. Regarding to the NLP mechanism itself: > As you explained, current NLP adopt the “Subscribe Summary Prefixes, Notify > the failure of Specific Address” to reduces the pressures on ABRs. Such > approach has the following drawbacks again: > 1) The register should know in advance the summary prefixes that the > peers‘ loopback address belong to. Once the summary prefixes are changed, > such information should be updated, which will be headache for the operators Not at all. Loopback address configuration is already handled by the management plane. A prefix or multiple prefixes for loopback addresses will also be incorporated into the management plane. Modern networking assumes automation. Yes, we didn’t have it back when I started, but it’s there today. Admittedly, it’s not perfect and it has a way to go, but there are MANY organizations now that are fully automated. Anyone that wants to be, can be. > 2) If the register subscribe the “summary prefixes”, then it will > receives all the nodes fail notifications within this summary prefixes, which > should be avoided when you argue that IGP flooding has such side > effect.----The results is, NLP can’t avoid it also, then why don’t we utilize > IGP flooding mechanism directly? Yes, if you register for a prefix, you may get multiple notifications back. This is a good thing. In the IGP, this would create a scalability problem. The very good news is that this is not a scalability problem for NLP. There is no restriction for a finite sized LSDB. There are no real-time demands. The distribution of the data can be easily managed, even for slow receivers, by techniques that are well-known for BGP. Using a real transport protocol instead of relying on flooding is a Very Good Thing. And don’t get me wrong, I love flooding. For the things that should be flooded. :) > 3) The controller is already in the network, why not rely on it to > relieve the pressure of ABRs if we prefer to the PUB/SUB model to solve the > questions. And, as you stated, the NLP mechanism may be used to transfer > other non-IGP information, then why bother ABR? Yes, we can also solve the PUA problem via a controller. If the WG chooses to take that path, it can. Heck, we could choose to say that we believe in the SDN philosophy completely and that IGPs should be deprecated in favor of SDN. Of course, this also addresses the PUA problem. :) Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
