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

[Acee Lindem (acee)]

The WG adoption poll has completed.  There is both quite a bit of support for 
the document as well as some who have concerns for the necessity of the TTZ 
mechanisms. Given the support as well as the fact that the draft is 
experimental track, our reading is that we have sufficient basis for 
experimentation. As discussions of IS-IS area abstraction mechanisms have 
progressed, it has become apparent that we are not going to reach consensus on 
a single mechanism. It is our feeling that having multiple mechanisms adopted 
by the WG on the experimental track is preferable to WG paralysis.

Please republish the draft as draft-ietf-lsr-isis-ttz-00.txt with experimental 
status.

Acee and Chris



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Tuesday, August 18, 2020 at 10:17 AM
To: "lsr@ietf.org" 
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

Hi Robert,

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

Best Regards,
Huaimo

From: Robert Raszuk 
Sent: Thursday, September 3, 2020 4:43 AM
To: Huaimo Chen 
Cc: tony...@tony.li ; Les Ginsberg (ginsberg) 
; Les Ginsberg ; 
lsr@ietf.org ; Acee Lindem (acee) 

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

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.

Q2 - Can zones be nested ?
[HC2]: No for now.

Q3 - Can zone boundary span across two or more areas ?
[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.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[John E Drake]

Hi,

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

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Kiran Makhijani
Sent: Thursday, September 3, 2020 5:07 PM
To: Gyan Mishra ; Robert Raszuk 
Cc: Les Ginsberg ; tony...@tony.li; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; lsr@ietf.org; Gengxuesong (Geng Xuesong) 
; Huaimo Chen 
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

From: Lsr  On Behalf Of Gyan Mishra
Sent: Wednesday, September 2, 2020 6:29 AM
To: Robert Raszuk 
Cc: Les Ginsberg ; tony...@tony.li; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; lsr@ietf.org; Gengxuesong (Geng Xuesong) 
; Huaimo Chen 
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 
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) 
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) 
mailto:gengxues...@huawei.com>>


Cc: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Les 
Ginsberg mailto:ginsb...@cisco.com>>; Acee Lindem (acee) 
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.

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

[Kiran Makhijani]

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  On Behalf Of Gyan Mishra
Sent: Wednesday, September 2, 2020 6:29 AM
To: Robert Raszuk 
Cc: Les Ginsberg ; tony...@tony.li; Acee Lindem (acee) 
; Les Ginsberg (ginsberg) 
; lsr@ietf.org; Gengxuesong (Geng Xuesong) 
; Huaimo Chen 
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 
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) 
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) 
mailto:gengxues...@huawei.com>>


Cc: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Les 
Ginsberg mailto:ginsb...@cisco.com>>; Acee Lindem (acee) 
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=wdakWTmkB8JIKCqDCBdMW56irI8Il6rNAnzHPNzd7

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

[Robert Raszuk]

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.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

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  on behalf of tony...@tony.li 

Sent: Wednesday, September 2, 2020 10:48 AM
To: Gengxuesong (Geng Xuesong) 
Cc: Huaimo Chen ; Les Ginsberg (ginsberg) 
; Les Ginsberg ; Acee 
Lindem (acee) ; lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


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 scalability). Comments will be helpful 
if it could provide ideas about how to improve.


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 first sight, but at this stage, has 
turned out to be a question with no right answer and may bring endless argument.


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

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 
Sent: Wednesday, September 2, 2020 11:02 AM
To: Tony Li 
Cc: Gengxuesong (Geng Xuesong) ; Les Ginsberg 
(ginsberg) ; Les Ginsberg 
; Huaimo Chen ; lsr@ietf.org 
; Acee Lindem (acee) 
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 mailto:tony...@tony.li>> wrote:

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 scalability). Comments will be helpful 
if it could provide ideas about how to improve.


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 first sight, but at this stage, has 
turned out to be a question with no right answer and may bring endless argument.


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

