Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Parag Kaneriya]

Hi Huaimo,

Let me try to explain you.

CASE 1:  Let's say TLV 22 all the node understand.  RFC doesn't specify 
multiple occurrences of TLV 22.  All the node parse the TLV and install in 
various database [ISIS, TED] etc...
   Now if there are more information need to pack TLV 22,  Updated 
Node send multiple of TLV 22,   Legacy node behavior is undefine since 
different node process differently [ some takes first TLV22 and some may take 
TLV 22].   This lead to inconsistent database behavior and THIS IS NOT A 
BACKWORD COMPITIBAL.Multi-TLV draft try to address this situation and 
layout procedure outline in the draft.

CASE 2:  New feature introduced in IGP with new TLV values.   Legacy node 
doesn't participate in this new feature since it doesn't understand and it will 
skip TLV while processing LSP.  This new TLV is BACKWARD COMPITIBAL.

HOPE THIS WILL CLARIFY YOUR DOUBT.

Regards
Parag



Juniper Business Use Only
From: Huaimo Chen 
Sent: Sunday, December 10, 2023 1:28 AM
To: Les Ginsberg (ginsberg) ; Parag Kaneriya 
; li_zhenqi...@hotmail.com; Tony Li ; 
Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

[External Email. Be cautious of content]

Hi Les and Parag,

The following are two definitions from you. You said they are the same in 
meaning. That is your opinions. But I think they are different. If they are the 
same and we use definition 1, then no protocol extension (with a new 
advertisement) is backwards compatible.
Definition 1 (derived): backwards compatibility/consistency means that protocol 
extensions can be advertised, and legacy node gets all the information (i.e., 
legacy node understands the new advertisements).
Definition 2: backwards compatibility means that protocol extensions can be 
advertised and safely used in the presence of legacy nodes (which do not 
understand the new advertisements).

Best Regards,
Huaimo


Juniper Business Use Only
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Saturday, December 9, 2023 11:33 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Parag Kaneriya mailto:pkane...@juniper.net>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Huaimo -

We are not making progress here - and I doubt that any additional posts from me 
will help - so I am not going to respond further.

I only want to point out that there is no difference between Parag and myself 
as regards the meaning of  "backwards compatibility".
The fact that you think there is a difference is a clear indication that you 
have not correctly understood what we have said. If I thought that I could help 
by presenting things in a different way I would give it a try - but I have 
already tried multiple times.

You will either take the above input as a reason to reread the thread and try 
to figure out why you have incorrectly concluded that Parag and I are not in 
agreement - or you won't. That is totally your decision.

   Les

From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Saturday, December 9, 2023 6:06 AM
To: Parag Kaneriya mailto:pkane...@juniper.net>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

>Legacy node gets half information result in the inconsistent view of network 
>(for example TED
>[traffic engineering database] inconsistency lead to many network related 
>issue.)
>hence legacy node getting half information is not backward consistent.

>From your statement, your definition of backwards compatibility/consistency 
>means that protocol extensions can be advertised, and legacy node gets all the 
>information (i.e., legacy node understands the new advertisements).

This seems uncommon. No protocol extension (with a new advertisement) is 
backwards compatible according to your definition. Your definition seems not 
consistent with Les'.

Best Regards,
Huaimo

From: Parag Kaneriya mailto:pkane...@juniper.net>>
Sent: Friday, December 8, 2023 11:29 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com&

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Parag Kaneriya]

Hi Huaimo,

Looks like you derived understanding that Les and I am not in agreement which 
is not true.  I agree with Authors of this draft and fully support it.

Regards
Parag



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Saturday, December 9, 2023 10:03 PM
To: Huaimo Chen ; Parag Kaneriya 
; li_zhenqi...@hotmail.com; Tony Li ; 
Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

[External Email. Be cautious of content]

Huaimo -

We are not making progress here - and I doubt that any additional posts from me 
will help - so I am not going to respond further.

I only want to point out that there is no difference between Parag and myself 
as regards the meaning of  "backwards compatibility".
The fact that you think there is a difference is a clear indication that you 
have not correctly understood what we have said. If I thought that I could help 
by presenting things in a different way I would give it a try - but I have 
already tried multiple times.

