I don’t think so. Today things just work, at a given time scale. What you said you are trying to do is reduce the time scale for detecting that an application on a node has failed. However, conflating the health of a node with the health of an application on that node seems to be inherently flawed.
Yours Irrespectively, John Juniper Business Use Only From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: Friday, January 14, 2022 7:40 PM To: John E Drake <jdr...@juniper.net> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Robert Raszuk <rob...@raszuk.net>; Christian Hopps <cho...@chopps.org>; Shraddha Hegde <shrad...@juniper.net>; Tony Li <tony...@tony.li>; Hannes Gredler <han...@gredler.at>; lsr <lsr@ietf.org>; Peter Psenak (ppsenak) <ppse...@cisco.com> Subject: Re: [Lsr] BGP vs PUA/PULSE [External Email. Be cautious of content] When the node is up, all the following process are passed to the application layer. This is the normal procedures of the IGP should do. According to your logic, IGP are solving the wrong problem now? Aijun Wang China Telecom On Jan 15, 2022, at 08:30, John E Drake <jdrake=40juniper....@dmarc.ietf.org<mailto:jdrake=40juniper....@dmarc.ietf.org>> wrote: Correct, but as Tony, Robert and I have noted, a node being up does not mean that an application on that node is up, which means that your proposed solution is probably a solution to the wrong problem. Further, Robert’s solution is probably a solution to the right problem. Yours Irrespectively, John Juniper Business Use Only From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Sent: Friday, January 14, 2022 5:53 PM To: John E Drake <jdr...@juniper.net<mailto:jdr...@juniper.net>> Cc: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Hannes Gredler <han...@gredler.at<mailto:han...@gredler.at>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>> Subject: Re: [Lsr] BGP vs PUA/PULSE [External Email. Be cautious of content] Hi, John: Please note if the node is down, the service will not be accessed. We are discussing the “DOWN” notification, not the “UP” notification. Aijun Wang China Telecom On Jan 15, 2022, at 00:25, John E Drake <jdrake=40juniper....@dmarc.ietf.org<mailto:jdrake=40juniper....@dmarc.ietf.org>> wrote: Hi, Comment inline below. Yours Irrespectively, John Juniper Business Use Only From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of Robert Raszuk Sent: Monday, January 10, 2022 7:15 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Hannes Gredler <han...@gredler.at<mailto:han...@gredler.at>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>>; Peter Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>> Subject: Re: [Lsr] BGP vs PUA/PULSE [External Email. Be cautious of content] Hi Les, > You seem focused on the notification delivery mechanism only. Not really. For me, an advertised summary is like a prefix when you are dialing a country code. Call signaling knows to go north if you are calling a crab shop in Alaska. Now such direction does not indicate if the shop is open or has crabs. That info you need to get over the top as a service. So I am much more in favor to make the service to tell you directly or indirectly that it is available. [JD] Right. Just because a node is up and connected to the network does not imply that a given application is active on it. Best, R. On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Robert - From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Monday, January 10, 2022 2:56 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Cc: Tony Li <tony...@tony.li<mailto:tony...@tony.li>>; Christian Hopps <cho...@chopps.org<mailto:cho...@chopps.org>>; Peter Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>; Shraddha Hegde <shrad...@juniper.net<mailto:shrad...@juniper.net>>; Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; Hannes Gredler <han...@gredler.at<mailto:han...@gredler.at>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: [Lsr] BGP vs PUA/PULSE Les, We have received requests from real customers who both need to summarize AND would like better response time to loss of reachability to individual nodes. We all agree the request is legitimate. [LES:] It does not seem to me that everyone does agree on that – but I appreciate that you agree. But do they realize that to practically employ what you are proposing (new PDU flooding) requires 100% software upgrade to all IGP nodes in the entire network ? Do they also realize that to effectively use it requires data plane change (sure software but data plane code is not as simple as PI) on all ingress PEs ? [LES:] As far as forwarding, as Peter has indicated, we have a POC and it works fine. And there are many possible ways for implementations to go. It may or may not require 100% software upgrade – but I agree a significant number of nodes have to be upgraded to at least support pulse flooding. And with scale requirements you are describing it seems this would be 1000s of nodes (if not more). That's massive if compared to alternative approaches to achieve the same or even better results. [LES:] Be happy to review other solutions if/when someone writes them up. I think what is overlooked in the discussion of other solutions is that reachability info is provided by the IGP. If all the IGP advertises is a summary then how would individual loss of reachability become known at scale? You seem focused on the notification delivery mechanism only. Les Many thx, Robert _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