___
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%7C71d83d2690d64fd496e108d84f51439b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346557737088426&sdata=a0CeD%2Fa2B6lsHgM7PaHZkQ1l%2FKu704jhY3XvOdXm0uY%3D&reserved=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

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 
Sent: Wednesday, September 2, 2020 5:03 AM
To: Gengxuesong (Geng Xuesong) 
Cc: tony...@tony.li ; Les Ginsberg (ginsberg) 
; Les Ginsberg ; 
Huaimo Chen ; lsr@ietf.org ; Acee 
Lindem (acee) 
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) 
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) 
mailto:gengxues...@huawei.com>>
Cc: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Les 
Ginsberg mailto:ginsb...@cisco.com>>; Acee Lindem (acee) 
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.safel

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

[Huaimo Chen]

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 
Sent: Wednesday, September 2, 2020 4:53 AM
To: Huaimo Chen 
Cc: tony...@tony.li ; Les Ginsberg (ginsberg) 
; Les Ginsberg ; 
lsr@ietf.org ; Acee Lindem (acee) 

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

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 
mailto:huaimo.c...@futurewei.com>> 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 mailto:tony1ath...@gmail.com>> on behalf 
of tony...@tony.li<mailto:tony...@tony.li> 
mailto:tony...@tony.li>>
Sent: Wednesday, September 2, 2020 12:09 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: Les Ginsberg mailto:ginsb...@cisco.com>>; Les Ginsberg 
(ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto: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 Huaimo,

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.


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
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%7C346e8ba1b8b140e581ab08d84f1db372%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346336293628016&sdata=0f4iui6ePeVSWMnsved8IdE7zKpKkWm0veMoHOcSuZ4%3D&reserved=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

> - 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  wrote:

>
> 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 scalability). Comments
> will be helpful if it could provide ideas about how to improve.
>
>
>
> 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 first sight, but at
> this stage, has turned out to be a question with no right answer and may
> bring endless argument.
>
>
>
> 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
>
> ___
> 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

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

[tony . li]

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 scalability). Comments will 
> be helpful if it could provide ideas about how to improve.


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 first sight, but at this stage, has 
> turned out to be a question with no right answer and may bring endless 
> argument.


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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

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  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) 
>>
>>
>> *Cc:* Huaimo Chen ; Les Ginsberg (ginsberg)
>> ; Les Ginsberg ;
>> Acee Lindem (acee) ; 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

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

[Robert Raszuk]

>  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) 
> *Cc:* Huaimo Chen ; Les Ginsberg (ginsberg)
> ; Les Ginsberg ;
> Acee Lindem (acee) ; 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

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

[Robert Raszuk]

> 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 
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  on behalf of tony...@tony.li <
> tony...@tony.li>
> *Sent:* Wednesday, September 2, 2020 12:09 AM
> *To:* Huaimo Chen 
> *Cc:* Les Ginsberg ; Les Ginsberg (ginsberg)
> ; Acee Lindem (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 Huaimo,
>
> 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.
>
>
>
> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gengxuesong (Geng Xuesong)]

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) 
Cc: Huaimo Chen ; Les Ginsberg (ginsberg) 
; Les Ginsberg ; Acee 
Lindem (acee) ; 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

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

[Tianran Zhou]

Hi Chairs and the WG,

I support the adoption of this document.

Cheers,
Tianran

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tony . li]

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


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

Tony

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

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  on behalf of tony...@tony.li 

Sent: Wednesday, September 2, 2020 12:09 AM
To: Huaimo Chen 
Cc: Les Ginsberg ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Hi Huaimo,

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.


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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

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  on behalf of Robert Raszuk 
Sent: Tuesday, September 1, 2020 11:18 AM
To: Huaimo Chen 
Cc: Les Ginsberg (ginsberg) ; Les Ginsberg 
(ginsberg) ; lsr@ietf.org ; Acee Lindem 
(acee) 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

[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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tony . li]

Hi Huaimo,

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


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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tony . li]

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

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

[Huaimo Chen]

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  on behalf of tony...@tony.li 

Sent: Tuesday, September 1, 2020 11:01 AM
To: Huaimo Chen 
Cc: Les Ginsberg ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gengxuesong (Geng Xuesong)]

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:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Tuesday, September 1, 2020 11:02 PM
To: Huaimo Chen 
Cc: Les Ginsberg (ginsberg) ; Les Ginsberg 
; lsr@ietf.org; Acee Lindem (acee) 

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


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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

