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

From: [email-masked]
Date: Tue, 1 Sep 2020 08:01:49 -0700

Hi Huaimo,

> > The question I and others have asked is “what can we do with zones that cannot be done with areas?”.
>     [HC]: IS-IS TTZ or say Zone is one of a few drafts which experiment/explore new ways for scalability. These new ways may be simpler and have some other features.

The English language is a remarkable creature. Enormously complex and intricate. Maddeningly irregular and inconsistent.

The word “may” is a fine example. It denotes the possibility of a relationship between two concepts, but says nothing about the likelihood of the reality. As a result, it can be used to
conjoin arbitrary entities.

Trump MAY win the election.

COVID MAY cure cancer.

The world MAY end tomorrow.

Any sentence with the word MAY in it is equally true if you replace “MAY” with “MAY NOT”.

Zones MAY be simpler.  Zones MAY NOT be simpler.  It’s up to you to convince us that they are simpler, better, or provide some value above and beyond the concepts that we have now.
The obligation is on you to make this point.

So far, you haven’t.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Sep 2020 17:18:01 +0200

>
>     [HC]: IS-IS TTZ or say Zone is one of a few drafts which
> experiment/explore new ways for scalability. These new ways may be simpler
> and have some other features.
>

While Tony very well explained the "may" part let me ask the "simpler"
part.

Simpler then what ?

Simpler when combined with existing levels of abstraction or when
taken alone in vaccume ?

The draft in question defines a new abstraction. But I would like to go
back to a very basic question:

What problem(s) are you solving ?

You say "new ways for scalability" - can you enumerate what is unscalable
in current areas or levels ?

Many thx,
Robert

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 2 Sep 2020 02:37:53 +0000

Hi Tony,

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?

Thanks
Xuesong

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 1, 2020 11:02 PM
To: Huaimo Chen <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Huaimo,

COVID MAY cure cancer.

So far, you haven’t.

Regards,
Tony

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 2 Sep 2020 03:51:12 +0000

Hi Tony,

    Assume that a big L1 area (say Area A1) is connected to backbone domain.
    Let us compare TTZ and Areas for scalability.

    Using TTZ, we need two steps below:
    1) configure a piece of Area A1, named P1, as a zone; and
    2) transfer P1 to a virtual node using one command or two.

    Using Areas, we need four steps below to split Area A1 into two L1 areas A11 and A12:
    1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
    2) add/configure a new area address on the routers in target Area A12;
    3) configure Attach bit for A11 or A12; and
    4) delete the old area address from the routers in Area A12.

    Using TTZ is simpler than using Areas.

Best Regards,
Huaimo

________________________________
From: Tony Li <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, September 1, 2020 11:01 AM
To: Huaimo Chen <[email-masked]>
Cc: Les Ginsberg <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Huaimo,

COVID MAY cure cancer.

So far, you haven’t.

Regards,
Tony

---

From: [email-masked]
Date: Tue, 1 Sep 2020 21:06:54 -0700

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…

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

---

From: [email-masked]
Date: Tue, 1 Sep 2020 21:09:46 -0700

Hi Huaimo,

>     Using TTZ is simpler than using Areas.

I’m not quite sure I follow you.  Are you arguing that simplicity is achieved through the minimum number of configuration steps?

If so, I’d like to introduce you to Arista CVP, our management platform, where all of this can be easily automated: 1 step.

Tony

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 2 Sep 2020 04:15:20 +0000

Hi Robert,

    There are three LSR drafts that experiment/explore new ways for scalability. IS-IS TTZ is one of them. The other two have been adopted as experimental.

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Sent: Tuesday, September 1, 2020 11:18 AM
To: Huaimo Chen <[email-masked]>
Cc: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; [email-masked] <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

While Tony very well explained the "may" part let me ask the "simpler" part.

Simpler then what ?

Simpler when combined with existing levels of abstraction or when taken alone in vaccume ?

The draft in question defines a new abstraction. But I would like to go back to a very basic question:

You say "new ways for scalability" - can you enumerate what is unscalable in current areas or levels ?

Many thx,
Robert

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 2 Sep 2020 04:58:08 +0000

Hi Tony,

    It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot be automated without people's planning. Some people need to spend their time in deciding where is the boundary between the two areas and selecting a router in the backbone domain for Attach bit for one of the two areas. These corresponds to step 1) and 3) for using Areas.

Best Regards,
Huaimo
Sent: Wednesday, September 2, 2020 12:09 AM

Hi Huaimo,

