Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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) <
> [e-mail]> 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:[e-mail]]
>>
>> *On Behalf Of *[e-mail]
>>
>>
>> *Sent:* Wednesday, September 2, 2020 12:07 PM
>>
>>
>> *To:* Gengxuesong (Geng Xuesong) <[e-mail]>
>>
>>
>> *Cc:* Huaimo Chen <[e-mail]>; Les Ginsberg (ginsberg)
>> <ginsberg=[e-mail]>; Les Ginsberg <[e-mail]>;
>> Acee Lindem (acee) <acee=[e-mail]>; [e-mail]
>>
>>
>> *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
>>
>>
>> [e-mail]
>>
>>
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
>>
>
> _______________________________________________
>
> Lsr mailing list
>
> [e-mail]
>
> 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