Re: [Lsr] draft-lin-lsr-flex-algo-metric-00

hanks, Mengxiao Chen -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak Sent: Thursday, March 24, 2022 11:09 PM To: lsr@ietf.org Subject: [Lsr] draft-lin-lsr-flex-algo-metric-00 Hi, as I was unable to make my comments during the presentation, let me put

[Lsr] draft-lin-lsr-flex-algo-metric-00

Hi, as I was unable to make my comments during the presentation, let me put them here: When we started with the flex-algo work, there has been a lengthy discussion on why not to use the multi-topology (MT) instead. We always wanted flex-algo to be light weight and as a result easy to deploy

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Tony, On 04/03/2022 18:30, Tony Li wrote: Peter, Once we get into FAD Sub-TLV overflow business, we would have to define, for each FAD sub-TLV, whether multiple of them can exist and how to resolve conflicts if only one is allowed. For all existing ones, I can only think of SRLG to be the c

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Tony, On 04/03/2022 17:53, Tony Li wrote: On Mar 4, 2022, at 8:50 AM, Peter Psenak <mailto:ppse...@cisco.com>> wrote: not at all. I just don't want to get into business of merging info from several FAD's sub-TLVs of the same type unless there is a compelling reason

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Tony, On 04/03/2022 17:36, Tony Li wrote: Hi Peter, I would prefer to address the "else clause"  in a following way: a) any FAD sub-TLV MUST only appear once in a the FAD definition for a given algorithm from a given source b) in case the FAD sub-TLV appear multiple times, the values

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Tony, On 03/03/2022 16:06, Tony Li wrote: Peter, I believe there is a subtle difference between what each of you is saying: a) Tony says that there may be many constraints used for a particular flex-algo, so that we may not be able to fit them in a single FAD Sub-TLV. I agree, we better ad

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Hi Tony, Gunter, On 02/03/2022 16:22, Tony Li wrote: Hi Peter, I believe that your assumption is that the FAD for a single algorithm can never grow bigger as a 256 octets. yes, that is indeed a limitation. Perhaps we should address it somehow? Coders have to deal with overflow conditio

Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

ld be covered by the specification that defines the Sub-TLV. thanks, Peter G/ -Original Message- From: Peter Psenak Sent: Wednesday, March 2, 2022 8:40 AM To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; Tony Li ; lsr Subject: Re: [Lsr] Fwd: New Version Notification for draft-pka

Re: [Lsr] Fwd: New Version Notification for draft-pkaneria-lsr-multi-tlv-00.txt

Gunter, I'm afraid you are mixing two different things. Flex-algo draft limits the FAD advertisement for a SINGLE algo to one on any originator. It DOES NOT limit in any way how many FADs for DIFFERENT algos any originator can send. There are implementations that already support more FADs

Re: [Lsr] Adoption Question Stub-Link vs RFC5316

that as as well. thanks, Peter On 18/02/2022 13:14, Christian Hopps wrote: Peter Psenak writes: Chris, the draft attempt to use the local subnet information for identifying two endpoints of the same link. That seems wrong in itself. In addition: The -03 revision uses other methods to ident

Re: [Lsr] Adoption Question Stub-Link vs RFC5316

Chris, the draft attempt to use the local subnet information for identifying two endpoints of the same link. That seems wrong in itself. In addition: 1) We have link local/remote IDs (and IP addresses) to pair the two endpoints of the link in both OSPF and ISIS. We do not need another mechani