Tony

---

From: [email-masked]
Date: Tue, 1 Sep 2020 23:02:05 -0700

Hi Huaimo,

>     It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot be automated without people's planning. Some people need to spend their time in deciding where is the boundary between th…

Architectural decisions do take careful thought.  That seems to be a common requirement, regardless of mechanism.

Tony

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 2 Sep 2020 06:08:07 +0000

Hi Chairs and the WG,

I support the adoption of this document.

Cheers,
Tianran

From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: [email-masked]
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Based on the discussions in the last meeting and on the mailing list regarding draft-chen-isis-ttz-11, the chairs feel that there are enough differences with draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it independently on the experimental track.

These differences include abstraction at arbitrary boundaries and IS-IS extensions for smooth transition to/from zone abstraction.

We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. Please indicate your support or objection to adoption prior to Tuesday, September 2nd, 2020.

Thanks,
Acee and Chris

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 2 Sep 2020 08:00:19 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, September 2, 2020 12:07 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Xuesong,

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 2 Sep 2020 10:53:36 +0200

> people need to spend their time in deciding where is the boundary between
the two areas

Oh then I perhaps completely missed the value and power of TTZ.

It seems that in TTZ instead of careful planning of your abstractions the
plan is to randomly create zones and see what happens - is this right
reading of your explanation ?

Many thx,
R.

On Wed, Sep 2, 2020 at 6:58 AM Huaimo Chen <[email-masked]>
wrote:

> Hi Tony,
>
>     It seems that splitting L1 area A1 into two L1 areas A11 and A12
> cannot be automated without people's planning. Some people need to spend
> their time in deciding where is the boundary between the two areas and
> selecting a router in the backbone domain for Attach bit for one of the two
> areas. These corresponds to step 1) and 3) for using Areas.
>
> Best Regards,
> Huaimo
> ------------------------------
> *From:* Tony Li <[email-masked]> on behalf of [email-masked] <
> [email-masked]>
> *Sent:* Wednesday, September 2, 2020 12:09 AM
> *To:* Huaimo Chen <[email-masked]>
> *Cc:* Les Ginsberg <[email-masked]>; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]>; Acee Lindem (acee) <acee=
> [email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
> Hi Huaimo,
>
> I’m not quite sure I follow you.  Are you arguing that simplicity is
> achieved through the minimum number of configuration steps?
>
> If so, I’d like to introduce you to Arista CVP, our management platform,
> where all of this can be easily automated: 1 step.
>
> Tony
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 2 Sep 2020 11:03:58 +0200

>  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) <
[email-masked]> 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:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Wednesday, September 2, 2020 12:07 PM
> *To:* Gengxuesong (Geng Xuesong) <[email-masked]>
> *Cc:* Huaimo Chen <[email-masked]>; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>;
> Acee Lindem (acee) <acee=[email-masked]>; [email-masked]
> 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?
>
>
>
>
>
> 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.
>
>
>

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 2 Sep 2020 09:28:43 -0400

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 <[email-masked]> wrote:

>> the size of marketing
>> department. Them are not relevant to this thread.
>>
>>
>> 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.
>>
>>
>>
>> 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:[email-masked]]
>>
>> *On Behalf Of [email-masked]
>>
>>
>> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS
>> Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi Xuesong,
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 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?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: [email-masked]
Date: Wed, 2 Sep 2020 07:48:04 -0700

Hi Xueson,

> My intension was not to talk about math/engineering/marketing or compare the size of marketing department. Them are not relevant to this thread. 

You are the one who suggested we leave it up to the market…

> 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…

That’s what we’ve been trying to tell you all along:

- If there is a benefit to zones, it’s not clear to us.  You need to do a better job articulating that.

- The transition mechanisms seem awkward and painful. Can you reduce the complexity?

> 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…

Technology is all about maximizing benefits while minimizing costs.  This is why we don’t wire houses using gold and silver.

Yes, this does seem to be an endless argument.  Welcome to the IETF.

Regards,,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 2 Sep 2020 17:02:39 +0200

> - The transition mechanisms

Hmmm maybe I missed some explanations by authors, but to me concept of
zones is positioned as an addition to the concept of areas or levels - not
a replacement of those.

So when you say "transition" means that something existing no longer would
be in place after successful deployment of a new thing.

Here I am actually not sure if IGP domain could be only constructed with
zones without areas ?

Of course said all of the above I am still not seeing any value in the
proposed new abstraction regardless if such abstraction would be positioned
to exist in parallel to areas/levels or by definition be nested within the
area/level.