You will either take the above input as a reason to reread the thread and try 
to figure out why you have incorrectly concluded that Parag and I are not in 
agreement - or you won't. That is totally your decision.

   Les



Juniper Business Use Only
From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Saturday, December 9, 2023 6:06 AM
To: Parag Kaneriya mailto:pkane...@juniper.net>>; Les 
Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

>Legacy node gets half information result in the inconsistent view of network 
>(for example TED
>[traffic engineering database] inconsistency lead to many network related 
>issue.)
>hence legacy node getting half information is not backward consistent.

>From your statement, your definition of backwards compatibility/consistency 
>means that protocol extensions can be advertised, and legacy node gets all the 
>information (i.e., legacy node understands the new advertisements).

This seems uncommon. No protocol extension (with a new advertisement) is 
backwards compatible according to your definition. Your definition seems not 
consistent with Les'.

Best Regards,
Huaimo

From: Parag Kaneriya mailto:pkane...@juniper.net>>
Sent: Friday, December 8, 2023 11:29 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Legacy node gets half information result in the inconsistent view of network 
(for example TED [traffic engineering database] inconsistency lead to many 
network related issue.) hence  legacy node getting half information is not 
backward consistent.




Juniper Business Use Only
From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Friday, December 8, 2023 7:23 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org<mailto:draft-pkaneria-lsr-multi-...@ietf.org>;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

[External Email. Be cautious of content]

Hi Les,

Your definition of backwards compatibility means that protocol extensions 
can be advertised and safely used in the presence of legacy nodes (which do not 
understand the new advertisements).

Protocol extensions for Big-TLV include a new TLV (called container TLV) and a 
new Sub-TLV (called Big-TLV Capability Sub-TLV).  Big-TLV is also short for 
Protocol extensions for Big-TLV.
When adding a piece of new information into an existing TLV makes the TLV > 
255, this new information can be put into a container TLV. The container TLV 
can be advertised in a network. The old/legacy nodes (i.e., the nodes not 
supporting Big-TLV) ignore the container TL

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Parag Kaneriya]

Legacy node gets half information result in the inconsistent view of network 
(for example TED [traffic engineering database] inconsistency lead to many 
network related issue.) hence  legacy node getting half information is not 
backward consistent.




Juniper Business Use Only
From: Huaimo Chen 
Sent: Friday, December 8, 2023 7:23 PM
To: Les Ginsberg (ginsberg) ; li_zhenqi...@hotmail.com; 
Tony Li ; Linda Dunbar 
Cc: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

[External Email. Be cautious of content]

Hi Les,

Your definition of backwards compatibility means that protocol extensions 
can be advertised and safely used in the presence of legacy nodes (which do not 
understand the new advertisements).

Protocol extensions for Big-TLV include a new TLV (called container TLV) and a 
new Sub-TLV (called Big-TLV Capability Sub-TLV).  Big-TLV is also short for 
Protocol extensions for Big-TLV.
When adding a piece of new information into an existing TLV makes the TLV > 
255, this new information can be put into a container TLV. The container TLV 
can be advertised in a network. The old/legacy nodes (i.e., the nodes not 
supporting Big-TLV) ignore the container TLV, which contains the new 
information. The new nodes (i.e., the nodes supporting Big-TLV) obtain the new 
information.
Each of the new nodes advertises a Big-TLV Capability Sub-TLV, indicating the 
capability of Big-TLV. The old/legacy nodes ignore it. The new nodes get it.
If it is not required that all the nodes must have the same new information for 
using the new information, the new nodes can use the new information, the 
old/legacy nodes ignore the new information.
If all the nodes need to have the same new information for using the new 
information, every node needs to check if all the nodes support the Big-TLV. If 
all the nodes support it, every node uses the new information.

>From the above, we can see that "the protocol extensions (: container TLV and 
>Big-TLV capability Sub-TLV, which is protocol extensions for Big-TLV) can be 
>advertised and safely used in the presence of legacy nodes (which do not 
>understand the new advertisements)". The quoted is your definition of 
>backwards compatibility. So, the Big-TLV is backwards compatible.

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Thursday, December 7, 2023 1:07 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
li_zhenqi...@hotmail.com; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Huaimo -