Re: [Lsr] IPR Poll Coinciding with WGLC for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee, I am not aware of any IPR associated with this draft. Thanks, Peter On 27/01/2022 18:15, Acee Lindem (acee) wrote: Draft Authors, Are you aware of any IPR that applies to draft-ietf-ospf-bfd-strict-mode-04? If so, has this IPR been disclosed in compliance with IETF IPR rules (se

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Tony, On 26/01/2022 16:46, Tony Li wrote: Peter, The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. yes, but how much data? Minimal. It'

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

. Peter The reason I mention this here is that whatever we do we should alway take end to end user application analysis into account. Thx, R. On Wed, Jan 26, 2022 at 10:20 AM Peter Psenak mailto:40cisco@dmarc.ietf.org>> wrote: Tony, On 25

Re: [Lsr] New Version Notification for draft-li-lsr-liveness-00.txt

Tony, On 25/01/2022 17:11, Tony Li wrote: Peter, we just moved the problem from IGPs to some "other" application. That was the entire point. Hopefully, you see that as a good thing. actually I don't. I want to solve the problem, not to move it to other app running on the same nodes.

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

e. Thx, R. On Tue, Jan 25, 2022 at 4:42 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: On 25/01/2022 15:18, Robert Raszuk wrote: > Peter, > > You clearly missed the added new sentence to section 4.3 in version -01 > > It is RECOMM

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

PE to ABR registrations only. I have not even counted the inter-ABR ones. Peter Thx, R On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: On 25/01/2022 14:07, Robert Raszuk wrote: > Peter, > > Your math is off. no, it's

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

ABR, 10 million network wide ABRs will "aggregate" atomic registrations to summaries when passing them to other ABRs. Please recalculate, Thx, R. On Tue, Jan 25, 2022 at 12:25 PM Peter Psenak mailto:40cisco@dmarc.ietf.org>> wrote: Tony, I'm going to us

Re: [Lsr] BGP vs PUA/PULSE

On 24/01/2022 21:27, Christian Hopps wrote: Peter Psenak writes: On 24/01/2022 16:19, Christian Hopps wrote: Peter Psenak writes: Chris, On 24/01/2022 10:29, Christian Hopps wrote: Again KISS applies here: If the summarization process *doesn't work* for a given pre

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Tony, I'm going to use my target scale of 100k PEs, split in 100 areas, 2 ABRs per area, with the average VPN size of 100. What you propose would result in: 1. 100k registrations in each ABR, 10 million network wide 2. 1200 TCP sessions in each ABR, 220k TCP sessions network wide Above is pr

Re: [Lsr] BGP vs PUA/PULSE

On 24/01/2022 16:19, Christian Hopps wrote: Peter Psenak writes: Chris, On 24/01/2022 10:29, Christian Hopps wrote: Again KISS applies here: If the summarization process *doesn't work* for a given prefix P, then *don't use summarization* for prefix P! above simply doe

Re: [Lsr] BGP vs PUA/PULSE

of them important, while others not. thanks, Peter Thanks, Chris. [As wg member] Best Regards Aijun Wang China Telecom -Original Message- From: Christian Hopps Sent: Monday, January 24, 2022 1:50 PM To: Gyan Mishra Cc: Christian Hopps ; Aijun Wang ; Hannes Gredler ; John E Dr

Re: [Lsr] BGP vs PUA/PULSE

es not change any of the above though :) thanks, Peter On Thu, Jan 6, 2022 at 10:25 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Bruno, the PIC is used unchanged with PULSE. The only difference is that the PIC is triggered by the pulse arrival, instead of t

Re: [Lsr] BGP vs PUA/PULSE

Bruno, On 06/01/2022 11:18, bruno.decra...@orange.com wrote: Peter, From: Peter Psenak Sent: Thursday, January 6, 2022 11:03 AM Bruno, On 06/01/2022 10:40, bruno.decra...@orange.com wrote: Peter, Thanks for your answer. Please see inline [Bruno] From: Peter Psenak Sent: Thursday

Re: [Lsr] BGP vs PUA/PULSE

Bruno, On 06/01/2022 10:40, bruno.decra...@orange.com wrote: Peter, Thanks for your answer. Please see inline [Bruno] From: Peter Psenak Sent: Thursday, January 6, 2022 10:25 AM Bruno, the PIC is used unchanged with PULSE. [Bruno] OK. Therefore, from a FIB standpoint, does this mean

Re: [Lsr] BGP vs PUA/PULSE

