Hi Peter, In your example of GRE between PEs .. what is the purpose of this GRE ? Isn't it to connect services advertised via BGP ?
In any case perhaps one size does not fit all. Maybe some networks can use BGP signalling (withdraws), maybe other will like to see bad even notification in IGPs. Considering that node down events are extremely rare in practice (what really happens much more often is link down/flap or node brownouts) this solution will not harm the network even if flooded blind everywhere. So my email was not to discourage progressing draft-ppsenak-lsr-igp-event-notification-00 <https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3> it was more triggered by Acee's question to use BFD end to end as an alternative. >From those two drafts I agree that your proposal is more generic and at the WG adoption call (if ever happens) you have my vote ;). Cheers, R. On Wed, Oct 13, 2021 at 10:42 AM Peter Psenak <ppsenak= [email protected]> wrote: > Hi Acee, > > On 12/10/2021 21:05, Acee Lindem (acee) 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. > > just for the record, I offered authors of "Prefix Unreachable > Announcement" co-authorship on "Event notification" draft, arguing the > the event base solution addresses their use case in a more elegant and > scalable way. They decided to push their idea regardless. > > > > > 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? > > we have looked at the various options. None of the existing ones would > fit the large scale deployment with summarization in place. Using BFD > end to end to track reachability between PEs simply does not scale. > > Some people believe this should be solved by BGP, but it is important to > realize that while the problem statement at the moment is primarily > targeted for egress PE reachability loss detection for BGP, the > mechanism proposed is generic enough and can be used to track the peer > reachablity loss for other cases (e.g GRE endpoint, etc) that do not > involve BGP. > > We went even further and explored the option to use completely out of > band mechanism that do not involve any existing protocols. > > Simply, the advantage of using IGP is that it follows the existing MPLS > model, where the endpoint reachability is provided by IGPs. Operators > are familiar with IGPs and know how to operate them. > > On top of the above, IGP event notification can find other use cases in > the future, the mechanism defined in draft is generic enough. > > > > 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 have listed some requirements at: > > > https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-event-notification-00#section-3 > > From my perspective the solution should be optimal in terms of amount > of data and state that needs to be maintained, ideally separated from > the traditional LS data. I also believe that having a generic mechanism > to distribute events has it own merits. > > thanks, > Peter > > > > > 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
