> same happens without a pulse today without a summarization We have established that this discussion is about this scenario:
" it's applicable in cases where summarization is used." and in such cases under some scenarios PULSES can actually make things worse. The goal is (or should be) not to make it worse when not needed. - - > the draft is specifying IGPs extensions for pulse. The handling of the > pulse by the interesting apps is not something we should be specifying > in this draft. Also such handling is a local behavior on the ingress PE. The draft is proposing an ephemeral signaling with mandatory timeout. An alternative could be the non ephemeral nature of the PULSE. You signal down then you clear it by signaling up. If UP never happens you clear it at next (or 2nd next) LSDB full sync. I think this is proper to discuss both on the list and in the draft how to use it instead of leaving lots of challenges and interpretations to potential users/apps of this new extension. Many thx, R. On Wed, Jan 5, 2022 at 1:16 PM Peter Psenak <ppse...@cisco.com> wrote: > Robert, > > On 05/01/2022 12:57, Robert Raszuk wrote: > > if the router supports NSR or NSF such event will be invisible to > other > > routers, including ABR. Without these mechanisms the neighboring > > routers > > would tear down the adjacency anyway. > > > > > > So are you going to add to the draft special handling in this case ? > > we could mention it, but there is noting special about it really. > > > > > There is difference between losing adj due to restart for few seconds > > and keeping the damage within an area to blasting PULSES globally when > > it happens. > > same happens without a pulse today without a summarization - ABR > propagates the loss of PE prefix(es) to remote areas/domains. ABR does > not distinguish between the "few seconds restart" and permanent loss if > the router losses adjacencies. > > > > > Note also that even if we loose adj data plane can stay intact in some > > area topologies with GR enabled. > > from the control plane perspective, loosing adjacency means loosing > reachability and we react. We are not changing any of it. > > > > > So it is becoming quite interesting to capture this or if not provide > > sufficient and easy guidelines to operators to tune PULSEs to match > > their network. > > > > yes, the ingress PE reacting to Pulse would have to re-evaluate the > BGP > > best paths of affected prefixes after the pulse expiration. > > > > > > "would have to" sounds like a normative MUST to me. Is this going to be > > also captured in the new version of the draft ? > > > the draft is specifying IGPs extensions for pulse. The handling of the > pulse by the interesting apps is not something we should be specifying > in this draft. Also such handling is a local behavior on the ingress PE. > > But we can certainly add some non normative guidelines and > recommendations for BGP handling of Summary Component Reachability Loss > Pulse. > > thanks, > Peter > > > > > Thx, > > R. > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
