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> 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> 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] >> >> *On Behalf Of *tony...@tony.li >> >> >> *Sent:* Wednesday, September 2, 2020 12:07 PM >> >> >> *To:* Gengxuesong (Geng Xuesong) <gengxues...@huawei.com> >> >> >> *Cc:* Huaimo Chen <huaimo.c...@futurewei.com>; Les Ginsberg (ginsberg) >> <ginsberg=40cisco....@dmarc.ietf.org>; Les Ginsberg <ginsb...@cisco.com>; >> Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; 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 >> >> >> https://www.ietf.org/mailman/listinfo/lsr >> >> >> > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
