Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Aijun, Hmm so you want ephemeral indication to trigger SPF and affect topology computation ? I do not think this is a sound idea. At least PULSE folks (Peter & Les pls confirm) never assumed PULSE will trigger SPF and will be used as topology change input. Thx, R. On Thu, Mar 31, 2022 at

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi, Robert: There are possibilities that only one of the ABRs is detached from other nodes in the same area, the receivers should select other ABRs to reach the destination announced by PUA message. Such scenario is described in

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi Aijun, *" Incremental SPF or other mechanism can be used to parse such unreachable information on the receiver to decrease Tony’ worry for the stability of “vital truck”.* H - could you kindly elaborate a bit more what *incremental SPF* has anything to do with parsing such unreachable

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi, Robert: From: Robert Raszuk Sent: Tuesday, March 29, 2022 3:53 PM To: Aijun Wang Cc: Tony Li ; Aijun Wang ; lsr Subject: Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live? Aijun, Your email is written prove that my question the other day which

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Aijun, Your email is written prove that my question the other day which remain not answered is valid. I asked is the scope of PUA/PULSE to only signal service endpoints or is this to also carry any to any liveness across all areas/levels in the link state IGP ? It seems clear that you say is

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi, Robert: Let’s don’t make the conclusion in hurry. I think you should know the application scenarios for such unreachable information is not only for BGP services, but also for the tunnel services(for example, SRv6 loose-path routing). For the latter scenario, the P node on the path

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

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

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

Hi Aijun, > 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

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

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

Re: [Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

I agree with Tony that these other PUB/SUB efforts aren’t directly applicable. I don’t necessarily agree that YANG is evil though  However, note that the I2RS effort (where such a route monitoring capability was envisioned) was for the most part unsuccessful. Thanks, Acee From: Lsr on

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

[Lsr] Is it necessary to define new PUB/SUB model to monitor the node live?

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)