>
> [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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[tony . li]

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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

Hi Les,

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

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, August 18, 2020 6:52 PM
To: Huaimo Chen ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org 
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Huaimo –



The question I and others have asked is “what can we do with zones that cannot 
be done with areas?”.



>From the day several years ago when IS-IS TTZ was first presented,  your 
>answer has been “with zones you can hitlessly alter the topological 
>boundaries”.

My response has consistently been “we can already do that with areas”.

If you want to justify zones, you then need to provide some other use case that 
either cannot be done using areas or cannot be done hitlessly.

Continuing to focus on something that can already be done with areas isn’t 
helping you.



   Les





From: Huaimo Chen 
Sent: Tuesday, August 18, 2020 3:18 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Hi Les,



> It is possible to merge/split areas without adjacency flaps.

[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before this abstraction 
and will not reduce the service interruption during the abstraction.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Huaimo –



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning – but it is quite feasible and has been done.



You cannot justify the need for zones on this basis.



   Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=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 Les,



> I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.

> IS-IS already has smooth transition capability for merging/splitting areas..



[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in “smooth transition to/from 
> zone abstraction”.



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto: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



I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] L

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

[Huaimo Chen]

Hi Henk,

It seems that IS-IS TTZ should not be complex. The prototype implementation 
of OSPF TTZ  seems simple and easy to operate. The complexity of IS-IS TTZ is 
similar to that of OSPF TTZ. In addition, we will try our best to reduce its 
complexity further.
IS-IS TTZ is one of a few proposals/drafts which explore/experiment new 
ways for scalability.

Best Regards,
Huaimo

From: Lsr  on behalf of Henk Smit 
Sent: Wednesday, August 19, 2020 12:08 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

I object the introduction of a new major concept, called "zone".
It adds nothing to solve problems we can not already solve.
It just adds unnecessary complexity and technical debt.

(12) In protocol design, perfection has been reached not when there
  is nothing left to add, but when there is nothing left to take
away.

henk.


Acee Lindem (acee) schreef op 2020-08-18 16:16:
> 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
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C1eebe40e2ab34d2ed03c08d8445a297c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637334501365871305&sdata=7Al1Hk%2FnR%2B19cbAigxEopXaX4x4bAneLMphQCjZw6c0%3D&reserved=0

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C1eebe40e2ab34d2ed03c08d8445a297c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637334501365881301&sdata=DMbOGdYQyEK9Abyc6TpFaP5P4iU5D7SeMDl69SUMVzY%3D&reserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Dongjie (Jimmy)]

I support the adoption of this document.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gengxuesong (Geng Xuesong)]

Yes, Support.
It is a reasonable technical solution to abstract a zone to a virtual node to 
enhanced scalability.

Best Regards
Xuesong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Lizhenbin]

Hi All,

I support the adoption.


Best Regards,

Zhenbin (Robin)

--
李振斌 Li Zhenbin
Mobile: +86-13651017745/+968-91797068
Email: lizhen...@huawei.com

发件人：Acee Lindem (acee) 
收件人：lsr 
时 间：2020-08-18 22:17:38
主 题：[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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[ruoxin huang]

I support working group adoption of this draft.

Best,
Ruoxin

Sent from Outlook<http://aka.ms/weboutlook>


From: Lsr  on behalf of reta Yang 
Sent: Thursday, August 27, 2020 7:48 PM
To: lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

I support the adoption.
This protocol can ease the deployment overhead.

Thanks,
Reta


From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Tuesday, August 18, 2020 10:16 PM
To: lsr@ietf.org 
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[reta Yang]

I support the adoption.
This protocol can ease the deployment overhead.

Thanks,
Reta


From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Tuesday, August 18, 2020 10:16 PM
To: lsr@ietf.org 
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huzhibo]

Support WG adoption.
Thanks,

Zhibo Hu
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Uma Chunduri]

Support.

--
Uma C.

On Tue, Aug 18, 2020 at 7:17 AM Acee Lindem (acee)  wrote:

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

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

[Xufeng Liu]

Support WG adoption.
Thanks,
- Xufeng

On Tue, Aug 18, 2020 at 10:17 AM Acee Lindem (acee)  wrote:

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

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

[Linda Dunbar]

Support the WG Adoption.

Linda Dunbar

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 AM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Yanhe Fan]

Support.

Thanks,
Yanhe

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 AM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Toy, Mehmet]

