> On Jan 14, 2022, at 8:25 PM, Christian Hopps <cho...@chopps.org> wrote: > > 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.
Sorry that was "as wg member". > > 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
