Hi, Tony:
-----Original Message----- From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Tony Li Sent: Monday, November 22, 2021 1:11 AM To: Aijun Wang <wangai...@tsinghua.org.cn> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Gyan Mishra <hayabusa...@gmail.com>; Christian Hopps <cho...@chopps.org>; lsr <lsr@ietf.org>; Acee Lindem (acee) <a...@cisco.com>; Tony Przygienda <tonysi...@gmail.com> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes Hi Aijun, >> No. ABRs advertised statically configured prefixes for the area. Anything >> else would cause flap. And it’s purely reachability, not liveness. There can >> be zero live nodes within an area and the ABR should still advertise its >> summary. > > [WAJ] What the usage of the summary advertisement in such conditions excepts > it misleads the nodes within the area it attached? I think Chris answered this adequately. [WAJ] I have explained to Chris the differences between the usage of IGP unreachable and BGP unreachable at https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/ BGP、Tunnel etc. overlay services are depending on the IGP, then knowing the unreachable information can certainly accelerate their convergence and switchover to the backup endpoints. >>> Pub/Sub style notification seems promising, but it will require the ABR >>> store the subscription state which will certainly degrade its performance. >> >> >> Baloney. A notification list address post-SPF is wholly outside of the >> performance path. > > [WAJ] Is there any existing mechanism to accomplish your proposal among the > PEs? No, there is no existing mechanism. PUAM is one new mechanism. I’m suggesting another one that’s architecturally cleaner. > [WAJ] Within the network, the number of PEs often surpasses the number of P > nodes. Even with P nodes, such information can also help them reroute/switch > to other endpoints along the SRv6 tunnel backup path. > I think you could imagine the signal just as the alert information that often > seen on the highway. It can certainly save the driver’s time. Wouldn’t you > like to know such information immediately? Or you just drive as planned until > near the target to know the road is broken? What I would like is if there was a centralized service, such as Google Maps, that simply did the path computation for me and updated it in real time. :) Interestingly, that information isn’t flooded. It’s built with a scalable back end service and then unicast to the end user. [WAJ] As I explained below, PUAM information is needed not only the PEs(for BGP scenario), but may be used by P router within the network(for Tunnel scenario). As also I explained previously, the implementation/operator can limit the PUAM only for /32 or /128 loopback address, which will not sacrifice the scalability of IGP, and at the same time, accelerate the convergence of the overlay services that depends on it. Comparing with utilizing the existing procedures, Introducing another mechanism, such as centralize service, PUB/SUB mechanism as you proposed, isn't it more complex and less efficient? All the procedures that we considered will not omitted, the difference is only how to transfer the message. T _______________________________________________ Lsr mailing list <mailto:Lsr@ietf.org> Lsr@ietf.org <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
