Aijun, > For PUAM, the receiver NEED NOT register anything. > Once the node fails, all the receivers(normally the nodes within one area) will be notified.
That's a spec bug not a feature. Not only those egress nodes which would have otherwise register will get it with PUAM, but also all P nodes in the area which do not have any interest what so ever will also get it. Worse - EVERY IGP NODE - in all areas/levels will get it. Can't you see how bad architecturally that is ? And I do not buy the justification - oh this is so little or - oh this is likely to never happen ... If that is so why bother when you can just either do it with pub-sub model or simply withdraw your service routes (either one by one or in bulk mode) ? Thx, R. PS. And if you like analogies - We are here about speed to service restoration - correct ? So what is better - to signal node failure using as a carrier a local train which requires to change trains at each of say 30 stations or put the information into a RAPID one which only stops at two exchange stations ? On Mon, Mar 28, 2022 at 3:15 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > Hi, Tony: > > Let’s focus on the comparison of NLP and PUAM(Prefix Unreachable > Announcement Mechanism): > > For NLP, the receiver should register the interested prefixes first. Once > the node fails, all the receivers(normally the nodes within one area) that > register such interested prefixes will be notified. > > For PUAM, the receiver NEED NOT register anything. Once > the node fails, all the receivers(normally the nodes within one area) will > be notified. > > > > From the POV of the receiver, if it gets the same results, why don’t > select the approach that need less work or nothing to do? > > > > And regarding to your arguments of “Dump Truck” worry about IGP protocol, > I think defining one new protocol does not solve the ultimate pressure on > Router. Let’s explain this via one analogy: > > The customer(Operator) want the truck(IGP Protocol) to piggyback(via some > Tag) some information, the driver(Vendor) said he can’t, because the truck > may crush the station(Router) when it pass. The operator need another > truck(New Protocol) to carry it. > > > > Here is the problem then, from the POV of station(Router), if it can’t > endure the pass of one truck, why can it can stand to pass the two trucks > at the same time? > > Wish you can explain the above paradox in reasonable/logical manner. > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org <lsr-boun...@ietf.org> *On Behalf Of *Tony Li > *Sent:* Friday, March 25, 2022 7:20 PM > *To:* Aijun Wang <wang...@chinatelecom.cn> > *Cc:* lsr@ietf.org > *Subject:* Re: [Lsr] Is it necessary to define new PUB/SUB model to > monitor the node live? > > > > > > 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 (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? > > > > > > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