version of the draft. It will be interesting to learn the criteria that enable an ABR to reliably identify the scenarios you've suggested are outside the scope of the PULSE draft and should be handled differently. Regards, Greg On Tue, Jan 4, 2022 at 10:08 AM P

Re: [Lsr] BGP vs PUA/PULSE

rsky ; Les Ginsberg (ginsberg) ; Christian Hopps ; Aijun Wang ; Shraddha Hegde ; Tony Li ; Hannes Gredler ; lsr ; Peter Psenak *Subject:* Re: [Lsr] BGP vs PUA/PULSE Hi Robert The goal of the draft is providing egress protection when summarization is used similar to RFC 8679 Egress protecti

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun, On 05/01/2022 16:20, Aijun Wang wrote: [WAJ] The above remote information must be configured manually on the local device. It is paired by manual. Thinking there are many links among the ASBRs, would you like to configure them manually for every remote ends on each link? We are looking

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun, please see inline (##PP): On 05/01/2022 13:01, Aijun Wang wrote: Hi, Peter: Thanks for your comments. Please see replies inline. Aijun Wang China Telecom On Jan 5, 2022, at 18:45, Peter Psenak wrote: Hi, I'm afraid the draft has some serious issues that would need

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 05/01/2022 12:57, Robert Raszuk wrote: if the router supports NSR or NSF such event will be invisible to other routers, including ABR. Without these mechanisms the neighboring routers would tear down the adjacency anyway. So are you going to add to the draft special

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 05/01/2022 12:27, Robert Raszuk wrote: Peter, Two other points .. #1 - Imagine PE is performing control plane restart or ISSU. How ABR will be able to detect this and instead of keep the potential disruption local to the area ? Note that data plane of the PE is working all the ti

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, I'm afraid the draft has some serious issues that would need to be addressed if it is to become a WG document. Below comments use ISIS as an example, but most of it applies to OSPF as well. 1. The draft says: "ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE inform

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 04/01/2022 20:05, Robert Raszuk wrote: no. It's a limit not a delay. That is directly contradicting the message from Les stating that this is going to be a rate limit not cut out. */"[LES2:] It is reasonable to limit the rate of pulses sent. "/* If too many edge nodes l

Re: [Lsr] BGP vs PUA/PULSE

e are trying to address with pulses. The limit is not described in the published version of the draft. We are working on the updated version that will include the description of it. thanks, Peter Regards, Greg On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak <mailto:ppse...@cisco.com>> wrote

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 04/01/2022 11:42, Robert Raszuk wrote: Peter, > Take SR-MPLS and RFC8667. for MPLS summarization is practically not possible, we have been through that. The point is that the proposed solution is applicable to only a subset of real practical deployments even if e

Re: [Lsr] BGP vs PUA/PULSE

to MTR. The summarization applies to any MT in a same way as to MT-0. literally anything which uses inter-area leaking today. prefixes that are leaked between areas can be summarized. We are not changing any of that. thanks, Peter Thx, R. On Mon, Jan 3, 2022 at 6:18 PM Peter Psenak

Re: [Lsr] BGP vs PUA/PULSE

each disconnected PE? obviously not. That's why I mentioned the number of pulses will be limited on every ABR. thanks, Peter Regards, Greg On Mon, Jan 3, 2022 at 8:56 AM Peter Psenak mailto:40cisco@dmarc.ietf.org>> wrote: Chris, On 03/01/2022 17:18, Christian

Re: [Lsr] BGP vs PUA/PULSE

Chris, On 03/01/2022 20:23, Christian Hopps wrote: Peter Psenak writes: Chris, On 03/01/2022 17:18, Christian Hopps wrote: Peter Psenak writes: On 03/01/2022 16:21, Christian Hopps wrote: On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) wrote: Tony – Let me try one

Re: [Lsr] BGP vs PUA/PULSE

ter Psenak <mailto:ppse...@cisco.com>> wrote: Chris, On 03/01/2022 17:18, Christian Hopps wrote: > > Peter Psenak mailto:ppse...@cisco.com>> writes: > >> On 03/01/2022 16:21, Christian Hopps wrote: >>> >>>&g

