Aijun - I appreciate the continued dialogue.
You no doubt remember that Peter and I discussed PUA with you and co-authors several times over the years (at your kind invitation) - even before you had submitted the draft. We raised the same concerns with you then that I have mentioned earlier in this thread. None of the changes you have made have altered the basic mechanism that you use - so my objections remain the same. And that isn’t going to change...I don’t think PUA is a good solution. The rest of your argument seems to be that we should move forward w the PUA solution just because the draft has been around for a long time. Sorry, that isn’t a valid argument. Either the WG thinks PUA is good solution or it doesn't - that is the only basis on which a decision to adopt/not adopt should be made. The fact that you keep refreshing/updating the draft carries no weight. Les > -----Original Message----- > From: Lsr <[email protected]> On Behalf Of Aijun Wang > Sent: Wednesday, October 13, 2021 7:50 PM > To: 'Les Ginsberg (ginsberg)' <[email protected]>; 'Acee > Lindem (acee)' <[email protected]>; 'Peter Psenak' > <[email protected]>; [email protected] > Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF > Extension for Event Notification" > > Hi, Les: > > Thanks for your invitation. We are considering how to merge our directions > to the same aim. > > The reason that we want to finalize the PUA solution is due to it has been > discussed intensely on the previous IETF meetings and on the mail list.(we > start the discussion on October 2019, two years passed, now in version 07) > We have changed and updated the draft a lot to reflect the comments from > the LSR experts, including the comments from you. > The use cases, solution procedures are almost finished, then we think it is > time to start the adoption call for PUA draft. > For the remaining questions, we think we have plenty of time to solve it after > the adopt > > But for "IS-IS and OSPF Extension for Event Notification" draft, it just began > the travel for the standardization activities. > I think it is one alternative solution to the PUA draft, but as we have seen > the > comments on the list, whether to open the gate for the event notification > mechanism within IGP is needed to further intense discussion. > There may be some hidden problems has not been investigated for this > direction. > > And, there is no any restriction within IETF that we should rely on one > solution to solve the same problem. Think about how many solutions exist > for the Traffic Engineering requirements? > Even within LSR WG, we have flooding reduction, flooding reflection and TTZ > solutions for the similar problems. > > We have never mixed them for discussion and compare. There is seldom > solutions can satisfy all our preferences. > > So, in conclusion, I recommend to standardize firstly the PUA draft, and then > to discuss whether to open the gate for the event notification mechanism > within IGP. > Anyway, for the general solution, currently we have only the same use case > in mind as that in PUA draft. > > We are also kind to invite you, Peter, Acee to participate the PUA solution, > to > solve the problems that you are worrying. Other LSR experts(Tony Li, Greg, > Robert, Jeff etc.) are also welcome > The design, implementation, deployment experiences of PUA mechanism > can certainly give the guides for the more general solution for further > notification event. > And, I still think PUA solution is the easiest way to solve the problem, I > think > all of your concerning points will emerge later in "IS-IS and OSPF Extension > for Event Notification" draft. > > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: [email protected] <[email protected]> On Behalf Of Les > Ginsberg (ginsberg) > Sent: Thursday, October 14, 2021 2:44 AM > To: Acee Lindem (acee) <[email protected]>; Peter Psenak > <[email protected]>; [email protected] > Subject: Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF > Extension for Event Notification" > > 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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
