> On Jul 16, 2020, at 11:18 PM, Tianran Zhou <[email protected]> wrote: > > Thanks. I am really glad to understand the LSR chair's thoughts. > Well OK. I understand LSR would like a high bar for IGP extension. > But your comparison with " research WG or a technical journal " makes no > sense. It's common sense. > And your statement on the complexity twisted too many none engineer reasons. > I would like the IETF to be more pure on technique.
[As a general IETF participant] I believe we all would like this, but real-world dynamics impose none-the-less. > Anyway, I respect the tradition of this WG. > I just want to know if the WG request for interop and implementation report > for every draft? [chair hat] We always prefer to have this. We do not always get it, unfortunately. Thanks, Chris. > > Thanks, > Tianran > > -----Original Message----- > From: Christian Hopps [mailto:[email protected]] > Sent: Thursday, July 16, 2020 7:54 PM > To: Tianran Zhou <[email protected]> > Cc: Christian Hopps <[email protected]>; Henk Smit <[email protected]>; > [email protected]; Huaimo Chen <[email protected]> > Subject: Re: [Lsr] Request WG adoption of TTZ > > My comments about what the WG should be doing are "As WGChair", I'm not > commenting directly on TTZ, but on the broader comments/questions below. > >> On Jul 16, 2020, at 6:19 AM, Tianran Zhou <[email protected]> wrote: >> >> Hi Henk, >> >> Thanks very much for your long email. >> I fully agree with what you said on the criterion. This is generally always >> correct. >> But still you cannot score a draft with it. >> That means I can probably say most of the IETF RFCs has no use. >> I can also list one hundred RFCs that is not implemented. > > This is not what we strive for in LSR. > >> Are you going to obsolete them all? > > No, but we as a WG can strive to not contribute to this problem. > >> Who knows if they are useful in the future? > > LSR is not a research WG or a technical journal. > >> If you find it no use, just not to implement it. How could it make your >> system complex? > > This statement flies in the face of market realty. > > People who have to fill RFPs from prospective customers, knowing that they > are competing against other vendors filling those same RFPs out, can tell you > why you can't just "not implement RFCs" if you don't want to, even when they > will never actually be used by those same customers. The short answer is: > RFPs are very often not written by the engineers that actually build and run > the customer's networks; however, answers to RFPs have a direct impact on > which vendors products are purchased by the customers. > > So lots of unused RFCs leads to lots of useless code being written to win > customers, which then leads to huge protocol code bases that are too complex > and fragile, as well as protocols that are hard to comprehend and thus manage > properly, and so ultimately destabalize the internet -- we have failed at > this point. > > This may be less of an issue with other WGs; however, the IGPs are a > *critical* part of the internet infrastructure, and they need to be treated > as such, and we should strive to do so. > > Thanks, > Chris. > >> >> Best, >> Tianran >> >> -----Original Message----- >> From: Henk Smit [mailto:[email protected]] >> Sent: Thursday, July 16, 2020 4:46 PM >> To: Tianran Zhou <[email protected]> >> Cc: Huaimo Chen <[email protected]>; [email protected] >> Subject: Re: [Lsr] Request WG adoption of TTZ >> >> >> Hello Tianran, >> >> Warning, long email again. >> >>> What's the criterion to evaluate the benefit? >> >> As people have asked before, did any provider or enterprise ever use rfc8099 >> in their network ? >> >> As I wrote, one of my criteria is rfc1925. I like technology to be >> understandable. I like protocols to be (relatively) easy to implement. The >> more unused cruft there is, the further we get away from that goal. >> >> >> I'll give you an example. Did you, or your company ever implement rfc2973 ? >> That's mesh-groups in IS-IS. >> I'm sure some customers put it on their wishlist. >> Did any provider or customer ever use it ? >> I asked this question at my last job, and nobody knew the answer. I suspect >> nobody in the world ever used mesh-groups. >> >> Around the time I got in touch with IS-IS, in spring 1996, there was a >> problem that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). >> Both networks melted because of IS-IS. All routers in their networks were >> 100% cpu time running IS-IS, busy exchanging LSPs. While no progress was >> made. The only solution was to reboot all routers in the backbone at the >> same time (several hundred routers). >> This happened more than once in both networks. >> >> To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 >> was written. However, a short while later I became the sole IS-IS programmer >> for that router vendor. I was able to reproduce the problem in the lab. >> I then realized what the issue was. A fix of 10 lines of extra code fixed >> the problem. No customer ever reported those meltdowns again. That fix was >> the real solution. >> Not writing another RFC. >> >> In the mean-time, we have an extra RFC, about mesh-groups. >> Every book and manual on IS-IS has to spent time explaining what mesh-groups >> are. Every vendor has to implement it. >> Even when nobody in the world is using it. Mesh-groups were a superfluous >> idea. What I (and many others) are saying is that we don't want to specify >> and implement unnecessary things. >> Even when nobody is using such a thing, it will live on forever. >> >>> What I see the TTZ does have benefit. >> >> Yes, TTZ and proxy-areas have benefit. Nobody is disagreeing. >> >> But what people don't like is the new concept of a zone. >> If you can abstract exactly one area into exactly one proxy-LSP, that is >> good enough for 99.9 % of cases. In OSPF it is harder to split or merge an >> area. In IS-IS it is a lot easier. So a network operator can design and >> change his areas first. And then implement proxy-areas as she/he wishes. >> Without much downtime. >> >> If we introduce the concept of a "zone", someone is going to have to explain >> that to everybody in the world who uses IS-IS. >> Have you ever taught a class on IS-IS to people who don't know routing >> protocols very well ? >> >>> I am also wandering how it hurts the protocol in the long run ? >> >> Adding stuff that nobody uses makes everything more complex. >> I know it seems as if the goal over the last 15 years was to make every >> thing more complex. So what's the problem with adding yet another RFC ? >> >> But I like simple things. >> >> henk. >> >> >> Tianran Zhou wrote on 2020-07-16 02:41: >> >>>> "Adding a new concept, with very little benefit, hurts the protocol >>>> in the long run. The ability to abstract an area, and not also a >>>> zone, is strong enough to be worthwhile, imho." >>> >>> Your conclusion here seems very subjective. >>> What's the criterion the evaluate the benefit? What I see the TTZ >>> does have benefit. >>> I am also wandering how it hurts the protocol in the long run? >>> .... >>> >>> Tianran >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