Re: [Lsr] BGP vs PUA/PULSE

Chris, On 03/01/2022 17:18, Christian Hopps wrote: Peter Psenak writes: On 03/01/2022 16:21, Christian Hopps wrote: On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) wrote: Tony – Let me try one example – see if it helps. Summarization is used in the network. But customer

Re: [Lsr] BGP vs PUA/PULSE

On 03/01/2022 16:21, Christian Hopps wrote: On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) wrote: Tony – Let me try one example – see if it helps. Summarization is used in the network. But customer identifies a modest number of key nodes where it wants to detect loss of reachab

Re: [Lsr] BGP vs PUA/PULSE

Tony, On 02/12/2021 15:58, Tony Przygienda wrote: On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Tony, On 02/12/2021 11:49, Tony Przygienda wrote: > Idly thinking about the stuff more and more issues pop up that confirm >

Re: [Lsr] BGP vs PUA/PULSE

the receiving router - e.g. BGP, TE, etc,. Peter Thx, R. On Thu, Dec 2, 2021 at 2:03 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Tony, On 02/12/2021 11:49, Tony Przygienda wrote: > Idly thinking about the stuff more and more issues pop up that confirm &

Re: [Lsr] BGP vs PUA/PULSE

*From:* Tony Przygienda mailto:tonysi...@gmail.com>> *Sent:* Wednesday, December 1, 2021 9:33 AM *To:* Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> *Cc:* Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Hannes Gredler mailto:han...@gredler.at>>; lsr ma

Re: [Lsr] BGP vs PUA/PULSE

On 02/12/2021 10:33, Robert Raszuk wrote: Hey Peter, I don't understand what "service stops" you are talking about. Pulse will never stop any service. It will at most trigger the switch to alternate service source. If there is none available, nothing will happen. Oh really ? I

Re: [Lsr] BGP vs PUA/PULSE

; then the L1/L2 on the border of the down L1 pulses and tears the session down albeit the prefix is perfectly reachable through the other L1/L2. I assume that parses for the connoscenti ... -=--- tony On Wed, Dec 1, 2021

Re: [Lsr] BGP vs PUA/PULSE

> Sent: Tuesday, November 30, 2021 11:22 AM > To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>> > Cc: Robert Raszuk mailto:rob...@raszuk.net>>; Les Ginsberg (ginsberg) > mailto:ginsb...@cisco.com>>; Aijun Wang mailto:wangai...@tsinghua.org.c

Re: [Lsr] IPR Poll for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

Hi Acee, I'm not aware of any undisclosed IPR related to this draft. thanks, Peter On 22/11/2021 15:12, Acee Lindem (acee) wrote: Draft Authors and Contributors, Are you aware of any IPR that applies to draft-decraeneginsberg-lsr-isis-fast-flooding-00? If so, has this IPR been disclosed in

Re: [Lsr] BGP vs PUA/PULSE

Hi Robert, On 30/11/2021 12:40, Robert Raszuk wrote: Hey Peter, > #1 - I am not ok with the ephemeral nature of the advertisements. (I > proposed an alternative). LSPs have their age today. One can generate LSP with the lifetime of 1 min. Protocol already allows that. Tha

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 30/11/2021 10:29, Robert Raszuk wrote: Les, */I was just trying to illustrate that prefixes covered by the summary could be advertised using existing IGP advertisements even when the summary is being advertised. /**/It is still reachability. The determination of when

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 29/11/2021 23:53, Robert Raszuk wrote: Hi Les, Just to summarize my personal take on this thread in the light of your last email. #1 - I am not ok with the ephemeral nature of the advertisements. (I proposed an alternative). LSPs have their age today. One can generate LSP with

Re: [Lsr] BGP vs PUA/PULSE

Hi Robert, On 29/11/2021 13:58, Robert Raszuk wrote: Hey Peter, think of it as LSP with the lifetime of 60 sec. Nothing magical about it. That 60 sec is not long enough. If folks do not want to quickly detect the failure by iBGP by running BFD def iBGP holdtime is 180 sec ! So right

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 26/11/2021 19:20, Robert Raszuk wrote: Pulse cleans up itself without any additional flooding, that's the whole idea of it. That's the most scary and not well understood part of it. Ghosts ! Appears and magically disappears. think of it as LSP with the lifetime of 6

Re: [Lsr] BGP vs PUA/PULSE

ger possible as the interface there is p2mp so it can not go down if even one remote PE is still up. Thx, R. On Fri, Nov 26, 2021 at 5:36 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Robert, On 26/11/2021 17:18, Robert Raszuk wrote: > Peter, > > Tec

Re: [Lsr] BGP vs PUA/PULSE

f network wide flooding of those PULSEs. Many thx, R. On Fri, Nov 26, 2021 at 4:38 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Robert, On 26/11/2021 15:06, Robert Raszuk wrote: > Peter, > >     again, if you use option 2

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 26/11/2021 15:06, Robert Raszuk wrote: Peter, again, if you use option 2. There are way too many networks without it. There is even more networks without PUA/PULSE today. Should that be a factor ? the solution should not depend on any particular deployment of the overlay pr

Re: [Lsr] BGP vs PUA/PULSE

ide of BGP. thanks, Peter Thx a lot, Robert On Thu, Nov 25, 2021 at 6:45 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: Robert, On 25/11/2021 18:25, Robert Raszuk wrote: > Dear LSR WG, > > I wanted to visualize the scenario we a

Re: [Lsr] BGP vs PUA/PULSE

Robert, On 25/11/2021 18:25, Robert Raszuk wrote: Dear LSR WG, I wanted to visualize the scenario we are so deeply discussing here. Specifically BGP vs IGP flooding as well as applicability of RFC8679. Below are three options comparing what it takes to distribute bad news in BGP vs IGP. Kee

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Shraddha, On 24/11/2021 06:19, Shraddha Hegde wrote: WG, MPLS egress protection framework RFC 8679 provides a mechanism to locally protect the traffic during PE failures. The concepts can be applied to SRv6 as well. This mechanism is much more efficient and quick because it locally provides

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

ployed by operators. SRv6 is an answer but majority of all SPs are not there yet and we need to be able support MPLS for a long time to come beyond our lifetime. Kind Regards Gyan On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak wrote: Robert, On 22/11/2021 15:26, Robert Raszuk wrote:

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

eed to be able support MPLS for a long time to come beyond our lifetime. Kind Regards Gyan On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak mailto:ppse...@cisco.com>> wrote: Robert, On 22/11/2021 15:26, Robert Raszuk wrote: > > Peter -

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

where. Cheers, R. On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote: On 22/11/2021 15:00, Robert Raszuk wrote: > >     it's not a choice, that is an MPLS architectural requirement and it >     happens in every single SP

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

On 22/11/2021 15:00, Robert Raszuk wrote: it's not a choice, that is an MPLS architectural requirement and it happens in every single SP network that offers services on top of MPLS. If that is considered architecturally incorrect, then the whole MPLS would be. But regardless of t

Re: [Lsr] Signaling next hop liveness

On 22/11/2021 14:47, Robert Raszuk wrote: time to look at SRv6, it does net require end-to-end LSP with host reachability - e.g. summarization is possible. And how do I know if remote PE is even SRv6 capable and for what behaviours ? How do I know its functions ? How about using EPE

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

On 22/11/2021 08:45, Les Ginsberg (ginsberg) wrote: Tony – I have been trying to gain a better understanding of your thinking – thanx for your responses which have helped in that regard. I am not trying to convince you of anything – just want to add a few comments: It is not clear to me wh

Re: [Lsr] Signaling next hop liveness

