Dear Aijun, Let me reply to other your other comments ...
> In both cases such an event will likely be detected using BFD (if we are > talking about unreachability of a BGP or IGP peer). > > *[WAJ] No. Link or Node Failures are not detected via BFD within one IGP > domain. It just rely on the normal IGP flooding procedures. Once the ABRs > receive the updated LSA, they will make the calculation and find the > missing prefixes.* > Normal IGP flooding must be triggered by detection of failure. In this case node failure. If you intend to rely on IGP keepalives to detect the adj down from the node immediately connected to the PE(s) then clearly we have different network connectivity restoration goals in place. > Neither of the drafts mentioned here replaces local BFD detection. > > *[WAJ] Deploy such mechanisms can replace the BFD for BGP configuration > between PEs that located in different IGP domains.* > I have never seen deployment of multihop BFD between PEs located in different IGP domains. > However IMO the natural signalling in this case would be to use BGP > itself. Here are the few reasons: > > *[WAJ] How the BGP peer be detected that the peer has been unreachable? > Via BFD for BGP?* > Yes. Just like adjacent IGP peer will. * detection time will be the same for IGP or BGP > > *[WAJ] It is the ABR’s summarization action hides the unreachable > prefixes, then BGP peers located in different IGP domains can’t know the > failure as quickly as IGP within the same domain.* > Not true. BGP is a recursive protocol and already propagate remote next hops in number of deployments. For example RFC3107 but not only. > * only those network elements which keep "interesting" state will be > notified > > *[WAJ] To be more accurate, your above statement should be **【* only > those network elements which keep "interesting" state will act upon the PUA > messages.】* > Nope. I meant that if I have decent size network with 10 areas and use L3VPNs. Only those PEs in some areas will get withdraws which keep routes from given src PEs. No other PE (nor P for that matter) will get any control message about it. * speed of withdraw can be argued to be as fast as IGP flooding especially > considering hierarchical IGP design > > *[WAJ] When we let ABR send the PUA messages, not hide them, the speed of > withdraw can certainly be accelerated.* > The withdraw propagation via 2 or 3 RRs IMO will be much faster then IGP flooding via say 20 IGP nodes. > * withdraws can be easily aggregated (when we loose PE single prefix can > be used to remove all paths advertised by given PE) > > *[WAJ] This is the effects PUA mechanism. when the BGP peer receives the > PUA message that includes the PE itself, all the path advertised by the > given PE can certainly be removed.* > As stated this is pretty infrequent that PE goes down. Sure there are also poorly designed networks with PEs attached over single link to the P nodes. Contrary to this if focus on using BGP for such signalling not only we can propagate node down but also any other failure affecting subset of services hosted by such PEs. > * withdraws can be injected as the next hop /32 or /128 prefixes and > remote next hop validation can be set not to consider less specific routes > to resolve next hops (in any case due to MPLS data plane host routes are > used in many networks today to resolve BGP service routes to LSPs in spite > of efforts to make this more scalable). > > *[WAJ]This the effect of PUA mechanism.* > Not sure you got the point, but yes both methods IGP or BGP can be used. It is just a matter of right judgement of pros and cons of each. And as I wrote to Peter maybe one size does not fit all. Only when we prove that BGP based solutions are not sufficient we > could/should explore moving such signalling to IGPs. > > > *[WAJ] Do the above responses prove the BGP based solution are not > sufficient?* > No. They are sufficient if supported by the network elements and deployed correctly. Cheers R. > > > Kind regards, > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) <acee= > [email protected]> wrote: > > Speaking as WG Chairs: > > > > The authors of “Prefix Unreachable Announcement” have requested an > adoption. The crux of the draft is to signal unreachability of a prefix > across OSPF or IS-IS areas when area summarization is employed and prefix > is summarised. We also have “IS-IS and OSPF Extension for Event > Notification” which can be used to address the same use case. The drafts > take radically different approaches to the problem and the authors of both > drafts do not wish to converge on the other draft’s method so it is > understandable that merging the drafts really isn’t an option. > > > > Before an adoption call for either draft, I’d like to ask the WG: > > > > 1. Is this a problem that needs to be solved in the IGPs? The use case > offered in both drafts is signaling unreachability of a BGP peer. Could > this better solved with a different mechanism (e.g., BFD) rather than > flooding this negative reachability information across the entire IGP > domain? > > 2. Assuming we do want to take on negative advertisement in the IGP, > what are the technical merits and/or detriments of the two approaches? > > > > We’ll reserve any further discussion to “WG member” comments on the two > approaches. > > > > Thanks, > Acee and Chris > > > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
