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 the latter. Not sure if PULSE authors are of
the same opinion.
If every node is interested in every other node's liveness that we are
redefining scope of the work here, but I may still argue that not every
node in the network will have a segment endpoints terminating on every
other node. So registration model handled outside of active link state
nodes IMO still is far superior to flood and forget (via timeout) type of
model.
Best,
R.
On Tue, Mar 29, 2022 at 3:40 AM Aijun Wang
wrote:
> 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 should know the status of
> other P node on the path, which is located in other areas.
>
> Then, NLP like approach will also result in ALL NODES within the areas
> needs to register such information, and the failures of one nodes will be
> sent to all the register.
>
> What’s the difference with the IGP flooding mechanism then?
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk
> *Sent:* Monday, March 28, 2022 5:01 PM
> *To:* Aijun Wang ; Tony Li
> *Cc:* Aijun Wang ; lsr
> *Subject:* 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 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
> 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 *On Behalf Of *Tony Li
> *Sent:* Friday, March 25, 2022 7:20 PM
> *To:* Aijun Wang
> *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)