Support adoption of  "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz-11.txt .
Thanks
Mehmet


--
*From:* Lsr  on behalf of Acee Lindem (acee) 
*Sent:* Tuesday, August 18, 2020 10:16 AM
*To:* lsr@ietf.org 
*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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Anil Kumar]

Hi All,

As Co-Author, I support working group adoption of this draft as
experimental.

With Regards
Anil S N

On Tue, Aug 18, 2020 at 7:47 PM Acee Lindem (acee)  wrote:

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

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

[Donald Eastlake]

I support working group adoption of this draft as experimental.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Tue, Aug 18, 2020 at 10:17 AM Acee Lindem (acee)  wrote:

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

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

[LEI LIU]

Support as a co-author.

Thanks,
Best regards,
Lei

On Tue, Aug 18, 2020 at 7:17 AM Acee Lindem (acee)  wrote:

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

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

[Aijun Wang]

Hi, all:

 

Support its adoption.

>From the current contents of these two drafts, as Acee said, there are enough 
>differences between them. The area-proxy draft defining mainly the extension 
>of the TLVs that should be carried by the Proxy LSP, the TTZ draft emphasizes 
>mainly the smooth transition procedures and the related protocol extension.  

 

Using the protocol to solve the transition problem can certainly ease the 
deployment/operation overhead.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

 

From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 10:17 PM
To: lsr@ietf.org
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 

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Haoyu Song]

I Support the adoption for experimental track.

Haoyu

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Kiran Makhijani]

I support the adoption.
-Kiran

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Richard Li]

Hi Robert,

-😊 It was not meant to be a silver-bullet by saying “5G”. It happened that I 
have been discussing with folks on the design of the mobile backhaul/core/MEC.  
Most of the designers and planners of the mobile backhaul/core/MEC do not work 
on routing technologies themselves, instead they choose and pick up some 
existing solutions provided by the IETF, and if they are not comfortable with 
the existing solutions, they use central controller/orchestrator and/or other 
management systems in a quasi-static config way.

Indeed, the WP you quoted does not indicate a need for zones. That said, you 
cannot deny that MEC is a set of inter-connected nodes, especially when being 
connected to the aggregation ring. Now the question is whether or not you allow 
such nodes to participate in routing. If you do, TTZ is a good candidate to 
reduce the internal topology and to turn MEC into a virtualized one; if you 
don’t, however, there is no space to discuss it.

Anyway, TTZ is aimed to be “experimental”.


Best regards,

Richard



From: Robert Raszuk 
Sent: Wednesday, August 19, 2020 12:25 AM
To: Richard Li 
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Richard,

I understand that these days you say "5G" and you are done for any use case. :)

So I read this paper: 
https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Fimages%2Ffiles%2FETSIWhitePapers%2Fetsi_wp28_mec_in_5G_FINAL.pdf&data=02%7C01%7Crichard.li%40futurewei.com%7C1a28b96b430246e2eaa208d844f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637334187402121649&sdata=l7uwLpOhqEkY20ZsQgCv4N0Ce9JgVMG%2FskWQ1RdkjJ4%3D&reserved=0>

There is nothing there which would indicate a need for zone or even area 
separation to effectively deploy MEC. To me MEC data path can be constructed 
with a form of encapsulation in an arbitrary fashion. In fact I could say the 
more underlay walls you implement the harder it becomes to construct arbitrary 
MEC mesh.

At least for LSR WG if I were to justify any work here like TTZ I would explain 
why Multi access edge computing requires IGP/underlay type of separation and 
moreover why such separation can not be constructed with areas or levels.

Thx,
R.

On Wed, Aug 19, 2020 at 5:18 AM Richard Li 
mailto:richard...@futurewei.com>> wrote:
This is a use case:

The user plane of 5G is distributed, and MEC is deployed as part of the user 
plane to provide some functions at Access Aggregation Ring or Regional 
Aggregation Ring or at the border between Regional Aggregation Ring and the 
National Core. Using TTZ, MEC or part of it can be virtualized and 
topologically simplified. Note that the outside really doesn’t care about the 
internals of MEC.


Thanks,

Richard



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Tuesday, August 18, 2020 2:25 PM
To: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Cc: 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

Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the 
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented 
therefore until the document extensively describes the real use cases with 
justification why use of areas may not be sufficient for such use cases I don't 
think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:

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

___
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%7Crichard.li%40futurewei.com%7C1a28b96b430246e2eaa208d844f2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637334187402131636&sdata=0wIVp2ymiUSfvbsNWjswxRilK03oyF9wOVdQbX9i0rI%3D&reserved=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Henk Smit]

I object the introduction of a new major concept, called "zone".
It adds nothing to solve problems we can not already solve.
It just adds unnecessary complexity and technical debt.

(12) In protocol design, perfection has been reached not when there
 is nothing left to add, but when there is nothing left to take 
away.


henk.


Acee Lindem (acee) schreef op 2020-08-18 16:16:

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

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

[Robert Raszuk]

Hi Richard,

I understand that these days you say "5G" and you are done for any use
case. :)

So I read this paper:
https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL..pdf

There is nothing there which would indicate a need for zone or even area
separation to effectively deploy MEC. To me MEC data path can be
constructed with a form of encapsulation in an arbitrary fashion. In fact I
could say the more underlay walls you implement the harder it becomes to
construct arbitrary MEC mesh.

At least for LSR WG if I were to justify any work here like TTZ I would
explain why Multi access edge computing requires IGP/underlay type of
separation and moreover why such separation can not be constructed with
areas or levels.

Thx,
R.

On Wed, Aug 19, 2020 at 5:18 AM Richard Li  wrote:

> This is a use case:
>
>
>
> The user plane of 5G is distributed, and MEC is deployed as part of the
> user plane to provide some functions at Access Aggregation Ring or Regional
> Aggregation Ring or at the border between Regional Aggregation Ring and the
> National Core. Using TTZ, MEC or part of it can be virtualized and
> topologically simplified. Note that the outside really doesn’t care about
> the internals of MEC.
>
>
>
>
>
> Thanks,
>
>
>
> Richard
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, August 18, 2020 2:25 PM
> *To:* Acee Lindem (acee) 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
> Dear WG,
>
>
>
> The draft in question does not describe even a single practical use case.
>
>
>
> While it describes the mechanics on how to construct the new model of the
> abstraction it fails to prove we need it.
>
>
>
> Not everything which can be invented should be standardized or implemented
> therefore until the document extensively describes the real use cases with
> justification why use of areas may not be sufficient for such use cases I
> don't think LSR WG should adopt it.
>
>
>
> Regards,
> Robert.
>
>
>
> On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee)  40cisco@dmarc.ietf.org> wrote:
>
>
>
> 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
>
>
>
> ___
> Lsr mailing list
> 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%7Crichard.li%40futurewei..com%7Ccfd66b6c7fc54591ec0408d843bd4046%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637333827425070909&sdata=UgI0%2Bd6TyQtenEEoyU97R2qQJBlzRYuqS4XxhFjjcYA%3D&reserved=0>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Richard Li]

This is a use case:

The user plane of 5G is distributed, and MEC is deployed as part of the user 
plane to provide some functions at Access Aggregation Ring or Regional 
Aggregation Ring or at the border between Regional Aggregation Ring and the 
National Core. Using TTZ, MEC or part of it can be virtualized and 
topologically simplified. Note that the outside really doesn’t care about the 
internals of MEC.


Thanks,

Richard



From: Lsr  On Behalf Of Robert Raszuk
Sent: Tuesday, August 18, 2020 2:25 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the 
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented 
therefore until the document extensively describes the real use cases with 
justification why use of areas may not be sufficient for such use cases I don't 
think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>> wrote:

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

___
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%7Crichard.li%40futurewei.com%7Ccfd66b6c7fc54591ec0408d843bd4046%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637333827425070909&sdata=UgI0%2Bd6TyQtenEEoyU97R2qQJBlzRYuqS4XxhFjjcYA%3D&reserved=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Richard Li]

I support it.

Yes, indeed, this draft is sufficiently different from 
draft-ietf-lsr-isis-area-proxy-03 and should be advanced independently.

Best regards,

Richard



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Acee 
Lindem (acee) 
mailto:acee=40cisco.@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 10:16 AM
To: lsr@ietf.org mailto:lsr@ietf.org>>
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Liu Vic]

Support as co-author.

Thanks,
Liu

