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]

On Behalf Of 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


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

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 IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

[Kiran Makhijani]

Hi,
I am not aware of any undeclared IPR for this draft.
-Kiran

From: Acee Lindem (acee) 
Sent: Tuesday, August 18, 2020 7:24 AM
To: draft-chen-isis-...@ietf.org
Cc: lsr@ietf.org
Subject: LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz.txt

Authors,

The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified here:

https://datatracker.ietf.org/ipr/4029/


Are you aware of any other IPR that applies to draft-chen-isis-ttz?

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. *The response needs to be sent to the LSR WG mailing
list.* The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

Re: [Lsr] Request WG adoption of TTZ

[Kiran Makhijani]

I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction.
-Kiran

-Original Message-
From: Lsr  On Behalf Of Yanhe Fan
Sent: Sunday, July 12, 2020 7:33 AM
To: Donald Eastlake ; Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adaption of this IS-IS TTZ draft. It is a useful work to address 
network scalability.

Thanks,
Yanhe

-Original Message-
From: Lsr  On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some editorial/nomenclature 
improvements in the draft would be good. I will send some more detailed 
suggestions to the authors.

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

On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdata=yxhI0GPxnBm5t0hosQNld4qq7O4bu3V2p4RExVjMcqE%3Dreserved=0
>  .
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone 
> or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in 
> the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single 
> pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its 
> zone smoothly
>
> with no or minimum service interruption.
>
>
>
> We had a prototype implementation of abstracting a zone to zone 
> edges' full
>
> mess in OSPF. The procedures and related protocol extensions for 
> transferring
>
> smoothly from a zone to zone edges' full mess are implemented and tested.
>
> A zone (block of an OSPF area) is smoothly transferred to its edges’ 
> full mess
>
> without any routing disruptions. The routes on every router are stable 
> while
>
> the zone is being transferred to its edges' mess. It is very easy to 
> operate
>
> the transferring.
>
>
>
> There are two other drafts for improving scalability: "Area Proxy for 
> IS-IS"
>
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
> short).
>
>
>
> "Area Proxy" 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03data=02%7C01%7
> Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a
> 3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdata=E95AXx%
> 2Bq4Xul3auIUt%2FUI203nvzgDODJDOs8l1Dlk9o%3Dreserved=0
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
> "Flood Reflection" 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01data=
> 02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdat
> a=iNunk3YCV%2FiXEEYNYxozwgRlavMPB%2B%2FF1k6K6CCcWkA%3Dreserved=0
>
> abstracts an existing IS-IS L1 area to its edges' connections via one 
> or more
>
> flood reflectors.
>
>
>
> We believe that TTZ has some special advantages even though
>
> Area Proxy and Flood Reflection are very worthy. We would like
>
> to ask for working group adoption of TTZ.
>
>
>
> Best Regards,
>
> Huaimo
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Ckiranm%40future
> wei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5
> 591fedc%7C1%7C0%7C637301612416445576sdata=P9I3KSsJb84wDSs6kaVrI%2
> B5bfPRF2MNt1JyTvJea6wc%3Dreserved=0

___
Lsr mailing list
Lsr@ietf.org

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Kiran Makhijani]

Support WG adoption.
Regards,
Kiran

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, May 15, 2020 12:40 PM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.

https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

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