Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Les, if we assume that this is a real case, it appears to me that it is a rear one. Thus, I don't see a good enough reason standardizing something that solves a rear case when there's already a standard-based solution that addresses 80%, if not 90% of cases. Yes, it is interesting problem but, in

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Greg – With 100K PE scale, we are talking about 100K BFD sessions/PE and close to 5 million BFD sessions network-wide. Eliminating one of the options we are discussing is admittedly a small step, but still worthwhile. However, If you still want to continue to advocate for BFD, I will say no

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi all, I suggest that we all agree to disagree. Since we cannot make progress, we simply drop all proposals, adopt none of them, and give up. Tony > On Jan 25, 2022, at 6:16 PM, Aijun Wang wrote: > > Hi, All: > > As Peter’s example and Acee’s suggestions, let’s focus on the following

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi, Greg: Yes. I think so. If we select the “OOB solution“ category, RFC 5883 is one existing option, and has no new connection states introduced within the network devices. The reason that we prefer to the IGP solution is that we want just to relieve from the configuration/operational

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi Aijun, I believe that under Option D you can add multihop BFD per RFC 5883. No new protols needed. Regards, Greg On Tue, Jan 25, 2022, 18:17 Aijun Wang wrote: > Hi, All: > > > > As Peter’s example and Acee’s suggestions, let’s focus on the following > problem to think how to solve it

[Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi, All: As Peter's example and Acee's suggestions, let's focus on the following problem to think how to solve it efficiently and reasonably: Scenario: 100 areas each with 1000 PEs (100K total PEs) with 2 ABRs per area Problem: Overlay services(BGP or Tunnel) that rely on the IGP needs to be

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: From: Robert Raszuk Sent: Wednesday, January 26, 2022 7:58 AM To: Aijun Wang Cc: lsr ; Tony Li Subject: Re: [Lsr] BGP vs PUA/PULSE I think we have to accept that we have very different understanding on what out-of-band means. But let's not get hang on this here.

Re: [Lsr] BGP vs PUA/PULSE

I think we have to accept that we have very different understanding on what out-of-band means. But let's not get hang on this here. Because to do it efficiently and in scalable manner close cooperation with LSDB is required. Management system is completely orthogonal to that. IMO Tony's proposal

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: Then why not let all of these out of band messages delivered via the management system? Aijun Wang China Telecom > On Jan 25, 2022, at 23:28, Robert Raszuk wrote: > >  > > Auto discovery is described in the draft. > > You may also provision this session by your management

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

Robert Raszuk writes: Peter, If a given PE needs to get all notifications from all other PEs it is sufficient that it sends to local ABRs a single registration in a form of 0.0.0.0/0 and be done.  But realistically speaking the case where services offered by a PE also exist on all 100K

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

Hi Tony, If a given PE needs to get all notifications from all other PEs it is > sufficient that it sends to local ABRs a single registration in a form of > 0.0.0.0/0 and be done. > > > If you look a bit more carefully, you will find that registering for 0/0 > doesn’t work without a bit more

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

Robert, > If a given PE needs to get all notifications from all other PEs it is > sufficient that it sends to local ABRs a single registration in a form of > 0.0.0.0/0 and be done. If you look a bit more carefully, you will find that registering for 0/0 doesn’t work

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

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

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

Peter, If a given PE needs to get all notifications from all other PEs it is sufficient that it sends to local ABRs a single registration in a form of 0.0.0.0/0 and be done. But realistically speaking the case where services offered by a PE also exist on all 100K other PEs would be pretty rare.

Re: [Lsr] BGP vs PUA/PULSE

Speaking as WG Chair and one who rarely wears a hat: I agree with Chris. There are multiple solutions being proposed and, as one would expect, the authors of each solution like their own. Can we agree on the requirement is the topology Peter used as an example with 100 areas each with 1000

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

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 RECOMMENDED that the ABR register for the most specific prefix that is less specific than the original prefix. I don't think so. I'm talking about PE to ABR

Re: [Lsr] BGP vs PUA/PULSE

Auto discovery is described in the draft. You may also provision this session by your management plane just like you push 1000s of configuration lines anyway to each network element. Those are commonly used techniques to run a network. On Tue, Jan 25, 2022 at 4:07 PM Aijun Wang wrote: > Or, I

Re: [Lsr] BGP vs PUA/PULSE

Or, I guess you still need the ABR to act as the server. But, how these RRs know which router is ABR? Aijun Wang China Telecom > On Jan 25, 2022, at 23:01, Aijun Wang wrote: > > Hi, Robert: > > You mean make every PE as the register server? > > Aijun Wang > China Telecom > >>> On Jan 25,

Re: [Lsr] BGP vs PUA/PULSE

No. Run this node liveness service on ABR or on any other IGP node in an area. On Tue, Jan 25, 2022 at 4:01 PM Aijun Wang wrote: > Hi, Robert: > > You mean make every PE as the register server? > > Aijun Wang > China Telecom > > On Jan 25, 2022, at 21:21, Robert Raszuk wrote: > >  > Aijun, >

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: You mean make every PE as the register server? Aijun Wang China Telecom > On Jan 25, 2022, at 21:21, Robert Raszuk wrote: > >  > Aijun, > >> No, I think you misunderstanding our purpose. > > You are using this argument towards a number of people ... I recommend you >

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

Peter, You clearly missed the added new sentence to section 4.3 in version -01 It is RECOMMENDED that the ABR register for the most specific prefix that is less specific than the original prefix. Thx, R On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak wrote: > On 25/01/2022 14:07, Robert

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

On 25/01/2022 14:07, Robert Raszuk wrote: Peter, Your math is off. no, it's right. Every local PE in an area registers to different 100 remote addresses to local ABRs. 1k PEs in area * 100 destinations equals to 100k registrations. Peter > 1. 100k registrations in each ABR, 10

Re: [Lsr] BGP vs PUA/PULSE

Aijun, No, I think you misunderstanding our purpose. > You are using this argument towards a number of people ... I recommend you reconsider. > The proposed solution can fit in small network, or large network and RR > can locate anywhere the operator want to place. We have no assumption about

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: No, I think you misunderstanding our purpose. The proposed solution can fit in small network, or large network and RR can locate anywhere the operator want to place. We have no assumption about the location of RR and PEs. Aijun Wang China Telecom > On Jan 25, 2022, at 21:03, Robert

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

Peter, Your math is off. > 1. 100k registrations in each 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 wrote: > Tony, > > I'm going to use my

Re: [Lsr] BGP vs PUA/PULSE

Aijun, The solution can’t rely only on the limited assumption. > And the protocol extensions can not be justified based on the limited corner cases of broken network designs. And, actually, the PE are Provider Edge Router, we always locate them at > the non-backbone area in large network ,

Re: [Lsr] BGP vs PUA/PULSE

Peter Psenak writes: 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*

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: The deployment of IGP and BGP is decoupled. The solution can’t rely only on the limited assumption. And, actually, the PE are Provider Edge Router, we always locate them at the non-backbone area in large network , that is close to the customer. There maybe some small network that

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 prefix P,

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

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: How about when the RR locates in one area(for example, backbone area), but the PEs locates in the attached non-backbone area? In such scenario, the RR can only receive the summary prefixes of PEs. Aijun Wang China Telecom > On Jan 25, 2022, at 17:59, Robert Raszuk wrote: > >  >

Re: [Lsr] BGP vs PUA/PULSE

Chair Hat: [This is not directed specifically at Aijun, I'm just replying to the thread at this point.] I think we all need to try and bring the tone down a bit, I realize this discussion/debate has really dragged on and so nerves are getting frazzled, but let's try, anyway. I do think that

Re: [Lsr] BGP vs PUA/PULSE

Aijun, [WAJ] X aims to how to withdraw the VPN prefixes with the mentioned > extended communities, right? > Extended communities have nothing to do with this discussion at all. > Y aims to how assist the RR get the prefix cost from one node that other > than the RR itself. Right? > No. > I

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: Aijun Wang China Telecom > On Jan 25, 2022, at 17:36, Robert Raszuk wrote: > >  > Aijun, > >> On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang >> wrote: >> Hi, Robert: >> >> >> >> So the main point here is that yes it is highly recommended to use summaries >> across areas. But

Re: [Lsr] BGP vs PUA/PULSE

Aijun, On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang wrote: > Hi, Robert: > > > > So the main point here is that yes it is highly recommended to use > summaries across areas. But what's not clear (at least to me) is if we > really need to signal node liveness in IGP to accomplish the ultimate

Re: [Lsr] BGP vs PUA/PULSE

Hi, Robert: So the main point here is that yes it is highly recommended to use summaries across areas. But what's not clear (at least to me) is if we really need to signal node liveness in IGP to accomplish the ultimate goal of few sec connectivity restoration upon PE failure in the cases

Re: [Lsr] BGP vs PUA/PULSE

> > As we’ve been saying for months now, the ordering is: > > 1) Leak PE loopbacks > 2) Pub/Sub > 3) Carry loopbacks in BGP and recurse > 4) Multi-hop BFD > 5) Pulse > 6) PUA I would like to actually add to this list two alternatives which some vendors have been shipping for decades: X)

Re: [Lsr] BGP vs PUA/PULSE

Hi, Tony: I am curious why you are so anxious to claim other solution, or make the baseless ranking? Please do not misled the reader any more. It's not helpful for the others to find the truth. When the receivers receives the PUA information, the SPF algorithm will not be triggered, then where