Les Ginsberg (ginsberg)  于2020年8月18日周二
下午3:52写道：

> Huaimo –
>
>
>
> The question I and others have asked is “what can we do with zones that
> cannot be done with areas?”.
>
>
>
> From the day several years ago when IS-IS TTZ was first presented,  your
> answer has been “with zones you can hitlessly alter the topological
> boundaries”.
>
> My response has consistently been “we can already do that with areas”.
>
>
> If you want to justify zones, you then need to provide some other use case
> that either cannot be done using areas or cannot be done hitlessly.
>
> Continuing to focus on something that can already be done with areas isn’t
> helping you.
>
>
>
>Les
>
>
>
>
>
> *From:* Huaimo Chen 
> *Sent:* Tuesday, August 18, 2020 3:18 PM
> *To:* Les Ginsberg (ginsberg) ; Les Ginsberg
> (ginsberg) ; Acee Lindem (acee)
> ; lsr@ietf.org
> *Subject:* Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone"
> - draft-chen-isis-ttz-11.txt
>
>
>
> Hi Les,
>
>
>
> > It is possible to merge/split areas without adjacency flaps.
>
> [HC]: While an existing area or zone is being abstracted as a single
> node or vice versa, there are the adjacency ups and downs. The areas
> merging/splitting without adjacency flaps has been done before this
> abstraction and will not reduce the service interruption during the
> abstraction.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Les Ginsberg (ginsberg) 
> *Sent:* Tuesday, August 18, 2020 5:59 PM
> *To:* Huaimo Chen ; Les Ginsberg (ginsberg) <
> ginsberg=40cisco@dmarc.ietf..org >;
> Acee Lindem (acee) ; lsr@ietf.org <
> lsr@ietf.org>
> *Subject:* RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone"
> - draft-chen-isis-ttz-11.txt
>
>
>
> Huaimo –
>
>
>
> It is possible to merge/split areas without adjacency flaps.
>
> The technique has been known for many years.
>
> It requires careful planning – but it is quite feasible and has been done.
>
>
>
> You cannot justify the need for zones on this basis..
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Huaimo Chen
> *Sent:* Tuesday, August 18, 2020 2:33 PM
> *To:* Les Ginsberg (ginsberg)  >; 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 Les,
>
>
>
> > I see no need for “abstraction at arbitrary boundaries”.. Areas work just
> fine.
>
> > IS-IS already has smooth transition capability for merging/splitting
> areas...
>
>
>
> [HC]: The smooth transition capability for merging/splitting areas in
> IS-IS will not reduce the service interruption while an existing area or
> zone is being abstracted as a single node because the adjacency ups and
> downs.
>
>
>
> > Given both of the points above, I see no value in “smooth transition
> to/from zone abstraction”.
>
>
>
> [HC]:  The "smooth transition to/from zone abstraction" will reduce the
> service interruption while an existing area or zone is being abstracted as
> a single node and vice versa.
>
>
>
> Best Regards,
>
> Huaimo
> --
>
> *From:* Lsr  on behalf of Les Ginsberg (ginsberg) <
> ginsberg=40cisco@dmarc.ietf.org>
> *Sent:* Tuesday, August 18, 2020 5:06 PM
> *To:* Acee Lindem (acee) ; lsr@ietf.org <
> lsr@ietf.org>
> *Subject:* Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent
> Zone" - draft-chen-isis-ttz-11.txt
>
>
>
> I see no need for “abstraction at arbitrary boundaries”. Areas work just
> fine.
>
>
>
> IS-IS already has smooth transition capability for merging/splitting areas.
>
>
>
> Given both of the points above, I see no value in “smooth transition
> to/from zone abstraction”.
>
>
>
> If these are the principal distinguishing characteristics of TTZ as
> compared to area proxy (and I would agree they are), then I see no reason
> why this solution should be pursued as well.
>
>
>
> I am therefore opposed to WG adoption of TTZ.
>
>
>
>Les
>
>
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Acee Lindem (acee)
> *Sent:* Tuesday, August 18, 2020 7:17 AM
> *To:* lsr@ietf.org
> *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 

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

[Les Ginsberg (ginsberg)]

Huaimo -

The question I and others have asked is "what can we do with zones that cannot 
be done with areas?".

>From the day several years ago when IS-IS TTZ was first presented,  your 
>answer has been "with zones you can hitlessly alter the topological 
>boundaries".
My response has consistently been "we can already do that with areas".

If you want to justify zones, you then need to provide some other use case that 
either cannot be done using areas or cannot be done hitlessly.
Continuing to focus on something that can already be done with areas isn't 
helping you.

   Les


From: Huaimo Chen 
Sent: Tuesday, August 18, 2020 3:18 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Les,

> It is possible to merge/split areas without adjacency flaps.
[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before this abstraction 
and will not reduce the service interruption during the abstraction.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Huaimo -



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning - but it is quite feasible and has been done.



You cannot justify the need for zones on this basis.



   Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=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 Les,



> I see no need for "abstraction at arbitrary boundaries". Areas work just fine.

> IS-IS already has smooth transition capability for merging/splitting areas..



[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in "smooth transition to/from 
> zone abstraction".



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto: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



I see no need for "abstraction at arbitrary boundaries". Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in "smooth transition to/from 
zone abstraction".



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
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

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

[Huaimo Chen]

Hi Les,

> It is possible to merge/split areas without adjacency flaps.
[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before this abstraction 
and will not reduce the service interruption during the abstraction.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org 
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Huaimo –



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning – but it is quite feasible and has been done..



You cannot justify the need for zones on this basis.



   Les





From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem 
(acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Hi Les,



> I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.

> IS-IS already has smooth transition capability for merging/splitting areas..



[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in “smooth transition to/from 
> zone abstraction”.



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto: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



I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Huaimo -

It is possible to merge/split areas without adjacency flaps.
The technique has been known for many years.
It requires careful planning - but it is quite feasible and has been done.

You cannot justify the need for zones on this basis.

   Les


From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem 
(acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

Hi Les,

> I see no need for "abstraction at arbitrary boundaries". Areas work just fine.
> IS-IS already has smooth transition capability for merging/splitting areas..

[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.

> Given both of the points above, I see no value in "smooth transition to/from 
> zone abstraction".

[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto: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


I see no need for "abstraction at arbitrary boundaries". Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in "smooth transition to/from 
zone abstraction".



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Huaimo Chen]

Hi Les,

> I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.
> IS-IS already has smooth transition capability for merging/splitting areas.

[HC]: The smooth transition capability for merging/splitting areas in IS-IS 
will not reduce the service interruption while an existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.

> Given both of the points above, I see no value in “smooth transition to/from 
> zone abstraction”.

[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.

Best Regards,
Huaimo

From: Lsr  on behalf of Les Ginsberg (ginsberg) 

Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) ; lsr@ietf.org 

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


I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Dear WG,

The draft in question does not describe even a single practical use case.

While it describes the mechanics on how to construct the new model of the
abstraction it fails to prove we need it.

Not everything which can be invented should be standardized or implemented
therefore until the document extensively describes the real use cases with
justification why use of areas may not be sufficient for such use cases I
don't think LSR WG should adopt it.

Regards,
Robert.

On Tue, Aug 18, 2020 at 4:17 PM Acee Lindem (acee)  wrote:

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

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

[John E Drake]

As am I.

Yours Irrespectively,

John



Juniper Business Use Only
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, August 18, 2020 5:07 PM
To: Acee Lindem (acee) ; lsr@ietf.org
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]

I see no need for "abstraction at arbitrary boundaries". Areas work just fine.

IS-IS already has smooth transition capability for merging/splitting areas.

Given both of the points above, I see no value in "smooth transition to/from 
zone abstraction".

If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.

I am therefore opposed to WG adoption of TTZ.

   Les



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.

IS-IS already has smooth transition capability for merging/splitting areas.

Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.

If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.

I am therefore opposed to WG adoption of TTZ.

   Les



From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org
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

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Chris Bowers]

I support WG adoption of draft-chen-isis-ttz as experimental.

Chris

On Tue, Aug 18, 2020 at 9:17 AM Acee Lindem (acee)  wrote:

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

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

[Huaimo Chen]

Support.

Best Regards,
Huaimo as a co-author

From: Lsr  on behalf of Acee Lindem (acee) 

Sent: Tuesday, August 18, 2020 10:16 AM
To: lsr@ietf.org 
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


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr