I understand the proposal. As I've stated elsewhere, I do not believe there is a problem here that needs solving. The "problem" was created by the user by summarizing prefixes that should not have been summarized -- they mis-configured their network. The routing protocols works just fine (act very quickly) if you don't incorrectly summarize "really important prefixes".
I was simply pointing out that IGPs also don't deal in liveness since that keeps coming up. Thanks, Chris. > On Jan 14, 2022, at 8:06 PM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > Hi, Christian and John: > > No. I think you all may misunderstand the proposal. What we are detecting is > actually the reachability/liveness of node that connected to the application, > not the application itself. > And, I think the node liveness is same as the node reachability. They will > all influence or break the path to their connected service if their > forwarding function is failed. > > Aijun Wang > China Telecom > >> On Jan 15, 2022, at 08:56, Christian Hopps <cho...@chopps.org> wrote: >> >> 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