There are some things on which people can legitimately have different opinions 
- the meaning of backwards compatibility is not one of them.

Your position seems to be that so long as I introduce a capability 
advertisement that controls whether a new advertisement is used when received 
that I can declare it "backwards compatible". By that definition everything is 
"backwards compatible".
This makes the term "backwards compatibility" meaningless.

This POV is neither useful nor sensible.

   Les


From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Thursday, December 7, 2023 6:07 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
li_zhenqi...@hotmail.com; Tony Li 
mailto:tony...@tony.li>>; Linda Dunbar 
mailto:linda.dun...@futurewei.com>>
Cc: Yingzhen Qu mailto:yingzhen.i...@gmail.com>>; 
draft-pkaneria-lsr-multi-...@ietf.org;
 lsr mailto:lsr@ietf.org>>
Subject: RE: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv 
(11/17/2023 - 12/09/2023)

Hi Les,

My responses are inline below with [HC].

Best Regards,
Huaimo

Folks -

The term "backwards compatibility" is getting abused here.

What does "backwards compatibility" mean in the context of a routing protocol 
like IS-IS?

It means that protocol extensions can be advertised and safely used in the 
presence of legacy nodes (which do not understand the new advertisements).

Neither MP nor Big-TLV are backwards compatible.
[HC]: Big-TLV is backwards compatible according to your definition of 
"backwards compatibility".

The authors of MP draft do not claim it is backwards compatible.

The authors of Big-TLV claim it is "backwards compatible" - but this is a false 
statement. Any attempt to use Big-TLV advertisements in the presence of legacy 
nodes will result in inconsistent and potentially dangerous behavior.
[HC]: Using Big-TLV advertisements in the presence of legacy nodes will not 
result in any inconsistent or potentially dangerous behavior. I have 

Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Parag Kaneriya]

I support adoption as co-author.




Juniper Business Use Only
From: Acee Lindem 
Sent: Friday, November 17, 2023 11:01 PM
To: Yingzhen Qu 
Cc: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Subject: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 
- 12/09/2023)

[External Email. Be cautious of content]

Speaking as WG member:

This draft has already resulted in a lot of good discussion and iteration. I 
support adoption as formalization of the existing solution with configuration, 
protocol level capability reporting, and IANA multi-TLV specification.

Thanks,
Acee


On Nov 17, 2023, at 12:23, Yingzhen Qu 
mailto:yingzhen.i...@gmail.com>> wrote:

Hi,

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org)

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

Thanks,
Yingzhen
___
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] IPR Poll for draft-pkaneria-lsr-multi-tlv

[Parag Kaneriya]

"No, I'm not aware of any IPR that applies to this draft"




Juniper Business Use Only
From: Yingzhen Qu 
Sent: Friday, November 17, 2023 10:31 PM
To: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
Cc: lsr-chairs 
Subject: IPR Poll for draft-pkaneria-lsr-multi-tlv

[External Email. Be cautious of content]

Hi,


This is an IPR call for draft-pkaneria-lsr-multi-tlv 
(draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS 
(ietf.org))


The authors and contributors please respond to this IPR call.



Please state either:

"No, I'm not aware of any IPR that applies to this draft"

or

"Yes, I'm aware of IPR that applies to this draft"



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3669, 5378 and 8179 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules"

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think

appropriate.



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,

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

Re: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03

[Parag Kaneriya]

I support this Draft.

Regards
Parag



Juniper Business Use Only
From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Wednesday, November 23, 2022 1:31 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for 
Dense Topologies" - draft-white-lsr-distoptflood-03

[External Email. Be cautious of content]

LSR WG,

This begins a 2 week WG adoption call for the following draft:

https://datatracker.ietf.org/doc/draft-white-lsr-distoptflood/

The draft would be adopted on the Informational or Experimental track.

Please indicate your support or objection by December 7th, 2022.
Also indicate whether you believe it should be Informational or Experimental 
track.

Thanks,
Acee


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

Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Parag Kaneriya]

Mixing data plan using same TLV may lead to forwarding issue. if you do so it 
is required to upgrade all the node in the network which is practically not 
possible.  Hence Different TVL for IP flex algo required. 

Regards
Parag

