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

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

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>>
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>>
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] WG Last Call for draft-ietf-lsr-flex-algo

[Shraddha Hegde]

Peter,

In order to make the document clearer on this point, I would like the text 
below to be added
to section 11 to make it explicit that setting the L-bit is valid for flex-algo 
for ISIS.

=
Section 11.

“The ASLA TLV in ISIS supports the L-Bit as described in section 4.2 of 
[draft-ietf-isis-te-app]. When the L-bit is set, applications MUST use
legacy advertisements for that link. Flex algorithm application MUST support
sending and receiving link attributes with ASLA TLV having L-bit set.

Note that earlier versions of this document did not mandate use of ASLA TLVs
and hence may not inter-operate with early implementations that use legacy 
advertisements."



Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak  
Sent: Wednesday, September 2, 2020 2:43 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; 
Les Ginsberg (ginsberg) ; lsr@ietf.org; 
lsr-...@ietf.org; Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Hi Shraddha,

please see inline:


On 02/09/2020 06:45, Shraddha Hegde wrote:
> Peter,
>
> It is worthwhile to note the history of the flex-algo draft and the 
> te-app draft and how many  backward incompatible changes have been 
> introduced in the course of the flex-algo draft.
>
> The original drafts of flex-algo did not mention the te-app draft and 
> was completely based on legacy advertisements.
> Two years ago, after the working group adopted the original drafts 
> without the ASLA TLV, the text was changed to require the ASLA TLV.

draft-ietf-lsr-flex-algo-00, which was the initial version of the WG document 
already mandated the ASLA usage. I don't believe we have to go back to the 
individual drafts that predated the WG version.

>
>
> ASLA TLV had the L-Bit and it was always valid to advertise link 
> attributes for flex-algo with L-bit set which means the link 
> attributes could still be sent in legacy TLVs.
> In a conversation last year, you had agreed that advertising link 
> attributes with L-bit set is valid for Flex-algo.


what we say in flex-algo draft in section 11 is:

"Link attribute advertisements that are to be used during Flex-
Algorithm calculation MUST use the Application-Specific Link
Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
[I-D.ietf-ospf-te-link-attr-reuse]."

ietf-isis-te-app clearly allows the app specific value of the attribute to be 
advertised in legacy TLV and be pointed to by ASLA with L-bit.
This is perfectly valid for Flex-algo with ISIS.

Please note that etf-ospf-te-link-attr-reuse does not have the concept of L-bit.

>
> Towards the end of 2019, draft-ietf-isis-te-app-08 was posted. This 
> version said that only RSVP, SR-TE and LFA can use legacy advertisements.
> This change in a different draft made using flex-algo with legacy 
> advertisements invalid.

no, not really. From the version 00, the WG version of the flex-algo draft 
mandated the usage of ASLA. And from day one of the draft-ietf-isis-te-app 
draft we mandated the usage of the ALSA for new applications, including the 
flex-algo. And usage of ASLA with L-bit together with the legacy advertisement 
of the link attribute is valid for any new application.

>
> So implementations from 2 yrs ago may not inter-operate with the ones 
> implemented a year ago or the ones implemented based on published RFC.

let's be more precise here. The implementation of the pre-WG version may not 
inter-operate with WG version. I don't see a problem there really.

> Implementations from a year ago may not interoperate with published RFC.

no, that is not true.

>
> I don’t agree with this series of backward incompatible changes that 
> have been made in this document.  However, if the working group 
> decides to go ahead and request publication of the current version,  
> which has broken backward compatibility twice with previous versions,

above statement is not correct. The WG document has been consistent in terms of 
ASLA usage from day one.

thanks,
Peter


>   I want the history to be accurately  recorded. This allows network 
> operators to better understand the history and ensure interoperability across 
> vendors before deploying.
>
>
> Rgds
> Shraddha
>
>
> Juniper Business Use Only
>
> -Original Message-
> From: Peter Psenak 
> Sent: Thursday, August 27, 2020 3:34 PM
> To: Shraddha Hegde ; olivier.dug...@orange.com; 
> tony...@tony.li; Robert Raszuk 
> Cc: Christian Hopps ; 
> draft-ietf-lsr-flex-algo@ietf.org; Les Ginsberg (ginsberg) 
> ; lsr@ietf.org; lsr-...@ietf.org; 
> Acee Lindem (acee) 
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
> [External Email. Be cautious of content]
>
>
> Hi Shraddha,
>
> draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years ago).
>
>
>
> It clearly stat

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

[Lsr] Fwd: New Version Notification for draft-ietf-lsr-isis-area-proxy-04.txt

[tony . li]

Hi all,

This version reflects the discussion to date and the early allocation of code 
points.

Regards,
Sarah, Vivek, Gyan, & Tony


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-ietf-lsr-isis-area-proxy-04.txt
> Date: September 2, 2020 at 7:35:25 AM PDT
> To: "Tony Li" , "Gyan S. Mishra" 
> , "Gyan Mishra" , 
> "Vivek Ilangovan" , "Sarah Chen" 
> 
> 
> A new version of I-D, draft-ietf-lsr-isis-area-proxy-04.txt
> has been successfully submitted by Tony Li and posted to the
> IETF repository.
> 
> Name: draft-ietf-lsr-isis-area-proxy
> Revision: 04
> Title:Area Proxy for IS-IS
> Document date:2020-09-02
> Group:lsr
> Pages:20
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-lsr-isis-area-proxy-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-04
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-04
> 
> Abstract:
>   Link state routing protocols have hierarchical abstraction already
>   built into them.  However, when lower levels are used for transit,
>   they must expose their internal topologies to each other, leading to
>   scale issues.
> 
>   To avoid this, this document discusses extensions to the IS-IS
>   routing protocol that would allow level 1 areas to provide transit,
>   yet only inject an abstraction of the level 1 topology into level 2.
>   Each level 1 area is represented as a single level 2 node, thereby
>   enabling greater scale.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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

[Lsr] I-D Action: draft-ietf-lsr-isis-area-proxy-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Area Proxy for IS-IS
Authors : Tony Li
  Sarah Chen
  Vivek Ilangovan
  Gyan S. Mishra
Filename: draft-ietf-lsr-isis-area-proxy-04.txt
Pages   : 20
Date: 2020-09-02

Abstract:
   Link state routing protocols have hierarchical abstraction already
   built into them.  However, when lower levels are used for transit,
   they must expose their internal topologies to each other, leading to
   scale issues.

   To avoid this, this document discusses extensions to the IS-IS
   routing protocol that would allow level 1 areas to provide transit,
   yet only inject an abstraction of the level 1 topology into level 2.
   Each level 1 area is represented as a single level 2 node, thereby
   enabling greater scale.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-isis-area-proxy-04
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-area-proxy-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-area-proxy-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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



*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] WG Last Call for draft-ietf-lsr-flex-algo

[Peter Psenak]

Hi Shraddha,

please see inline:


On 02/09/2020 06:45, Shraddha Hegde wrote:

Peter,

It is worthwhile to note the history of the flex-algo draft and the
te-app draft and how many  backward incompatible changes have been
introduced in the course of the flex-algo draft.

The original drafts of flex-algo did not mention the te-app draft
and was completely based on legacy advertisements.
Two years ago, after the working group adopted the original drafts without the 
ASLA TLV,
the text was changed to require the ASLA TLV.


draft-ietf-lsr-flex-algo-00, which was the initial version of the WG 
document already mandated the ASLA usage. I don't believe we have to go 
back to the individual drafts that predated the WG version.





ASLA TLV had the L-Bit and it was always valid to advertise link attributes
for flex-algo with L-bit set which means the link attributes could still be sent
in legacy TLVs.
In a conversation last year, you had agreed that advertising link attributes 
with
L-bit set is valid for Flex-algo.



what we say in flex-algo draft in section 11 is:

   "Link attribute advertisements that are to be used during Flex-
   Algorithm calculation MUST use the Application-Specific Link
   Attribute (ASLA) advertisements defined in [I-D.ietf-isis-te-app] or
   [I-D.ietf-ospf-te-link-attr-reuse]."

ietf-isis-te-app clearly allows the app specific value of the attribute 
to be advertised in legacy TLV and be pointed to by ASLA with L-bit. 
This is perfectly valid for Flex-algo with ISIS.


Please note that etf-ospf-te-link-attr-reuse does not have the concept 
of L-bit.




Towards the end of 2019, draft-ietf-isis-te-app-08 was posted. This version said
that only RSVP, SR-TE and LFA can use legacy advertisements.
This change in a different draft made using flex-algo with
legacy advertisements invalid.


no, not really. From the version 00, the WG version of the flex-algo 
draft mandated the usage of ASLA. And from day one of the 
draft-ietf-isis-te-app draft we mandated the usage of the ALSA for new 
applications, including the flex-algo. And usage of ASLA with L-bit 
together with the legacy advertisement of the link attribute is valid 
for any new application.




So implementations from 2 yrs ago may not inter-operate with
the ones implemented a year ago or the ones implemented based on published RFC.


let's be more precise here. The implementation of the pre-WG version may 
not inter-operate with WG version. I don't see a problem there really.



Implementations from a year ago may not interoperate with published RFC.


no, that is not true.



I don’t agree with this series of backward incompatible changes that have been
made in this document.  However, if the working group decides to go ahead and 
request publication
of the current version,  which has broken backward compatibility twice with 
previous versions,


above statement is not correct. The WG document has been consistent in 
terms of ASLA usage from day one.


thanks,
Peter



  I want the history to be accurately  recorded. This allows network
operators to better understand the history and ensure interoperability across 
vendors before deploying.


Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Peter Psenak 
Sent: Thursday, August 27, 2020 3:34 PM
To: Shraddha Hegde ; olivier.dug...@orange.com; 
tony...@tony.li; Robert Raszuk 
Cc: Christian Hopps ; draft-ietf-lsr-flex-algo@ietf.org; Les 
Ginsberg (ginsberg) ; lsr@ietf.org; lsr-...@ietf.org; 
Acee Lindem (acee) 
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Hi Shraddha,

draft-ietf-lsr-flex-algo-00 was published May 15, 2018 (over two years ago).



It clearly stated:

https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00*section-9__;Iw!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_03Sd1J7b$

"To advertise a link affinity in a form of the AG or EAG that is used
   during Flex-Algorithm calculation, an Application Specific Link
   Attributes sub-TLV as described in [I-D.ietf-isis-te-app], or sub-TLV
   of Extended Link TLV as described in [I-D.ietf-ospf-te-link-attr-reuse]
   MUST be used. The advertisement MUST indicate that it is usable by the
   Flex-Algorithm application."

This is consistent with normative statements in both 
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-isis-te-app-19__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_09_HTtuT$
  and 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/__;!!NEt6yMaO-gk!U69buL_O8Dwro3_ks7FCVPZ2-jnYKFPl7DWC_fZCGDapvakBVKlZPth_08_P1Wmy$
which REQUIRE the use of application specific advertisements by all 
applications other than the legacy applications (RSVP-TE, Segment Routing 
Policy,  Loop Free Alternate).

draft-hegdeppsenak-isis-sr-flex-algo had a lifetime of 10 months(V00 published 
in July 2017) and draf

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