Hi Robert, > * IGP scalability can be easily solved with the additional levels of current > abstraction instead of introducing new types of abstraction into it. Ref: > draft-ietf-lsr-isis-extended-hierarchy [HC]: There are three LSR drafts that experiment/explore the new ways for scalability. Two of them have been adopted as experimental. TTZ is one of them on Adoption Poll now. It is better to adopt all three as experimental. https://mailarchive.ietf.org/arch/msg/lsr/KNh_3KAnBRqTEc6e-ziLzpokkZs/ (adopted email for draft 1) https://mailarchive.ietf.org/arch/msg/lsr/mv156bQSOqF6QuD1QHBozfxX590/ (adopted email for draft 2)
> * Most scaling aspects I have seen in practical deployments with IGPs are not > caused by the suboptimal protocol design. Those are caused by requirements > introduced by some transport technologies which (at least originally) > required flooding of host routes domain wide for exact match of FECs to > prefixes. I do not see how TTZs would address that aspect in any better way > than areas can. [HC]: The requirement for flooding of host routes domain wide is considered in section 4.1.3 of TTZ draft. Best Regards, Huaimo ________________________________ From: Robert Raszuk <rob...@raszuk.net> Sent: Wednesday, September 2, 2020 5:03 AM To: Gengxuesong (Geng Xuesong) <gengxues...@huawei.com> Cc: tony...@tony.li <tony...@tony.li>; Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; Les Ginsberg <ginsb...@cisco.com>; Huaimo Chen <huaimo.c...@futurewei.com>; lsr@ietf.org <lsr@ietf.org>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt > acknowledged problem (IGP scalability) Great so we see the problem description. This is progress ! Allow me to observe two points: * IGP scalability can be easily solved with the additional levels of current abstraction instead of introducing new types of abstraction into it. Ref: draft-ietf-lsr-isis-extended-hierarchy * Most scaling aspects I have seen in practical deployments with IGPs are not caused by the suboptimal protocol design. Those are caused by requirements introduced by some transport technologies which (at least originally) required flooding of host routes domain wide for exact match of FECs to prefixes. I do not see how TTZs would address that aspect in any better way than areas can. Thx, R. On Wed, Sep 2, 2020 at 10:00 AM Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>> wrote: Hi Tony, My intension was not to talk about math/engineering/marketing or compare the size of marketing department. Them are not relevant to this thread. I want to make clear about IETF process. In my understanding the document does not need to be perfect at this stage, as long as it is in the right direction to solve some acknowledged problem( IGP scalability). Comments will be helpful if it could provide ideas about how to improve. But IMO the discussion in the mailing list about this draft has gone off the rails of technology, including keeping challenging tradeoff between value and complexity, which seems reasonable at the first sight, but at this stage, has turned out to be a question with no right answer and may bring endless argument. Thanks Xuesong From: Tony Li [mailto:tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>] On Behalf Of tony...@tony.li<mailto:tony...@tony.li> Sent: Wednesday, September 2, 2020 12:07 PM To: Gengxuesong (Geng Xuesong) <gengxues...@huawei.com<mailto:gengxues...@huawei.com>> Cc: Huaimo Chen <huaimo.c...@futurewei.com<mailto:huaimo.c...@futurewei.com>>; Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>; Les Ginsberg <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt Hi Xuesong, Apologies first if I have missed any history of this discussion. But I’m not sure that we have to evaluate whether a method is “optimal” before WG adoption. Why not adopt some alternative solutions and leave the choice to industry/market? First off, this is engineering, not theoretical math. Optimal is not the issue. Heck, optimal isn’t even a goal. What we are looking for is value and value that outweighs the complexity. Leaving the choice to the market is a bad idea. The market does NOT make sound technical decisions. It makes pseudo-random decisions not based on technical merits. The canonical example here is VHS vs Betamax. Better technology lost. Second, the market is unduly influenced by marketing. The size of your marketing department exceeds the size of my entire (not tiny) company. And it’s still second to that of Cisco. Marketing does not make good technical and architectural decisions. That’s our job. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C0cbf1e96d7d24dc4b90a08d84f1f25f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346342484646408&sdata=lfW56nVOePzDn2CxQYZyE4Rv14vTy5Cmw%2FNIVULZOOk%3D&reserved=0>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
