Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

[Jeff Tantsura]

+1 Cheers,Jeff From: Les Ginsberg (ginsberg)Sent: Friday, August 12, 2022 9:05 AMTo: 龚立艳; lsr@ietf.org; shraddhaSubject: Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo Liyan – You agree that there is an existing way to prune links from the IGP SPF.Still, you insist that an extension that requires ALL routers – whether they support flex algo or not – to utilize a new advertisement when computing algo 0 SPF is necessary.Your rationale for this is that this allows you to use IGP Metric for flex algo in cases where the IGP metric would have been set to maximum.But we already have the ability to define metrics specific to flex algo – and this is greatly enhanced by the generic metric defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ Requiring a non backwards compatible extension to be used in base protocol operation in order to support a new feature is exactly what we MUST NOT do when introducing protocol extensions. My opinion is unchanged – this is a bad idea – and completely unnecessary.    Les  From: 龚立艳  Sent: Friday, August 12, 2022 2:16 AMTo: lsr@ietf.org; Les Ginsberg (ginsberg) ; shraddha Subject: Re:Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo  Hi Shraddha and Les, Sorry for late reply and thanks for your comments.  Yes, the maximum link metric mechanism is an option as described in section 4 of the draft.  But, it has two defects which we also wanted to discuss in ietf 114 meeting. Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.Secondly, it does not work with OSPF. For OSPF,the links with maximummetric value(65535) are also included in the SPF calculation,even if not preferred. If there are no other preferred paths,the Flex-Algoritnm links will still affect the result of thenormal SPF calculation. Due to the time constraints,The presentation has been moved to the interim meeting on 2022-09-21. For more detail, please refer to the slides.https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.In view of these two cases, new protocol extension becomes necessary.  As for the backward incompatible issues, we think it can be avoided by deployment.  For example, the new extension should be deployed in sync with the Flex-Algo feature, so that all the routers in one IGP domain will run the same software version.  Looking forward to your reply. Best Regards,Liyan  邮件原文发件人："Les Ginsberg \\(ginsberg\\)" 收件人：Shraddha Hegde  ,"lsr@ietf.org" 抄　送: (无)发送时间：2022-07-29 21:14:08主题：Re: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo    I fully agree with Shraddha. In fact Section 4 of the draft makes clear why no protocol extensions are needed.    Les From: Lsr  On Behalf Of Shraddha HegdeSent: Friday, July 29, 2022 2:18 AMTo: lsr@ietf.orgSubject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo Authors,  I suggest that the usecase can be satisfied using the backward compatibleMaximum link metric mechanism defined in the draft.I don’t see any need to define protocol extensions,that are backward incompatible and can cause serious issues in the networkin the presence of older implementations. RgdsShraddha Juniper Business Use Only  
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Gyan Mishra]

I support publication of this specification for the SRV6 OSPFV3 extension
as the SRV6 ISIS extension is in RFC queue.

Do we have any implementations of this OSPFv3 extension?

Thanks

Gyan
On Fri, Jul 29, 2022 at 1:17 PM Acee Lindem (acee)  wrote:

> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call,
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The
> extra week is to account for PIST (Post-IETF Stress Syndrome). The
> corresponding IS-IS draft is already on the RFC Queue and there are
> implementations.
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

[Acee Lindem (acee)]

Speaking as WG member:

I agree with Les. A non-backward compatible change is a non-starter.

I’m not sure why you’d need to present this again at the Interim unless you 
provide backward compatibility.

Thanks,
Acee

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Friday, August 12, 2022 at 12:05 PM
To: 龚立艳 , "lsr@ietf.org" , shraddha 

Subject: Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

Liyan –

You agree that there is an existing way to prune links from the IGP SPF.
Still, you insist that an extension that requires ALL routers – whether they 
support flex algo or not – to utilize a new advertisement when computing algo 0 
SPF is necessary.
Your rationale for this is that this allows you to use IGP Metric for flex algo 
in cases where the IGP metric would have been set to maximum.
But we already have the ability to define metrics specific to flex algo – and 
this is greatly enhanced by the generic metric defined in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

Requiring a non backwards compatible extension to be used in base protocol 
operation in order to support a new feature is exactly what we MUST NOT do when 
introducing protocol extensions.

My opinion is unchanged – this is a bad idea – and completely unnecessary.

   Les


From: 龚立艳 
Sent: Friday, August 12, 2022 2:16 AM
To: lsr@ietf.org; Les Ginsberg (ginsberg) ; shraddha 

Subject: Re:Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo




Hi Shraddha and Les,



Sorry for late reply and thanks for your comments.



Yes, the maximum link metric mechanism is an option as described in section 4 
of the draft.



But, it has two defects which we also wanted to discuss in ietf 114 meeting.



Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.

Secondly, it does not work with OSPF. For OSPF,the links with maximummetric 
value(65535) are also included in the SPF calculation,even if not preferred. If 
there are no other preferred paths,the Flex-Algoritnm links will still affect 
the result of thenormal SPF calculation.



Due to the time constraints,The presentation has been moved to the interim 
meeting on 2022-09-21. For more detail, please refer to the slides.

https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.



In view of these two cases, new protocol extension becomes necessary.



As for the backward incompatible issues, we think it can be avoided by 
deployment.



For example, the new extension should be deployed in sync with the Flex-Algo 
feature, so that all the routers in one IGP domain will run the same software 
version.



Looking forward to your reply.



Best Regards,

Liyan




邮件原文
发件人："Les Ginsberg \\(ginsberg\\)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
收件人：Shraddha Hegde  
mailto:shraddha=40juniper@dmarc.ietf.org>>,"lsr@ietf.org"
 mailto:lsr@ietf.org>>
抄　送: (无)
发送时间：2022-07-29 21:14:08
主题：Re: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo


I fully agree with Shraddha.

In fact Section 4 of the draft makes clear why no protocol extensions are 
needed.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Friday, July 29, 2022 2:18 AM
To: lsr@ietf.org
Subject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

Authors,


I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don’t see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.

Rgds
Shraddha


Juniper Business Use Only


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

Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

[Les Ginsberg (ginsberg)]

Liyan –

You agree that there is an existing way to prune links from the IGP SPF.
Still, you insist that an extension that requires ALL routers – whether they 
support flex algo or not – to utilize a new advertisement when computing algo 0 
SPF is necessary.
Your rationale for this is that this allows you to use IGP Metric for flex algo 
in cases where the IGP metric would have been set to maximum.
But we already have the ability to define metrics specific to flex algo – and 
this is greatly enhanced by the generic metric defined in 
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/

Requiring a non backwards compatible extension to be used in base protocol 
operation in order to support a new feature is exactly what we MUST NOT do when 
introducing protocol extensions.

My opinion is unchanged – this is a bad idea – and completely unnecessary.

   Les


From: 龚立艳 
Sent: Friday, August 12, 2022 2:16 AM
To: lsr@ietf.org; Les Ginsberg (ginsberg) ; shraddha 

Subject: Re:Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo




Hi Shraddha and Les,



Sorry for late reply and thanks for your comments.



Yes, the maximum link metric mechanism is an option as described in section 4 
of the draft.



But, it has two defects which we also wanted to discuss in ietf 114 meeting.



Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.

Secondly, it does not work with OSPF. For OSPF,the links with maximummetric 
value(65535) are also included in the SPF calculation,even if not preferred. If 
there are no other preferred paths,the Flex-Algoritnm links will still affect 
the result of thenormal SPF calculation.



Due to the time constraints,The presentation has been moved to the interim 
meeting on 2022-09-21. For more detail, please refer to the slides.

https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.



In view of these two cases, new protocol extension becomes necessary.



As for the backward incompatible issues, we think it can be avoided by 
deployment.



For example, the new extension should be deployed in sync with the Flex-Algo 
feature, so that all the routers in one IGP domain will run the same software 
version.



Looking forward to your reply.



Best Regards,

Liyan




邮件原文
发件人："Les Ginsberg \\(ginsberg\\)" 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
收件人：Shraddha Hegde  
mailto:shraddha=40juniper@dmarc.ietf.org>>,"lsr@ietf.org"
 mailto:lsr@ietf.org>>
抄　送: (无)
发送时间：2022-07-29 21:14:08
主题：Re: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo


I fully agree with Shraddha.

In fact Section 4 of the draft makes clear why no protocol extensions are 
needed.

   Les

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Shraddha Hegde
Sent: Friday, July 29, 2022 2:18 AM
To: lsr@ietf.org
Subject: [Lsr] Comments on draft-gong-lsr-exclusive-link-for-flex-algo

Authors,


I suggest that the usecase can be satisfied using the backward compatible
Maximum link metric mechanism defined in the draft.
I don’t see any need to define protocol extensions,
that are backward incompatible and can cause serious issues in the network
in the presence of older implementations.

Rgds
Shraddha


Juniper Business Use Only


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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Susan Hares]

Support.

This matches the IS-IS SRv6 extensions, and it is ready to publish.

Sue

From: Lsr  On Behalf Of Dongjie (Jimmy)
Sent: Wednesday, August 10, 2022 11:22 AM
To: Acee Lindem (acee) ; lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

Support. It provides necessary OSPF extensions for SRv6 which is equivalent to 
the IS-IS SRv6 extensions. Best regards, Jie  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  
‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External 
(jie.dong=40huawei@dmarc.ietf.org)
  Report This 
Email
  FAQ  GoDaddy Advanced Email Security, 
Powered by INKY

Support.

It provides necessary OSPF extensions for SRv6 which is equivalent to the IS-IS 
SRv6 extensions.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr mailto:lsr@ietf.org>>
Cc: 
draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.


https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Huaimo Chen]

Hi Everyone,

I read through the document and support its publication.

Best Regards,
Huaimo



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

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)



As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.



https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/





Thanks,

Acee & Chris




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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Acee Lindem (acee)]

Speaking as WG member:

I support publication of this draft. I reviewed the draft and my comments have 
been incorporated.

Thanks,
Acee

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

Date: Friday, July 29, 2022 at 1:18 PM
To: lsr 
Cc: "draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org" 

Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Lizhenbin]

