Yup, that can be done. But I see steps such as ATT configuration as an additional effort when splitting areas. With TTZ, this propagation is not needed. Given that an operator has chosen to split the area anyway, TTZ process and config steps are relatively simple explained earlier (https://mailarchive.ietf.org/arch/msg/lsr/NxNJRUulSnGaR5PNBJv5x1kxUTw/). -Kiran
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Gyan Mishra Sent: Wednesday, September 2, 2020 6:29 AM To: Robert Raszuk <rob...@raszuk.net> Cc: Les Ginsberg <ginsb...@cisco.com>; tony...@tony.li; Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org; Gengxuesong (Geng Xuesong) <gengxues...@huawei.com>; Huaimo Chen <huaimo.c...@futurewei.com> Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt Since careful planning and design is required to split a L1 Area into L1a L1b using TTZ as this is a major effort to plan out. It maybe easier as part of the planning effort to just create two separate L1 areas that have different L1/L2 attachment points for the attach bit to be propagated. Use existing ISIS machinery to now create two new smaller L1 areas. Kind Regards Gyan On Wed, Sep 2, 2020 at 5:04 AM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: > 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%7Ckiranm%40futurewei.com%7Cbf82756deb714596bfd108d84f444b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346502051754821&sdata=wdakWTmkB8JIKCqDCBdMW56irI8Il6rNAnzHPNzd7IA%3D&reserved=0> _______________________________________________ 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%7Ckiranm%40futurewei.com%7Cbf82756deb714596bfd108d84f444b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346502051764815&sdata=3pldswAxXCXRwWk7hUb9HcE6yENHFAGplsblbji1q9w%3D&reserved=0> -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=02%7C01%7Ckiranm%40futurewei.com%7Cbf82756deb714596bfd108d84f444b6a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346502051764815&sdata=Fk%2F2rg%2FZ4gsqMesojLS%2BL0Wt9sF6zLUgKe9kwrMfPZo%3D&reserved=0> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr