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/).
-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 enti

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

[Peter Psenak]

Gunter,

On 03/09/2020 14:49, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

I think that some misunderstanding comes from a different definition of " LEGACY 
ADVERTISEMENTS" between section 4.2 and 6.1

In section 4.2:
LEGACY ADVERTISEMENTS means that *ASLA is used* and point to the attributes 
found in legacy TLVs for example EAG, Delay and TE-metric

In section 6.1:
LEGACY ADVERTISEMENTS means that *ASLA is NOT used* and allows RSVP-TE, 
SR-Policy and LFA to interoperate between systems that do not, and do, support 
ASLA

Taking this understanding to flex-algo:
* Interop: traditionally we use the L-bit=SET for application interoperability 
when not all nodes understand valid ASLA encoding.
* Interop: by design of flex-algorithm technology, we mandate ASLA encoding. No 
interop issues should exist with nodes not understanding ASLA encodings.
* Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo 
attributes? There seems no use-case and no logic for such.


because the draft-ietf-isis-te-app allows it.



* OSPF has no existing L-bit

For flex-algo simplicity, we could agree that legacy attribute advertisements 
MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET


not really. Flex-algo draft simply refers to draft-ietf-isis-te-app, 
which allows L-bit (with legacy adv) to be used for any application.
There are vendors that have implemented flex-algo this way and we MUST 
be able to interoperate.


thanks,
Peter


(This is unrelated that flex-algo ASLA with L-bit SET is semantically a valid 
ASLA. This also simplifies and align ISIS and OSPF routing protocol behavior. 
It reduce interop issues footprint with systems not supporting ASLA.)

G/






-Original Message-
From: Peter Psenak 
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; Selderslaghs, Rudy 
(Nokia - BE/Antwerp) ; 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

Gunter,

On 03/09/2020 11:53, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

Hi Peter, All,

Let me chime in.

When the L-bit is set in an ASLA TLV, then for all applications marked, indeed 
only legacy attributes can be used.
Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That is 
not the point.

Read the text in chapter 4.2:


  When the L-flag is set in the Application Identifier Bit Mask, all of
  the applications specified in the bit mask MUST use the legacy
  advertisements for the corresponding link found in TLVs 22, 23, 25,
  141, 222, and 223 or TLV 138 or TLV 139 as appropriate.


This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have to 
be used.
However chapter 6.1 is saying that legacy advertisements can only be used for 
RSVP-TE, SR-Policy and LFA.


where? Please point me to the text.

If you are referring to the text:

"New applications that future documents define to make use of the advertisements 
defined in this document MUST NOT make use of legacy advertisements."

then it is NOT preventing L-bit with legacy advertisement for new apps, because 
ASLA with L-bit in combination with legacy advertisement is not considered as 
legacy advertisement, but as a valid ASLA advertisement.




So in my opinion the draft is saying the opposite and legacy advertisements 
MUST NOT be used for flex-algo.


again, L-bit with legacy advertisement is NOT a legacy advertisement. It is 
ASLA advertisement.


Hence, I suggest that we should make it explicit clear that L-bit set for 
flex-algo is MUST NOT be allowed.


L-bit is allowed with any app, including the flex-algo.

thanks,
Peter



G/




-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp)
; Peter Psenak
; 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

Hi Rudy,

On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:

Hi Peter,

My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set 
to 1, cannot be used for Flex-Algo.


no, that is not correct.


This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
6.1.


no.



>From chapter 6.1 Use of Legacy advertisements:
  ...
  New applications that future documents define to make use of the
  advertisements defined in this document MUST NOT make use of legacy
  advertisements.  This simplifies deployment of new applications by
  eliminating the need to support multiple ways to advertise attributes
  for the new a

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

I think that some misunderstanding comes from a different definition of " 
LEGACY ADVERTISEMENTS" between section 4.2 and 6.1

In section 4.2:
LEGACY ADVERTISEMENTS means that *ASLA is used* and point to the attributes 
found in legacy TLVs for example EAG, Delay and TE-metric

In section 6.1:
LEGACY ADVERTISEMENTS means that *ASLA is NOT used* and allows RSVP-TE, 
SR-Policy and LFA to interoperate between systems that do not, and do, support 
ASLA

Taking this understanding to flex-algo:
* Interop: traditionally we use the L-bit=SET for application interoperability 
when not all nodes understand valid ASLA encoding. 
* Interop: by design of flex-algorithm technology, we mandate ASLA encoding. No 
interop issues should exist with nodes not understanding ASLA encodings.
* Why would a flex-algo node, ever, advertise legacy TLVs for flex-algo 
attributes? There seems no use-case and no logic for such. 
* OSPF has no existing L-bit

For flex-algo simplicity, we could agree that legacy attribute advertisements 
MUST NOT be used and agree that flex-algo ASLA L-bit MUST be UNSET 
(This is unrelated that flex-algo ASLA with L-bit SET is semantically a valid 
ASLA. This also simplifies and align ISIS and OSPF routing protocol behavior. 
It reduce interop issues footprint with systems not supporting ASLA.)

G/






-Original Message-
From: Peter Psenak  
Sent: Thursday, September 3, 2020 12:02
To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
Selderslaghs, Rudy (Nokia - BE/Antwerp) ; 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

Gunter,

On 03/09/2020 11:53, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> Hi Peter, All,
> 
> Let me chime in.
> 
> When the L-bit is set in an ASLA TLV, then for all applications marked, 
> indeed only legacy attributes can be used.
> Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That 
> is not the point.
> 
> Read the text in chapter 4.2:
> 
>>  When the L-flag is set in the Application Identifier Bit Mask, all of
>>  the applications specified in the bit mask MUST use the legacy
>>  advertisements for the corresponding link found in TLVs 22, 23, 25,
>>  141, 222, and 223 or TLV 138 or TLV 139 as appropriate.
> 
> This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have 
> to be used.
> However chapter 6.1 is saying that legacy advertisements can only be used for 
> RSVP-TE, SR-Policy and LFA.

where? Please point me to the text.

If you are referring to the text:

"New applications that future documents define to make use of the 
advertisements defined in this document MUST NOT make use of legacy 
advertisements."

then it is NOT preventing L-bit with legacy advertisement for new apps, because 
ASLA with L-bit in combination with legacy advertisement is not considered as 
legacy advertisement, but as a valid ASLA advertisement.


> 
> So in my opinion the draft is saying the opposite and legacy advertisements 
> MUST NOT be used for flex-algo.

again, L-bit with legacy advertisement is NOT a legacy advertisement. It is 
ASLA advertisement.

> Hence, I suggest that we should make it explicit clear that L-bit set for 
> flex-algo is MUST NOT be allowed.

L-bit is allowed with any app, including the flex-algo.

thanks,
Peter

> 
> G/
> 
> 
> 
> 
> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 11:19
> To: Selderslaghs, Rudy (Nokia - BE/Antwerp) 
> ; Peter Psenak 
> ; 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
> 
> Hi Rudy,
> 
> On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:
>> Hi Peter,
>>
>> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit 
>> set to 1, cannot be used for Flex-Algo.
> 
> no, that is not correct.
> 
>> This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
>> 6.1.
> 
> no.
> 
>>
>> >From chapter 6.1 Use of Legacy advertisements:
>>  ...
>>  New applications that future documents define to make use of the
>>  advertisements defined in this document MUST NOT make use of legacy
>>  advertisements.  This simplifies deployment of new applications by
>>  eliminating the need to support multiple ways to advertise attributes
>>  for the new applications.
> 
> ASLA with L-bit pointing to legacy TLV is NOT considered legacy 
> advertisement. It is valid ASLA advertisement.
> 
> 
>>
>> Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
>> advertisements":
> 
> no. It s

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Selderslaghs, Rudy (Nokia - BE/Antwerp)]

Hi Peter,

My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set 
to 1, cannot be used for Flex-Algo.
This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
6.1.

From chapter 6.1 Use of Legacy advertisements:
   ...
   New applications that future documents define to make use of the
   advertisements defined in this document MUST NOT make use of legacy
   advertisements.  This simplifies deployment of new applications by
   eliminating the need to support multiple ways to advertise attributes
   for the new applications.

Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
advertisements":
   ...
   When the L-flag is set in the Application Identifier Bit Mask, all of
   the applications specified in the bit mask MUST use the legacy
   advertisements for the corresponding link found in TLVs 22, 23, 25,
   141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

Regards,
Rudy

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
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

Hi Shraddha,

On 03/09/2020 05:39, Shraddha Hegde wrote:
> 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.


I can add the above, although, it's clear from the draft-ietf-isis-te-app that 
L-bit with legacy advertisement MAY be used for any app.

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

it is not true that "earlier versions of this document" did not mandate ASLA.

https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only supported 
the include/exclude Admin Groups, clearly stated:


9.  Advertisement of Link Attributes for Flex-Algorithm

Various link include or exclude rules can be part of the Flex-
Algorithm definition.  These rules use Admin Groups (AG) as defined
in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
as defined in [RFC7308].

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.


thanks,
Peter



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

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Peter Psenak]

Gunter,

On 03/09/2020 11:53, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

Hi Peter, All,

Let me chime in.

When the L-bit is set in an ASLA TLV, then for all applications marked, indeed 
only legacy attributes can be used.
Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That is 
not the point.

Read the text in chapter 4.2:


 When the L-flag is set in the Application Identifier Bit Mask, all of
 the applications specified in the bit mask MUST use the legacy
 advertisements for the corresponding link found in TLVs 22, 23, 25,
 141, 222, and 223 or TLV 138 or TLV 139 as appropriate.


This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have to 
be used.
However chapter 6.1 is saying that legacy advertisements can only be used for 
RSVP-TE, SR-Policy and LFA.


where? Please point me to the text.

If you are referring to the text:

"New applications that future documents define to make use of the
advertisements defined in this document MUST NOT make use of legacy
advertisements."

then it is NOT preventing L-bit with legacy advertisement for new apps, 
because ASLA with L-bit in combination with legacy advertisement is not 
considered as legacy advertisement, but as a valid ASLA advertisement.





So in my opinion the draft is saying the opposite and legacy advertisements 
MUST NOT be used for flex-algo.


again, L-bit with legacy advertisement is NOT a legacy advertisement. It 
is ASLA advertisement.



Hence, I suggest that we should make it explicit clear that L-bit set for 
flex-algo is MUST NOT be allowed.


L-bit is allowed with any app, including the flex-algo.

thanks,
Peter



G/




-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp) ; Peter Psenak 
; 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

Hi Rudy,

On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:

Hi Peter,

My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set 
to 1, cannot be used for Flex-Algo.


no, that is not correct.


This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
6.1.


no.



>From chapter 6.1 Use of Legacy advertisements:
 ...
 New applications that future documents define to make use of the
 advertisements defined in this document MUST NOT make use of legacy
 advertisements.  This simplifies deployment of new applications by
 eliminating the need to support multiple ways to advertise attributes
 for the new applications.


ASLA with L-bit pointing to legacy TLV is NOT considered legacy advertisement. 
It is valid ASLA advertisement.




Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
advertisements":


no. It says that if L-flag is set, all apps mentioned in the bitmask
MUST use the legacy advertisement to derive the value of the attribute.
It does NOT say that ASLA TLV with L-bit set means "using legacy
advertisements". It does not.

thanks,
Peter


 ...
 When the L-flag is set in the Application Identifier Bit Mask, all of
 the applications specified in the bit mask MUST use the legacy
 advertisements for the corresponding link found in TLVs 22, 23, 25,
 141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

Regards,
Rudy

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
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

Hi Shraddha,

On 03/09/2020 05:39, Shraddha Hegde wrote:

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.



I can add the above, although, it's clear from the draft-ietf-isis-te-app that 
L-bit with legacy advertisement MAY be used for any app.



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


it is not true that "earlier versions of this document" did not mandate ASLA.

https://tools.ietf.org/html/draft-ietf-lsr-flex

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi Peter, All,

Let me chime in.

When the L-bit is set in an ASLA TLV, then for all applications marked, indeed 
only legacy attributes can be used.
Of course an ASLA TLV with the L-bit set is a valid ASLA advertisement. That is 
not the point.

Read the text in chapter 4.2:

> When the L-flag is set in the Application Identifier Bit Mask, all of
> the applications specified in the bit mask MUST use the legacy
> advertisements for the corresponding link found in TLVs 22, 23, 25,
> 141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

This clearly says that when the L-bit is set, the LEGACY ADVERTISEMENTS have to 
be used.
However chapter 6.1 is saying that legacy advertisements can only be used for 
RSVP-TE, SR-Policy and LFA.

So in my opinion the draft is saying the opposite and legacy advertisements 
MUST NOT be used for flex-algo.
Hence, I suggest that we should make it explicit clear that L-bit set for 
flex-algo is MUST NOT be allowed.

G/




-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 11:19
To: Selderslaghs, Rudy (Nokia - BE/Antwerp) ; 
Peter Psenak ; 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

Hi Rudy,

On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:
> Hi Peter,
> 
> My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set 
> to 1, cannot be used for Flex-Algo.

no, that is not correct.

> This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
> 6.1.

no.

> 
>>From chapter 6.1 Use of Legacy advertisements:
> ...
> New applications that future documents define to make use of the
> advertisements defined in this document MUST NOT make use of legacy
> advertisements.  This simplifies deployment of new applications by
> eliminating the need to support multiple ways to advertise attributes
> for the new applications.

ASLA with L-bit pointing to legacy TLV is NOT considered legacy advertisement. 
It is valid ASLA advertisement.


> 
> Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
> advertisements":

no. It says that if L-flag is set, all apps mentioned in the bitmask 
MUST use the legacy advertisement to derive the value of the attribute. 
It does NOT say that ASLA TLV with L-bit set means "using legacy 
advertisements". It does not.

thanks,
Peter

> ...
> When the L-flag is set in the Application Identifier Bit Mask, all of
> the applications specified in the bit mask MUST use the legacy
> advertisements for the corresponding link found in TLVs 22, 23, 25,
> 141, 222, and 223 or TLV 138 or TLV 139 as appropriate.
> 
> Regards,
> Rudy
> 
> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Thursday, September 3, 2020 9:55 AM
> 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
> 
> Hi Shraddha,
> 
> On 03/09/2020 05:39, Shraddha Hegde wrote:
>> 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.
> 
> 
> I can add the above, although, it's clear from the draft-ietf-isis-te-app 
> that L-bit with legacy advertisement MAY be used for any app.
> 
>>
>> 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."
> 
> it is not true that "earlier versions of this document" did not mandate ASLA.
> 
> https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only supported 
> the include/exclude Admin Groups, clearly stated:
> 
> 
> 9.  Advertisement of Link Attributes for Flex-Algorithm
> 
>  Various link include or exclude rules can be part of the Flex-
>  Algorithm definition.  These rules use Admin Groups (AG) as defined
>  in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
>  as defined in [RFC7308].
> 
>  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-

Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

[Peter Psenak]

Hi Rudy,

On 03/09/2020 11:01, Selderslaghs, Rudy (Nokia - BE/Antwerp) wrote:

Hi Peter,

My interpretation of the isis-te-app draft is that an ASLA TLV with L-bit set 
to 1, cannot be used for Flex-Algo.


no, that is not correct.


This can only be used for RSVP-TE, SR-Policy and LFA as specified in chapter 
6.1.


no.




From chapter 6.1 Use of Legacy advertisements:

...
New applications that future documents define to make use of the
advertisements defined in this document MUST NOT make use of legacy
advertisements.  This simplifies deployment of new applications by
eliminating the need to support multiple ways to advertise attributes
for the new applications.


ASLA with L-bit pointing to legacy TLV is NOT considered legacy 
advertisement. It is valid ASLA advertisement.





Chapter 4.2. states that ASLA TLV with L-bit set means "using legacy 
advertisements":


no. It says that if L-flag is set, all apps mentioned in the bitmask 
MUST use the legacy advertisement to derive the value of the attribute. 
It does NOT say that ASLA TLV with L-bit set means "using legacy 
advertisements". It does not.


thanks,
Peter


...
When the L-flag is set in the Application Identifier Bit Mask, all of
the applications specified in the bit mask MUST use the legacy
advertisements for the corresponding link found in TLVs 22, 23, 25,
141, 222, and 223 or TLV 138 or TLV 139 as appropriate.

Regards,
Rudy

-Original Message-
From: Lsr  On Behalf Of Peter Psenak
Sent: Thursday, September 3, 2020 9:55 AM
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

Hi Shraddha,

On 03/09/2020 05:39, Shraddha Hegde wrote:

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.



I can add the above, although, it's clear from the draft-ietf-isis-te-app that 
L-bit with legacy advertisement MAY be used for any app.



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


it is not true that "earlier versions of this document" did not mandate ASLA.

https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only supported 
the include/exclude Admin Groups, clearly stated:


9.  Advertisement of Link Attributes for Flex-Algorithm

 Various link include or exclude rules can be part of the Flex-
 Algorithm definition.  These rules use Admin Groups (AG) as defined
 in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
 as defined in [RFC7308].

 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.


thanks,
Peter







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 t

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

[Peter Psenak]

Hi Shraddha,

On 03/09/2020 05:39, Shraddha Hegde wrote:

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.



I can add the above, although, it's clear from the 
draft-ietf-isis-te-app that L-bit with legacy advertisement MAY be used 
for any app.




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


it is not true that "earlier versions of this document" did not mandate 
ASLA.


https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-00, which only 
supported the include/exclude Admin Groups, clearly stated:



9.  Advertisement of Link Attributes for Flex-Algorithm

   Various link include or exclude rules can be part of the Flex-
   Algorithm definition.  These rules use Admin Groups (AG) as defined
   in [RFC7308] and [RFC5305], or Extended Administrative Groups (EAG)
   as defined in [RFC7308].

   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.


thanks,
Peter







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 wor