Indeed, and in fact the IGP should only be dealing with the reachability to the node, not with the node or applications liveness.
Thanks, Chris. [as wg member] > On Jan 14, 2022, at 7:47 PM, John E Drake <jdr...@juniper.net> wrote: > > 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> > 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> > Sent: Friday, January 14, 2022 5:53 PM > To: John E Drake <jdr...@juniper.net> > Cc: Robert Raszuk <rob...@raszuk.net>; Les Ginsberg (ginsberg) > <ginsb...@cisco.com>; 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] > > 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> > wrote: > > > Hi, > > Comment inline below. > > Yours Irrespectively, > > John > > > Juniper Business Use Only > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Robert Raszuk > Sent: Monday, January 10, 2022 7:15 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; Aijun Wang > <wangai...@tsinghua.org.cn>; 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] > > 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> > wrote: > Robert - > > From: Robert Raszuk <rob...@raszuk.net> > Sent: Monday, January 10, 2022 2:56 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Tony Li <tony...@tony.li>; Christian Hopps <cho...@chopps.org>; Peter > Psenak (ppsenak) <ppse...@cisco.com>; Shraddha Hegde <shrad...@juniper.net>; > Aijun Wang <wangai...@tsinghua.org.cn>; Hannes Gredler <han...@gredler.at>; > lsr <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 > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