Hi All,
I support to publish the draft as the co-author. It has been stable and well 
written.

Best Regards,
Zhenbin (Robin)






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

发件人：Acee Lindem (acee) 
收件人：lsr 
抄 送：draft-ietf-lsr-ospfv3-srv6-extensions 

时 间：2022-07-30 01:17:42
主 题：Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations.

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/


Thanks,
Acee & Chris


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

Re: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

[Lizhenbin]

Hi All,

I am not aware of any undisclosed IPR that applies to this draft.



Thanks,
Zhenbin (Robin)





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

发件人：Acee Lindem (acee) 
收件人：Lizhenbin 
抄 送：lsr ;draft-ietf-lsr-ospfv3-srv6 

时 间：2022-08-06 03:02:10
主 题：Re: IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

Hi Robin,
I’m only missing your IPR declaration.
Thanks,
Acee

From: Huzhibo 
Date: Wednesday, August 3, 2022 at 11:08 PM
To: Acee Lindem , "draft-ietf-lsr-ospfv3-s...@ietf.org" 

Cc: lsr 
Subject: RE: IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt


Hi Acee,



I am not aware of any undisclosed IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt



thanks,

Zhibo


From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, July 30, 2022 1:15 AM
To: draft-ietf-lsr-ospfv3-s...@ietf.org
Cc: lsr 
Subject: [Lsr] IPR Poll Coincident with the Working Group Last Call for "OSPFv3 
Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt

Co-authors,

Are you aware of any IPR that applies to 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt?

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 & Chris


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

Re: [Lsr] FW: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-lsr-ospfv3-srv6-extensions

[Lizhenbin]

Hi Acee,
Yes. I asked them to check the consistency with the IPR claims of SRV6 ISIS and 
if necessary disclose as the IETF rules.


Best Regards,
Robin





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

发件人：Acee Lindem (acee) 
收件人：Zhenbin Lin (zhenblin) 
抄 送：lsr 
时 间：2022-08-11 22:51:11
主 题：[Lsr] FW: IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR 
related to draft-ietf-lsr-ospfv3-srv6-extensions

Hey Robin,

Haven't received your WG last call IPR poll response yet - I guess you were 
waiting for this to be posted?

Thanks,
Acee

On 8/11/22, 10:47 AM, "Lsr on behalf of IETF Secretariat" 
 wrote:

Dear Zhenbin Li, Zhibo Hu, Ketan Talaulikar, Peter Psenak:


An IPR disclosure that pertains to your Internet-Draft entitled "OSPFv3
Extensions for SRv6" (draft-ietf-lsr-ospfv3-srv6-extensions) was submitted 
to
the IETF Secretariat on 2022-08-10 and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures" (/ipr/5785/history/). The title of
the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR
related to draft-ietf-lsr-ospfv3-srv6-extensions"


Thank you

IETF Secretariat


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

Re: [Lsr] Comments ondraft-gong-lsr-exclusive-link-for-flex-algo

[龚立艳]

Hi Shraddha and Les,





Sorry for late reply and thanks for your comments. 





Yes, the maximum link metric mechanism is an option as described in section 4 
of the draft. 





But, it has two defects which we also wanted to discuss in ietf 114 meeting.





Firstly, it restricts the Flex-Algorithm from using IGP-Cost as its metric-type.


Secondly, it does not work with OSPF. For OSPF,the links with maximummetric 
value(65535) are also included in the SPF calculation,even if not preferred. If 
there are no other preferred paths,the Flex-Algoritnm links will still affect 
the result of thenormal SPF calculation.





Due to the time constraints,The presentation has been moved to the interim 
meeting on 2022-09-21. For more detail, please refer to the slides.


https://datatracker.ietf.org/meeting/114/materials/slides-114-lsr-13-exclusive-link-for-flex-algo-00.
  


  


In view of these two cases, new protocol extension becomes necessary. 





As for the backward incompatible issues, we think it can be avoided by 
deployment. 





For example, the new extension should be deployed in sync with the Flex-Algo 
feature, so that all the routers in one IGP domain will run the same software 
version. 





Looking forward to your reply.





Best Regards,


Liyan





邮件原文发件人："Les Ginsberg \\(ginsberg\\)" 
收件人：Shraddha Hegde  
,"lsr@ietf.org" 抄　送: 
(无)发送时间：2022-07-29 21:14:08主题：Re: [Lsr] Comments on 
draft-gong-lsr-exclusive-link-for-flex-algo 

I fully agree with Shraddha.


 


In fact Section 4 of the draft makes clear why no protocol extensions are 
needed.


 


   Les


 




From: Lsr  On Behalf Of Shraddha Hegde Sent: Friday, July 
29, 2022 2:18 AM To: lsr@ietf.org Subject: [Lsr] Comments on 
draft-gong-lsr-exclusive-link-for-flex-algo




 


Authors,


 


 


I suggest that the usecase can be satisfied using the backward compatible


Maximum link metric mechanism defined in the draft.


I don’t see any need to define protocol extensions,


that are backward incompatible and can cause serious issues in the network


in the presence of older implementations.


 


Rgds


Shraddha


 


Juniper Business Use Only





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