[Lsr] Re: Comments on draft-ietf-lsr-distoptflood-07

We've had few sides meeting on this, and reviews. We were asked to remove the "election stuff". https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-distoptflood-06&url2=draft-ietf-lsr-distoptflood-07&difftype=--html At this point, I would like to turn the table to other operators (than me)

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Hi Robert, inlines From: Lsr on behalf of Robert Raszuk Date: Monday, August 28, 2023 at 12:00 PM To: "Hassan, Shehzad" , Daniel Bernier Cc: lsr , "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" Subject: [EXT]Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement"

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Hi wg, I support the adoption of UPA. This solution is key when summarization is used for IPv6/SRv6 networks. Thanks Dan On 2023-08-23, 3:58 PM, "Lsr on behalf of Acee Lindem" mailto:lsr-boun...@ietf.org> on behalf of acee.i...@gmail.com > wrote: LSR Working Grou

Re: [Lsr] IPR Poll for Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name and IPR link)

Hi Acee, I am not aware of any IPR regarding this work. Cheers, Dan On 2023-08-23, 4:06 PM, "Acee Lindem" mailto:acee.i...@gmail.com>> wrote: Co-Authors, Are you aware of any IPR that applies to draft-posenak-lsr-igp-ureach-prefix-announce-04? If so, has this IPR been disclosed in compli

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

Yes, I support this draft Thanks, Dan From: Lsr on behalf of "Acee Lindem (acee)" Date: Tuesday, November 22, 2022 at 3:01 PM To: "lsr@ietf.org" Subject: [EXT][Lsr] WG Adoption Call for "IS-IS Optimal Distributed Flooding for Dense Topologies" - draft-white-lsr-distoptflood-03 LSR WG, This

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

enak-lsr-igp-ureach-prefix-announce”, is describing a use case/architecture and what you can do w/ RFC5305/RFC5308 – its “informational” 😊 G/ From: Robert Raszuk Sent: Thursday, June 16, 2022 11:54 AM To: Van De Velde, Gunter (Nokia - BE/Antwerp) Cc: Gyan Mishra ; Voyer, Daniel ; draft-

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Hi Gunter, Thanks for your comments, The idea, here, with summarization is to "reduce" the LSDB quite a lots and make a given backbone much more scalable / flexible and allow to simplify NNI's within that given backbones considerably. Summarization is "needed" for better scale and, in the conte

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Hi Gunter, Thanks for your comments, The idea, here, with summarization is to "reduce" the LSDB quite a lots and make a given backbone much more scalable / flexible and allow to simplify NNI's within that given backbones considerably. Summarization is "needed" for better scale and, in the cont

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

g in those 2 RFC ? Basically, if I ignore “draft-ppsenak-lsr-igp-ureach-prefix-announce” since it’s only informational, and wanted to do these RFCs – what’s missing ? Thanks, Cheers, --Bruno Orange Restricted From: Voyer, Daniel Sent: Wednesday, June 15, 2022 6:06 PM To: DECRAENE Bruno INNOV

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno, Thanks for your comment on the draft. I too, have a minor disagreement on your disagreement. The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as “a use case”/informational. In this case, a PE being hidden from other area due to route summarization. The draft is n

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

Peter, On 2021-08-20, 8:46 AM, "Lsr on behalf of Peter Psenak" wrote: Dan, On 20/08/2021 14:14, Voyer, Daniel wrote: > But generic-metric is a “new attribute” and is not in ASLA – RFC8919, > why can’t we use TLV 22 again ? because any new link att

Re: [Lsr] RFC 8919, RFC 8920, Flex Algo, and Flex Algo BW Constraints

But generic-metric is a “new attribute” and is not in ASLA – RFC8919, why can’t we use TLV 22 again ? From: Lsr on behalf of Jeff Tantsura Date: Thursday, August 19, 2021 at 8:14 PM To: Yingzhen Qu Cc: "Les Ginsberg (ginsberg)" , Ron Bonica , "Acee Lindem (acee)" , "lsr@ietf.org" Subject:

Re: [Lsr] Generic metric: application-specific vs application-independent

Sharddha, From my last email in the list, I am also asking the same - can you be specific about what ASLA doesn't provide ? Maybe you have a point that I don't see. dan On 2021-07-30, 3:42 AM, "Lsr on behalf of Peter Psenak" wrote: Shraddha, On 30/07/2021 06:53, Shraddha Hegde wrote

Re: [Lsr] Generic metric: application-specific vs application-independent

Hi there, I completely agree with Les here. ASLA exist already as per RFC8919, RFC8920. Example of application is here: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-17#section-12. Generic Metrics fits the application specific paradigm. What are we trying to accomplish here and

Re: [Lsr] IPR Poll for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

Hi Acee, As a contributor, I am not aware of any IPR. dan From: "Acee Lindem (acee)" Date: Thursday, May 9, 2019 at 10:42 AM To: Stefano Previdi , "Paul Wells (pauwells)" , "Voyer, Daniel" , "Ketan Talaulikar (ketant)" , "satoru.matsush...@g.