r.

On Wed, Sep 2, 2020 at 4:48 PM <[email-masked]> wrote:

> Technology is all about maximizing benefits while minimizing costs.  This
> is why we don’t wire houses using gold and silver.
>

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 3 Sep 2020 04:55:04 +0000

Hi Robert,

>It seems that in TTZ instead of careful planning of your abstractions the plan is to randomly create zones and see what happens - is this right reading of your explanation ?

[HC]: TTZ provides users flexibility to define a zone and abstract the zone to a single node for scalability. Users can define a zone (a block of an area) and the zone can be any block of the area that users decide. Thus, using TTZ seems simpler than using Areas for scalability. It uses less planning effort and less configurations.
For example, given a big L1 area (say area A1) connected to backbone, users can define a zone in area A1 and abstract it to a node for scalability. When area A1 is split into two L1 areas A11 and A12 using Areas, the planning effort includes two parts: 1) determining the boundary of A11 and A12 and 2) selecting a router for Attach bit. Since users can define any block of area A1 as a zone, the block for A11 can be defined as a zone and abstracted to a single node.
The planning effort using TTZ is just the first part of the planning effort using Areas, and is less.
For less configurations using TTZ, refer to
https://mailarchive.ietf.org/arch/msg/lsr/NxNJRUulSnGaR5PNBJv5x1kxUTw/

Best Regards,
Huaimo
________________________________
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, September 2, 2020 4:53 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked] <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>; [email-masked] <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

> people need to spend their time in deciding where is the boundary between the two areas

It seems that in TTZ instead of careful planning of your abstractions the plan is to randomly create zones and see what happens - is this right reading of your explanation ?

Many thx,
R.

On Wed, Sep 2, 2020 at 6:58 AM Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,

Best Regards,
Huaimo
________________________________
From: Tony Li <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 2, 2020 12:09 AM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Huaimo,

Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
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%7C346e8ba1b8b140e581ab08d84f1db372%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346336293628016&sdata=0f4iui6ePeVSWMnsved8IdE7zKpKkWm0veMoHOcSuZ4%3D&reserved=0>

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 3 Sep 2020 05:16:55 +0000

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 <[email-masked]>
Sent: Wednesday, September 2, 2020 5:03 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: [email-masked] <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

* 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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tony,

Thanks

Xuesong

From: Tony Li [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 2, 2020 12:07 PM
To: Gengxuesong (Geng Xuesong) <[email-masked]<mailto:[email-masked]>>
Cc: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>>; Les Ginsberg <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Xuesong,

Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
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>

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 3 Sep 2020 05:39:41 +0000

Hi Robert,

    The "transition" means transfer/abstract a zone to a single virtual node smoothly and roll the virtual node back to the zone smoothly.
    TTZ draft contains a solution for the "transition", which reduces the traffic interruption when a zone is abstracted to a node and vice versa.

    The values of TTZ include: 1) Less traffic interruption and 2) Simpler operations (refer to https://mailarchive.ietf.org/arch/msg/lsr/H8muAnPwnxVa9d_8FY7x3rofKLw/)

Best Regards,
Huaimo
________________________________
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, September 2, 2020 11:02 AM
To: Tony Li <[email-masked]>
Cc: Gengxuesong (Geng Xuesong) <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>; Huaimo Chen <[email-masked]>; [email-masked] <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

> - The transition mechanisms

Hmmm maybe I missed some explanations by authors, but to me concept of zones is positioned as an addition to the concept of areas or levels - not a replacement of those.

So when you say "transition" means that something existing no longer would be in place after successful deployment of a new thing.

Here I am actually not sure if IGP domain could be only constructed with zones without areas ?

Of course said all of the above I am still not seeing any value in the proposed new abstraction regardless if such abstraction would be positioned to exist in parallel to areas/levels or by definition be nested within the area/level.

r.

On Wed, Sep 2, 2020 at 4:48 PM <[email-masked]<mailto:[email-masked]>> wrote:

Hi Xueson,

Regards,,
Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
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%7C71d83d2690d64fd496e108d84f51439b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346557737088426&sdata=a0CeD%2Fa2B6lsHgM7PaHZkQ1l%2FKu704jhY3XvOdXm0uY%3D&reserved=0>

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 3 Sep 2020 06:03:13 +0000

Hi Tony,

>- If there is a benefit to zones, it’s not clear to us.  You need to do a better job articulating that.
[HC]: Using zone/TTZ for scalability seems simpler than using Areas. It uses less planning efforts and less configurations (refer to https://mailarchive.ietf.org/arch/msg/lsr/H8muAnPwnxVa9d_8FY7x3rofKLw/ for some details).

>- The transition mechanisms seem awkward and painful. Can you reduce the complexity?
[HC]: Yes. We can reduce the complexity of the transition mechanisms and have a simple solution.

Best Regards,
Huaimo
________________________________
From: Tony Li <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Wednesday, September 2, 2020 10:48 AM
To: Gengxuesong (Geng Xuesong) <[email-masked]>
Cc: Huaimo Chen <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Les Ginsberg <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

Hi Xueson,

Regards,,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 3 Sep 2020 10:43:43 +0200

Hi Huaimo,

> > Users can define a zone (a block of an area) and the zone can be any
> block of the area that users decide. Thus, using TTZ seems simpler than
> using Areas for scalability. It uses less planning effort and less
> configurations.
>
>
Q1 - Can zones overlap ? IE. can any node be in the same time in
multiple zones ?

Q2 - Can zones be nested ?

Q3 - Can zone boundary span across two or more areas ?

> [HC]:  The requirement for flooding of host routes domain wide is
considered in section 4.1.3 of TTZ draft.

Well all it says that loopbacks can be included. That in no way addresses
the scalability aspect if those loopbacks are to be flooded domain wide
anyway.

Thx,
R.

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 3 Sep 2020 21:06:52 +0000

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 <[email-masked]> On Behalf Of Gyan Mishra
Sent: Wednesday, September 2, 2020 6:29 AM
To: Robert Raszuk <[email-masked]>
Cc: Les Ginsberg <[email-masked]>; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; Gengxuesong (Geng Xuesong) <[email-masked]>; Huaimo Chen <[email-masked]>
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

Thx,
R.

Hi Tony,

My intension was not to talk about math/engineering/marketing or compare the size of marketing

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:[email-masked]<mailto:[email-masked]>]

On Behalf Of [email-masked]<mailto:[email-masked]>

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?

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.

Tony

Lsr mailing list

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

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

---

From: John E Drake <[email-masked]>
Date: Thu, 3 Sep 2020 23:17:57 +0000

Hi,

The proponents of this draft seem to be arguing by repeated assertion.

Yours Irrespectively,

John

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Thursday, September 3, 2020 5:07 PM
To: Gyan Mishra <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: Les Ginsberg <[email-masked]>; [email-masked]; Acee Lindem (acee) <acee=[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; [email-masked]; Gengxuesong (Geng Xuesong) <[email-masked]>; Huaimo Chen <[email-masked]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[External Email. Be cautious of content]

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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/NxNJRUulSnGaR5PNBJv5x1kxUTw/__;!!NEt6yMaO-gk!TIMeNJoxm1YXWPZsv8ovRxr0GAuD2K0kUxab-4AGBoYswyrC5StUx-01gNrlRl0$>).
-Kiran

Kind Regards

Gyan

Thx,
R.

Hi Tony,

Thanks

Xuesong

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.

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

https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!TIMeNJoxm1YXWPZsv8ovRxr0GAuD2K0kUxab-4AGBoYswyrC5StUx-01AcIoEhA$>

Lsr mailing list

https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!TIMeNJoxm1YXWPZsv8ovRxr0GAuD2K0kUxab-4AGBoYswyrC5StUx-01EM00Abw$>
--

[Image removed by sender.]<https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TIMeNJoxm1YXWPZsv8ovRxr0GAuD2K0kUxab-4AGBoYswyrC5StUx-01ua5CV-E$>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 4 Sep 2020 03:21:44 +0000

Hi Robert,

    My answers/explanations to your questions/comments are inline below with prefix [HC2].

Best Regards,
Huaimo
Sent: Thursday, September 3, 2020 4:43 AM

Hi Huaimo,

> Users can define a zone (a block of an area) and the zone can be any block of the area that users decide. Thus, using TTZ seems simpler than using Areas for scalability. It uses less planning effort and less configurations.

Q1 - Can zones overlap ? IE. can any node be in the same time in multiple zones ?
[HC2]: Yes.

[HC2]: No for now.

[HC2]: No.

> [HC]:  The requirement for flooding of host routes domain wide is considered in section 4.1.3 of TTZ draft.

Well all it says that loopbacks can be included. That in no way addresses the scalability aspect if those loopbacks are to be flooded domain wide anyway.
[HC2]: We will work on improving it.

Thx,
R.