Robert, On 20/11/2021 20:14, Robert Raszuk wrote: All, With all the discussions about how to accomplish this I have one fundamental doubt. Let's take SR and ISIS or OSPF extensions for it (say RFC8667). It seems that none of it works network wide if we instead of prefix reachability start

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Tony, On 19/11/2021 17:55, Tony Li wrote: Hi Peter, yes, but it's not specific to flat areas. Even in multi-area deployments the host routing is mandated by MPLS. In these multi-area deployments the host routes are sent everywhere, updates are triggered regardless of the failure type. IG

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Hi Tony, On 19/11/2021 17:02, Tony Li wrote: Hi Peter, [WAJ] The problem is arose from the summary action of IGP, why let other protocols solve it? There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. That’s not a property that it was meant to provide. today IGPs pro

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Tony, On 19/11/2021 04:16, Aijun Wang wrote: Hi, Tony: -Original Message- From: tony1ath...@gmail.com On Behalf Of Tony Li Sent: Friday, November 19, 2021 9:08 AM To: Aijun Wang Cc: Tony Przygienda ; Les Ginsberg (ginsberg) ; Gyan Mishra ; lsr@ietf.org; Christian Hopps ; Acee Lindem

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Tony, On 18/11/2021 17:38, Tony Li wrote: Les, You are not retaining scalability. You are damaging it. You are proposing flooding a prefix per router that fails. If there is a mass failure, that would result in flooding a large number of prefixes. The last thing you want when there is a mass

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Suppressing them randomly may lead to even bigger disappointment of unreachability propagation hence delaying connectivity restoration to a backup path. Many thx, R. On Thu, Nov 18, 2021 at 1:58 PM Peter Psenak mailto:ppse...@cisco.com>> wrote: Robert,

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Robert, On 18/11/2021 13:42, Robert Raszuk wrote: [WAJ] In the scenarios that you mentioned, BGP nexthop reachability is derived from the directed interface, there is no summary action done by the router. Is that true? Not necessarily - TORs do not always do eBGP to compute and set

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

Robert, On 18/11/2021 11:33, Robert Raszuk wrote: Les, All, One thing to keep in mind in this entire discussion is the reality of compute nodes becoming L3 routing nodes in many new architectures. The protocol which is used between TORs and such compute nodes is almost always BGP. That means

Re: [Lsr] Oscillation caused by the "site-cost" associated with a Prefix (ANYCAST) in draft-dunbar-lsr-5g-edge-compute

Linda, On 11/11/2021 15:33, Linda Dunbar wrote: Since we didn’t have enough time at today’s LSR session, I want to continue the discussion of draft-dunbar-lsr-5g-edge-compute on the mailing list: * Shraddha pointed out that advertising the “site aggregated cost” of a Prefix (ANYCAST) mi

Re: [Lsr] Question about how topology is calculated ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

hanks, Peter Thank you, Linda -Original Message- From: Peter Psenak Sent: Friday, November 5, 2021 10:49 AM To: Linda Dunbar ; lsr@ietf.org Subject: Re: Question about how topology is calculated ( was RE: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge comp

Re: [Lsr] Question about how topology is calculated ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

u, Linda -Original Message- From: Peter Psenak Sent: Friday, November 5, 2021 4:43 AM To: Linda Dunbar ; lsr@ietf.org Subject: Re: Question about how topology is calculated ( was RE: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics Linda,

Re: [Lsr] Question about how topology is calculated ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

you, Linda -Original Message----- From: Peter Psenak Sent: Thursday, November 4, 2021 1:16 PM To: Linda Dunbar ; lsr@ietf.org Subject: Re: Question about the FAD Flags Sub-TLV ( was RE: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics Linda,

Re: [Lsr] Question about the FAD Flags Sub-TLV ( was RE: Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

cs is not present.  When AppMeteData metrics is not present, the prefix is considered normal that doesn't need special constraint SPF computation. * Calc-Type-v5: no transit across areas/domains * Calc-Type-v6: transit across areas/domains. Thank you, Linda -Original Message-

Re: [Lsr] Looking for feedback of using Flex Algo to advertise the 5G edge computing associated metrics

Hi Linda, I went through your document and here are my comments: 1. the section 1, 2, and 3 can probably be summarized in a single paragraph stating the problem you are trying to solve. The 5G details are redundant, you may just want to add reference to the parent document. 2. FAD is used to

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-flex-algo-18

Henning, On 02/11/2021 14:57, Henning Rogge wrote: On Tue, Nov 2, 2021 at 12:07 PM Peter Psenak wrote: Hi Henning, In chapter 6.1-6.3 (7.1-7.3 for OSPF) you define a subset of "boolean algebra" among the extended admin groups. I assume that more complex boolean conditions are not

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-flex-algo-18

Hi Henning, thanks for your review, please see some responses inline (##PP): On 01/11/2021 11:18, Henning Rogge via Datatracker wrote: Reviewer: Henning Rogge Review result: Ready Hi, I have been asked to do a review of draft-ietf-lsr-flex-algo (currently in draft 18). First I have to say i

Re: [Lsr] [LSR] draft-ietf-lsr-flex-algo

Hi Abhinay, On 20/10/2021 10:45, Abhinay R wrote: Hi All,         I see a typo in the flex algo draft [https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/]. 7.3.  OSPF Flexible Algorithm Include-All Admin Group Sub-TLV    The usage of this Sub-TLVs is described in Section 6.3.    

Re: [Lsr] Francesca Palombini's Discuss on draft-ietf-lsr-isis-srv6-extensions-17: (with DISCUSS)

Hi Francesca, I have uploaded the new version of the draft that addresses all your comments. thanks, Peter On 19/10/2021 15:54, Francesca Palombini wrote: Hi Peter! Thanks for the quick reaction. Inline. Francesca *From: *Peter Psenak *Date: *Tuesday, 19 October 2021 at 15:19 *To

Re: [Lsr] Francesca Palombini's Discuss on draft-ietf-lsr-isis-srv6-extensions-17: (with DISCUSS)

Hi Francesca, thanks for your review, please see my responses inline (##PP): On 18/10/2021 23:57, Francesca Palombini via Datatracker wrote: Francesca Palombini has entered the following ballot position for draft-ietf-lsr-isis-srv6-extensions-17: Discuss When responding, please keep the subje

Re: [Lsr] 【Technical Discussion】"Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

y, October 15, 2021 3:16 PM *To:* 'Les Ginsberg (ginsberg)' ; 'Acee Lindem (acee)' ; 'Peter Psenak' ; lsr@ietf.org *Subject:* Re: [Lsr] 【Technical Discussion】"Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

PUA is not an alternative that I can support. Les > -Original Message- > From: Lsr On Behalf Of Acee Lindem (acee) > Sent: Wednesday, October 13, 2021 9:49 AM > To: Peter Psenak ; lsr@ietf.org > Subject: Re:

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

l Message- > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee Lindem (acee) > Sent: Wednesday, October 13, 2021 9:49 AM > To: Peter Psenak mailto:40cisco@dmarc.ietf.org>>; lsr@ietf.org <mailto:lsr@ietf.org> > Subject: Re: [Lsr] &

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Tony, On 14/10/2021 07:50, Tony Li wrote: Les, If you’re advertising loopbacks that are outside of the summarized space, then you end up with reachability and liveness.  Yes, there’s a cost in scalability… it ain’t free. the whole point is to summarize loopbacks of PE devices, so above wou

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

dem (acee) mailto:40cisco@dmarc.ietf.org>> wrote: Hi Peter, See inline. On 10/13/21, 4:42 AM, "Peter Psenak" mailto:40cisco@dmarc.ietf.org>> wrote:     Hi Acee,     On 12/10/2021 21:05, Acee Lindem (acee) wrote:  

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Greg, On 13/10/2021 15:36, Greg Mirsky wrote: Hi Aijun, thank you for your quick response. Please find my further notes in-line below tagged GIM>>. Regards, Greg On Tue, Oct 12, 2021 at 9:06 PM Aijun Wang > wrote: Hi, Greg: __ __ The defe

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

proposal is more generic and at the WG adoption call (if ever happens) you have my vote ;). good :) thanks, Peter Cheers, R. On Wed, Oct 13, 2021 at 10:42 AM Peter Psenak mailto:40cisco@dmarc.ietf.org>> wrote: Hi Acee, On 12/10/2021 21:05, Acee Lindem (acee) wrote: &

Re: [Lsr] "Prefix Unreachable Announcement" and "IS-IS and OSPF Extension for Event Notification"

Hi Acee, On 12/10/2021 21:05, Acee Lindem (acee) wrote: Speaking as WG Chairs: The authors of “Prefix Unreachable Announcement” have requested an adoption. The crux of the draft is to signal unreachability of a prefix across OSPF or IS-IS areas when area summarization is employed and prefix

Re: [Lsr] draft-ietf-lsr-flex-algo

Robert, Acee, On 16/09/2021 22:16, Acee Lindem (acee) wrote: Hi Robert, *From: *Robert Raszuk *Date: *Thursday, September 16, 2021 at 5:34 AM *To: *Peter Psenak *Cc: *Linda Dunbar , Tony Li , "lsr@ietf.org" , Bruno Decraene , Acee Lindem , "Acee Lindem (acee)" *Subje

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Linda, On 15/09/2021 21:45, Linda Dunbar wrote: Tony, Answers are inserted below: *From:* Tony Li *On Behalf Of *Tony Li *Sent:* Wednesday, September 15, 2021 1:26 PM *To:* Peter Psenak *Cc:* Acee Lindem (acee) ; Acee Lindem (acee) ; Linda Dunbar ; bruno.decra...@orange.com; lsr

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Acee, On 15/09/2021 20:09, Acee Lindem (acee) wrote: Hi Peter, I had too long of a context switch on flex algo See inline. On 9/12/21, 2:15 PM, "Lsr on behalf of Peter Psenak" wrote: Hi Acee, On 11/09/2021 16:59, Acee Lindem (acee) wrote: > Hi Peter,

Re: [Lsr] Proposed changes for OSPFv3 SRv6 encoding

Hi Ketan, On 14/09/2021 11:24, Ketan Talaulikar (ketant) wrote: Hi Dirk, Your point is related to my original concern/interpretation for why we introduced a new LSA type for SRv6 Locator than use the existing Extended Prefix LSA types. This goes back to the original intention of the WG and a

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Acee, On 11/09/2021 16:59, Acee Lindem (acee) wrote: Hi Peter, On 9/10/21, 1:46 AM, "Lsr on behalf of Peter Psenak" wrote: Linda, On 09/09/2021 22:17, Linda Dunbar wrote: > Peter and Tony, > > Thank you very much for the explanation. >

Re: [Lsr] draft-ietf-lsr-flex-algo

which indicates how metric is used. Metric-Type indicates which metric is used. thanks, Peter Linda -Original Message----- From: Peter Psenak Sent: Thursday, September 9, 2021 1:00 PM To: Tony Li ; Linda Dunbar Cc: bruno.decra...@orange.com; lsr@ietf.org Subject: Re: [Lsr] draft-iet

Re: [Lsr] draft-ietf-lsr-flex-algo

27 (currently shown unassigned on IANA page)? Linda Dunbar -Original Message- From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Peter Psenak Sent: Thursday, September 9, 2021 7:52 AM To:bruno.decra...@orange.com <mailto:bruno.decra...@orange.com>;lsr@ietf.org <mailt

Re: [Lsr] draft-ietf-lsr-flex-algo

Hi Bruno, On 09/09/2021 15:27, bruno.decra...@orange.com wrote: Hi Peter, Thanks for your answer. Please see inline -Original Message- From: Peter Psenak [mailto:ppse...@cisco.com] Sent: Thursday, September 9, 2021 2:52 PM To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org Subject: Re: [Lsr

<    1   2   3   4   5   6   7   8   >