-Original Message-
From: Peter Psenak  
Sent: Tuesday, May 3, 2022 1:35 PM
To: Aijun Wang ; Peter Psenak 

Cc: Acee Lindem (acee) ; lsr@ietf.org; 
draft-ietf-lsr-ip-flexa...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - 
"IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[External Email. Be cautious of content]


Aijun,

On 03/05/2022 09:59, Aijun Wang wrote:
> Hi, Peter:
> The definition of FAPM for IS-IS and OSPF doesn’t prevent from it is used for 
> the intra-area prefixes.
> If we advertise the different loopback addresses via the FAPM, associate them 
> to different Flex-Algo and related metrics, and does not allocate the MPLS 
> SID, we can achieve the IP-Flex effect then.

as I said, we can not mix metrics for different data-planes.

> So, what’s the additional value of the IP-Flexalgo draft then?

please read the draft. It defines the flex-algo for IP data plane.

thanks,
Peter



>
> Aijun Wang
> China Telecom
>
>> On May 3, 2022, at 14:46, Peter Psenak  
>> wrote:
>>
>> Aijun,
>>
>>> On 03/05/2022 00:47, Aijun Wang wrote:
>>> Hi, Acee:
>>> The questions raised at 
>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/RlHphXCwxMbgGvcBV_m24xiDzS0/__;!!NEt6yMaO-gk!G17D9bO4s42aBMCFpgMcDLEOsyVydCNbfKW5UAkmHbgLdgKiYWY1ryBShvdDHk53sdkcOyP_dXaI7uY$
>>>   
>>> >>  > has not been answered.
>>
>> IS-IS Flexible Algorithm Prefix Metric Sub-TLV” and “OSPF Flexible Algorithm 
>> Prefix Metric Sub-TLV” are defined for advertisement of algorithm specific 
>> metric for inter-area inter-AS prefixes for SR-MPLS data-plane.
>>
>> SR MPLS and IP are independent data-planes used for flex-algo. We can not 
>> mix their metric.
>>
>> thanks,
>> Peter
>>
>>> Aijun Wang
>>> China Telecom
> On May 2, 2022, at 23:00, Acee Lindem (acee) 
>  wrote:

 The WG last call has completed. We will submit an updated version of the 
 document for publication with the terminology changes based on the 
 discussion amongst the authors, Ketan, Robert, Gyan, and others.

 Thanks,
 Acee

 *From: *Lsr  on behalf of "Acee Lindem (acee)" 
 
 *Date: *Thursday, April 7, 2022 at 3:07 PM
 *To: *"lsr@ietf.org" 
 *Cc: *"draft-ietf-lsr-ip-flexa...@ietf.org" 
 
 *Subject: *[Lsr] Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 
 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

 This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04.  The draft 
 had a lot of support and discussion initially and has been stable for some 
 time. Please review and send your comments, support, or objection to this 
 list before 12 AM UTC on April 22^nd , 2022.

 Thanks,
 Acee

 ___
 Lsr mailing list
 Lsr@ietf.org
 https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!G17D9bO4s42aBMCFpgMcDLEOsyVydCNbfKW5UAkmHbgLdgKiYWY1ryBShvdDHk53sdkcOyP_BMwKUC4$
>>
>
>

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

Re: [Lsr] Working Group Last Call IPR poll for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"

[Parag Kaneriya]

Hello All,

I am not aware of any IPR beyond that which has already been disclosed to the 
IETF and is referenced in your email.

Regards
Parag

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Friday, April 8, 2022 12:40 AM
To: draft-ietf-lsr-ip-flexa...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] Working Group Last Call IPR poll for 
draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP 
Networks"

[External Email. Be cautious of content]

Authors,

The following IPR has been disclosed:

https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-lsr-ip-flexalgo

Are you aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ip-flexalgo-04?

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] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[Parag Kaneriya]

I support this Draft.

Regards
Parag

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, November 23, 2021 1:17 AM
To: lsr@ietf.org
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05

[External Email. Be cautious of content]

This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please 
post your support or objection to this list by 12:00 AM UTC on Dec 14th , 2021. 
Also please post your comments on the draft. I’m allowing as extra week as I 
like to get some additional reviews – although my comments have been addressed.

Thanks,
Acee

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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Parag Kaneriya]

IP Algorithm SUBTLV indicate the participation for particular flex algo by 
node.  Participation doesn't depend on whether it support ipv4 prefix or ipv6 
prefix.  Node which doesn't support particular family will not install that 
family route.

Regards
Parag



Juniper Business Use Only
From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, December 9, 2020 3:40 PM
To: Acee Lindem (acee) ; lsr 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi authors,

Here is one comment following the previous discussion on the mail list and the 
IETF meeting.

The IP Algorithm TLV is defined to advertise the IP Flex-Algorithm 
participation information, there is no separate TLV for IPv4 or IPv6 Flex-Algo 
participation. If some nodes participate in IPv4 Flex-Algo 128, and some of 
these nodes participate in IPv6 Flex-Algo 128, how to ensure that the path 
computed for IPv6 Flex-Algo will not use the nodes which only participate in 
IPv4 Flex-Algo 128?

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[Parag Kaneriya]

Hello Aijun,

Every router by default support algo 0.  When router support IP-FLEX algo along 
with default algo, we need to be deterministic when there is conflict of prefix 
advertise in both algo. This conflict might be due to mis config. So when such 
condition arise, prefix belong to default algo should give priority to be 
install in forwarding table.

Regards
Parag


Juniper Business Use Only
From: Lsr  On Behalf Of Aijun Wang
Sent: Thursday, December 3, 2020 7:02 AM
To: 'Acee Lindem (acee)' ; 'lsr' 
Subject: Re: [Lsr] WG Adoption Call for "IGP Flexible Algorithms 
(Flex-Algorithm) In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

[External Email. Be cautious of content]

Hi, authors:

Want to confirm one thing:
Does the mechanism described in this draft support the automatic fallback from 
"flex algorithm" to the "traditional least-cost algorithm"?
That is to say, can one prefix exists both in the "flex algorithm" table and 
"traditional least-cost algorithm" table, the router prefer to forwarding the 
packet based on the former table, and if not hit, then lookup the latter table?

>From the context of the document, the answer seems not, or even on the 
>contrary?
In cases where a prefix advertisement is received in both a IPv4
   Prefix Reachability TLV and an IPv4 Algorithm Prefix Reachability
   TLV, the IPv4 Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.

If so, what the value to deploy such flexible algorithm within the network? 
From my POV, the reason that we want to deploy such mechanism is that we want 
to differentiate the path(result of flex algorithm) of some traffic from 
that(result of traditional least-cost algorithm) of most other normal traffic.

Best Regards

Aijun Wang
China Telecom

From: lsr-boun...@ietf.org 
mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, December 2, 2020 5:13 AM
To: lsr mailto:lsr@ietf.org>>
Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithms (Flex-Algorithm) 
In IP Networks" - draft-bonica-lsr-ip-flexalgo-01

This IP Flex Algorithm draft generated quite a bit of discussion on use cases 
and deployment prior to IETF 109 and there was generally support for WG 
adoption. This begins a two week WG adoption call. Please indicate your support 
or objection to WG adoption on this list prior to 12:00 AM UTC on December 
16th, 2020. Also, review comments are certainly welcome.
Thanks,
Acee


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

Re: [Lsr] [spring] clarification of END Point behavior in draft-ietf-spring-srv6-network-programming

[Parag Kaneriya]

Hello,

I am going through recent draft 
https://tools.ietf.org/pdf/draft-ietf-spring-srv6-network-programming-16.pdf

Changes are follow ,

4.1. End: Endpoint

S01. When an SRH is processed {
S02. If (Segments Left == 0) {
S03. Proceed to process the next header in the packet, whose type is identified 
by the Next Header field in the routing header.
S04. }
S05. If (IPv6 Hop Limit <= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address, Code 0 (Hop 
limit exceeded in transit), Interrupt packet processing and discard
 the packet.
S07. }


With these change, I have below few question


  1.  Can END SID can be last SID of the SID list ?   earlier draft (not sure 
which version), it was explicitly mentioned that last SID can't be END sid ( 
Most basic flavors ).
  2.  IF yes then When/Who will remove the SRH header when last sid is END SID 
in the sid list.

Regards
Parag


Juniper Business Use Only
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr