Hi Peter, I am familiar with solutions that guarantee sub-second defect detection in an IGP domain. But these are based on the single-hop BFD. Do you mean that a standard-based IGP without any BFD involvement can guarantee sub-second detection of a failure in the domain? Would be interesting to learn about that and I much appreciate any reference or a pointer.
Regards, Greg On Wed, Oct 13, 2021 at 6:41 AM Peter Psenak <[email protected]> wrote: > Greg, > > On 13/10/2021 15:36, Greg Mirsky wrote: > > Hi Aijun, > > thank you for your quick response. Please find my further notes in-line > > below tagged GIM>>. > > > > Regards, > > Greg > > > > On Tue, Oct 12, 2021 at 9:06 PM Aijun Wang <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi, Greg:____ > > > > __ __ > > > > The defect detection time should be same as the IGP flooding speed. > > > > GIM>> I think that that would not be the only component that > > contributes to the overall detection delay. An instance of IGP needs > > something to detect the local failure that triggers the LSA update and > > flooding. AFAIK, if that process is based on IGP, it is in the > > single-second, at the minimum, range. As a result, that time will > > determine overall time to detect and propagate the notification of a > > defect in the IGP domain. > > > > It can achieve such goals via the PUA mechanism.____ > > > > Or else, we must depends on other mechanism, such as BFD, which > > requires configuration overhead, and the process pressure especially > > when the timer is decreased in multi-hop BFD mode. > > > > GIM>> I agree that using an additional protocol increases complexity. On > > another hand, if the IGP-based solution cannot guarantee the required > > defect detection time, it seems that an operator is more likely to > > choose the BFD-based solution. > > the requirement here is not for sub-50ms, it has never been the case > with BGP PIC anyway. The target is sub-second which is doable with IGP > based solution. > > thanks, > Peter > > > > > ____ > > > > __ __ > > > > __ __ > > > > Best Regards____ > > > > __ __ > > > > Aijun Wang____ > > > > China Telecom____ > > > > __ __ > > > > *From:*[email protected] <mailto:[email protected]> > > <[email protected] <mailto:[email protected]>> *On Behalf Of > > *Greg Mirsky > > *Sent:* Wednesday, October 13, 2021 10:43 AM > > *To:* Aijun Wang <[email protected] > > <mailto:[email protected]>> > > *Cc:* [email protected] <mailto:[email protected]>; Robert Raszuk > > <[email protected] <mailto:[email protected]>>; Acee Lindem (acee) > > <[email protected] <mailto:[email protected] > >> > > *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS > > and OSPF Extension for Event Notification"____ > > > > __ __ > > > > Hi Aijun,____ > > > > could you help me to understand the requirement for defect > > detection time for the method you propose? Single seconds? Tens of > > seconds?____ > > > > __ __ > > > > Regards,____ > > > > Greg____ > > > > __ __ > > > > On Tue, Oct 12, 2021, 18:27 Aijun Wang <[email protected] > > <mailto:[email protected]>> wrote:____ > > > > Hi, Robert:____ > > > > ____ > > > > Answers to your comments are inline below.____ > > > > ____ > > > > ____ > > > > Best Regards____ > > > > ____ > > > > Aijun Wang____ > > > > China Telecom____ > > > > ____ > > > > *From:*[email protected] <mailto:[email protected]> > > <[email protected] <mailto:[email protected]>> *On Behalf > > Of *Robert Raszuk > > *Sent:* Wednesday, October 13, 2021 3:52 AM > > *To:* Acee Lindem (acee) <[email protected] > > <mailto:[email protected]>> > > *Cc:* [email protected] <mailto:[email protected]> > > *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and > > "IS-IS and OSPF Extension for Event Notification"____ > > > > ____ > > > > Hi Acee,____ > > > > ____ > > > > I would like to make a comment on your point #1. ____ > > > > ____ > > > > You said: ____ > > > > ____ > > > > "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)..."____ > > > > ____ > > > > That is not a very precise statement - simply due to the fact > > that to signal anything in any solution requires a peer to > > detect giben network event. ____ > > > > ____ > > > > 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./*____ > > > > ____ > > > > 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 do infer from your message that what was meant to be said was > > an alternative to support BFD sessions across areas/levels for > > example between PEs. Clearly that would get very ugly very > > quickly. ____ > > > > ____ > > > > 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?/*____ > > > > ____ > > > > * 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./*____ > > > > ____ > > > > * 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.__】_/*____ > > > > ____ > > > > * 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./*____ > > > > ____ > > > > * 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./*____ > > > > * 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./*____ > > > > ____ > > > > 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?/*____ > > > > ____ > > > > Kind regards,____ > > > > R.____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > ____ > > > > On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) > > <[email protected] > > <mailto:[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] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr____ > > > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr____ > > > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
