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
