Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps <[e-mail]>]

> On Jul 16, 2020, at 11:18 PM, Tianran Zhou <[e-mail]> 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:[e-mail]]
> Sent: Thursday, July 16, 2020 7:54 PM
> To: Tianran Zhou <[e-mail]>
> Cc: Christian Hopps <[e-mail]>; Henk Smit <[e-mail]>; [e-mail]; Huaimo Chen <[e-mail]>
> 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 <[e-mail]> 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:[e-mail]]
>> Sent: Thursday, July 16, 2020 4:46 PM
>> To: Tianran Zhou <[e-mail]>
>> Cc: Huaimo Chen <[e-mail]>; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr
>> 
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>