I agree with Les. We are rushing to the solutions for the none universal problems that should not be solved by IGP. There are many ways to implement the network connections, why design IGP areas in so strange manner and let the IGP behave BGP like?
Aijun Wang China Telecom > On Dec 8, 2021, at 11:23, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > (Subject was: RE: [Lsr] WG Last Call for "IS-IS Flood Reflection" > -draft-ietf-lsr-isis-flood-reflection-05) > > (Changing the subject as Acee has suggested that discussion of the problem > space is inappropriate for the WG LC thread) > > Tony (and everyone) – > > This isn’t the first contentious issue the WG has considered. By way of > comparison (hopefully a useful one), a number of folks (including you and I) > are participating in another contentious issue – fast-flooding. > But for fast-flooding there is broad WG consensus that fast-flooding is > something that IS-IS should do. The contentious part is regarding what is the > best way to do it. And we are proceeding in a manner where different > algorithms are being tested while still in the WG document stage. And there > is hope (still TBD) that multiple algorithms may be able to interoperate. > > Here, I am not convinced that there is broad WG consensus that this is a > problem that the IGPs should solve. (If I am wrong on that I presume the WG > members will let me know.) > And, we have multiple proposals, none of which have any hope of > interoperating with each other. > And we have had very little discussion about the problem space. (not your > fault – certainly you have been willing as have the authors of the competing > draft) > > So, at best, I think WG LC is premature. I would like to see more discussion > as to whether this is a problem that IGPs should solve as well as a general > look at how this might be done with and/or without the IGPs. > And since all of the proposed solutions have been allocated code points, they > can continue to gain implementation/deployment experience in the meantime. > Therefore, I do not see that we need to make this choice now. > > I realize that you are not the one asking for WG LC and I don’t know when you > plan to do so and I am not trying to influence you in that regard. > But for me, WG LC is at best premature. > > As regards you trying to solve a real world customer ask, I was aware of > that. And I believe the authors of flood-reflection can make the same claim. > > Thanx for listening, > > Les > > > > > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Tuesday, December 7, 2021 2:53 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Acee Lindem (acee) <[email protected]>; Acee Lindem (acee) <[email protected]>; > [email protected] > Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" > -draft-ietf-lsr-isis-flood-reflection-05 > > > Les, > > And in response to Tony Li’s statement: “…the IETF is at its best when it is > documenting de facto standards” > > 1) I fully believe that our customers understand their requirements(sic) > better than we (vendors) do. But that does not mean that they understand what > is the best solution better than we do. > When a customer comes to me and says “Can you do this?” my first response is > usually “Please fully describe your requirements independent of the solution.” > > > If it matters at all, Area Proxy is the result of a customer explaining his > issues and my attempt to address them. I’m sorry you don’t like my proposal. > > > 2)Not clear to me that there is an existing “de facto standard” here – which > is reinforced by the fact that we have so many different solutions proposed. > > > There isn’t. Yet. Thus, it’s not time to pick one vs. the other. > > Tony > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
