> You should put your BGP solution out there as well. Well honestly I did not say anything new. All options I enumerated have been described in public a long time ago.
Some vendors support those already for years. Operators are free to select the best methods to design their BGP overlays which fits to their scale and connectivity restoration requirements. IMO what is missing is not protocol gaps, but proper configuration of already available features. Many thx, Robert. On Tue, Oct 12, 2021 at 11:02 PM Acee Lindem (acee) <a...@cisco.com> wrote: > Hi Robert, > > > > *From: *Robert Raszuk <rob...@raszuk.net> > *Date: *Tuesday, October 12, 2021 at 4:27 PM > *To: *Acee Lindem <a...@cisco.com> > *Cc: *"Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org>, " > lsr@ietf.org" <lsr@ietf.org> > *Subject: *Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and > OSPF Extension for Event Notification" > > > > Hi, > > > > > What are you worried about? Scaling? > > > > Yes if we were to establish BFD sessions between say 1000 PEs then each PE > would need to handle such a number of BFD sessions (as long as at least one > prefix comes with given PE's next hop). > > > > > > As you know those would be multihop BFD sessions running on REs/RPs which > often are not hardware accelerated as p2p BFD with line card offloading. > > > > > > > > Ok – I think BFD should be implement in the data plane like it is for > SDWAN tunnels (at least on the data center routers). But that is a > different discussion. > > > > > > Then honestly it is not obvious if in such case BFD adds real value as > compared to ICMP or UDP next hop periodic probing (as part of next hop > periodic reachability validation). > > > > Usage of BFD with protocols is standard. Alternatives would work as well. > You should put your BGP solution out there as well. > > > > Thanks, > > Acee > > > > Thx, > > Robert > > > > > > On Tue, Oct 12, 2021 at 10:15 PM Acee Lindem (acee) <a...@cisco.com> > wrote: > > Speaking as WG member: > > > > Hi Robert, > > > > I think you are envisioning a use case beyond section 3 in > https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ > where the unreachable prefix is the loopback of PE. If not, I don’t see > your concern with BFD between the PEs. What are you worried about? Scaling? > > > > In any case, we both agree that flooding this unreachability information > to everyone in the IGP domain is possibly not the best way to solve the > problem. > > > > Thanks, > > Acee > > > > *From: *Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk < > rob...@raszuk.net> > *Date: *Tuesday, October 12, 2021 at 3:52 PM > *To: *"Acee Lindem (acee)" <acee=40cisco....@dmarc.ietf.org> > *Cc: *"lsr@ietf.org" <lsr@ietf.org> > *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). > > > > Neither of the drafts mentioned here replaces local BFD detection. > > > > 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: > > > > * detection time will be the same for IGP or BGP > > * only those network elements which keep "interesting" state will be > notified > > * speed of withdraw can be argued to be as fast as IGP flooding especially > considering hierarchical IGP design > > * withdraws can be easily aggregated (when we loose PE single prefix can > be used to remove all paths advertised by given PE) > > * 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). > > > > Only when we prove that BGP based solutions are not sufficient we > could/should explore moving such signalling to IGPs. > > > > Kind regards, > > R. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 12, 2021 at 9:06 PM Acee Lindem (acee) <acee= > 40cisco....@dmarc.ietf.org> 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
