Hi, Tony: 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 (Subscription to YANG Notifications for Datastore Updates) 2) https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09 3) https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile 4) https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-09 Why do we need to invent the new one again? And, if we prefer to the PUB/SUB model to solve the discussed problem, why RFC8641 can't be used? 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 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? 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? Best Regards Aijun Wang China Telecom
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
