Hi Les, thank you for your consideration of my note. No, I am not saying "never". I agree with you that extending the discussion on the applicability of the proposed solution is helpful. Looking forward to that.
Regards, Greg On Wed, Oct 13, 2021 at 3:14 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Greg – > > > > The draft is introducing a new IGP mechanism to signal events. > > That does not mean that it should be used for any and all event > notifications. > > > > We don’t discuss the latter point in any detail in the draft – but it is > only V-00. 😊 > > > > The first use case (described in Section2) seems very appropriate for the > IGP. > > > > So, I agree with your point. We need to do a better job of describing > appropriate use cases. But, if you are arguing that we should NEVER do this > in the IGP then we are not in full agreement. > > > > Les > > > > *From:* Lsr <[email protected]> *On Behalf Of * Greg Mirsky > *Sent:* Wednesday, October 13, 2021 1:45 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* [email protected]; Peter Psenak <[email protected]>; > Acee Lindem (acee) <[email protected]> > *Subject:* Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and > OSPF Extension for Event Notification" > > > > Hi Les, et al., > > I've just read the draft-ppsenak-lsr-igp-event-notification. Event > notification is usually viewed as the function of the Fault Management OAM, > not of a control plane protocol. Thus, I find the idea of using an IGP > protocol to distribute event notifications troubling. One of my concerns is > with the ability to control the scope of who receives the notification. > Even though the proposal follows RFC 7356, it might still be too broad. In > my experience, usually only designated systems in a domain are to receive a > notification about the particular class of events. In fact, > a publish-subscribe model for event notification is seen as more suitable > than flooding. AFAIK, there are different solutions for publish-subscribe > event notifications using gRPC, Kafka, etc. > > > > Regards, > > Greg > > > > On Wed, Oct 13, 2021 at 11:44 AM Les Ginsberg (ginsberg) <ginsberg= > [email protected]> wrote: > > This thread is becoming "diverse". > We are trying to talk about many different solutions (IGP, BGP, BFD) - all > of which may be useful and certainly are not mutually exclusive. > > If we can agree that an IGP solution is useful, then we can use this > thread to set a direction for the IGP solution - which seems to me to be > something we should do independent of whether the other solutions are also > pursued. > > With that in mind, here is my input on the IGP solutions: > > PUA > ------- > > For me, the solution has two major drawbacks: > > 1)It tries to repurpose an existing (and fundamental) Reachability > Advertisement into an UnReachability advertisement under certain conditions > > The interoperability risks associated with this make me very reluctant to > go down this path. > And the use of the same advertisement to indicate Reachability and > Unreachability is IMO highly undesirable. > > 2)The withdrawal of the "Unreachability Advertisement" after some delay > (which is necessary) remains problematic despite the authors attempts to > address thus > > Event Notification > ------------------------ > > This avoids the drawbacks of PUA and is flexible enough to handle future > and unforeseen types of notifications. > > I would like to extend the offer already made by Peter to the authors of > PUA to join us and work on the Event Notification draft. > The authors of PUA certainly deserve credit for raising awareness of the > problem space and it would be good to have them working with us on a single > IGP solution. > > But PUA is not an alternative that I can support. > > Les > > > -----Original Message----- > > From: Lsr <[email protected]> On Behalf Of Acee Lindem (acee) > > Sent: Wednesday, October 13, 2021 9:49 AM > > To: Peter Psenak <[email protected]>; [email protected] > > Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF > > Extension for Event Notification" > > > > Hi Peter, > > > > See inline. > > > > On 10/13/21, 4:42 AM, "Peter Psenak" > > <[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. > > > > One solution to this problem would have definitely been better. > > > > > 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. > > > > It seems to me that scaling of BFD should be "roughly" proportional to > BGP > > session scaling but I seem to be in the minority. My opinion is based on > > SDWAN tunnel scaling, where BFD is used implicitly in our solution. How > > many other PEs does a BGP edge PE maximally peer with? > > Thanks, > > Acee > > > > > > 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 > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
