Subject: Re: [Lsr] BGP vs PUA/PULSE

From: Christian Hopps <[email-masked]>
Date: Mon, 3 Jan 2022 10:21:57 -0500

> On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> 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 reachability ASAP. Unfortunately, customer is unable to assign addresses which are outside of the summary to these nodes.

I think this does in fact capture the problem trying to be solved here, nicely.

One solution very simple solution that works today is:

- Tell the customer they can't do this, but they *can* modify their addressing (this is literally what they do for a living) so that they don't have this problem.

Do we *really* want modify our IGPs (a BIG ask) with some pretty questionable changes, just to save the operators the trouble of doing their job correctly?

Maybe the answer here is this isn't a good idea, and we should move on...

Thanks,
Chris.
[as wg member]

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Jan 2022 16:33:23 +0100

> I think this does in fact capture the problem trying to be solved here, nicely.

not really.
In fact assigning addresses to the nodes in a way that they are part of 
the summary is the right thing to do.

The problem we are trying to solve is to use the summarization but 
without the loss of the fast notification of the node down event.

thanks,
Peter

> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: Christian Hopps <[email-masked]>
Date: Mon, 03 Jan 2022 11:18:37 -0500

Peter Psenak <[email-masked]> writes:

> In fact assigning addresses to the nodes in a way that they are part of the
> summary is the right thing to do.

No, not if you want more detailed information about specific reachability it's not. And ....

> The problem we are trying to solve is to use the summarization but without the
> loss of the fast notification of the node down event.

You want more specific information about reachability, but you just want to do it when the network is stressed and undergoing change.

So the "works now" way of not summarizing these important prefixes has the state in the network when it's working, so you know adding and removing it is something the network is already capable of handling.

New signaling that *only* is created when things start failing, tests the infrastructure at exactly the wrong time.

If a failing network can handle the extra state, then a functioning stable network of course can too.

Thanks,
Chris.

>> - Tell the customer they can't do this, but they *can* modify their addressing
>> (this is literally what they do for a living) so that they don't have this
>> problem.
>> Do we *really* want modify our IGPs (a BIG ask) with some pretty questionable
>> changes, just to save the operators the trouble of doing their job correctly?

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Jan 2022 17:56:16 +0100

Chris,

> No, not if you want more detailed information about specific reachability it's not. And ....

typically you want to summarize all prefixes inside the area when 
advertising outside the area. And you want to know about some of these 
prefixes when they are lost to help convergence.

> New signaling that *only* is created when things start failing, tests the infrastructure at exactly the wrong time.

In 99,99% of cases there will be only single pulse generated when one PE 
goes down. That itself is a very rare event itself.

We can easily limit the number of pulses generated on ABR to a single 
digit number to cover the unlikely case of many PEs in area becoming 
unreachable at the same time.

> If a failing network can handle the extra state, then a functioning stable network of course can too.

no, that's not what we claim. We want network to be summarized all times 
and generate limited number of pulses at any given time to help the 
network converge fast in case where single (or very few) PEs in an area 
go down.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 3 Jan 2022 18:04:34 +0100

Peter,

> We want network to be summarized all times

Please - can you answer my question which was already stated at least twice
?

How can you summarize PE addresses if outside of reachability they
advertise and leak across areas lots of other important information in an
opaque to the IGP meaning ?

What other transport those opaque gen-art /gen-app  information will take
once you summarize the reachability and stop inter-area leaking ?

Many thx,
R.

On Mon, Jan 3, 2022 at 5:56 PM Peter Psenak <[email-masked]> wrote:

> >>>> But customer identifies a modest number of key nodes where it wants
> to detect loss of reachability ASAP. Unfortunately, customer is unable to
> assign addresses which are outside of the summary to these nodes.
> >>>
> without the
> > You want more specific information about reachability, but you just want
> to do it when the network is stressed and undergoing change.
> >
> > So the "works now" way of not summarizing these important prefixes has
> the state in the network when it's working, so you know adding and removing
> it is something the network is already capable of handling.
> >
> > New signaling that *only* is created when things start failing, tests
> the infrastructure at exactly the wrong time.
>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 3 Jan 2022 18:18:01 +0100

Robert,

On 03/01/2022 18:04, Robert Raszuk wrote:
> Please - can you answer my question which was already stated at least 
> twice ?
> 
> advertise and leak across areas lots of other important information in 
> an opaque to the IGP meaning ?

like what?

thanks,
Peter

> 
> What other transport those opaque gen-art /gen-app  information will 
> take once you summarize the reachability and stop inter-area leaking ?
> 
> Many thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Jan 3, 2022 at 5:56 PM Peter Psenak <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Chris,
> 
>      > Peter Psenak <[email-masked] <mailto:[email-masked]>> writes:
>      >
>      >>>> On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg)
>     <ginsberg=[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >>>>
>      >>>> Tony –
>      >>>> But customer identifies a modest number of key nodes where it
>     wants to detect loss of reachability ASAP. Unfortunately, customer
>     is unable to assign addresses which are outside of the summary to
>     these nodes.
>      >>>
>      > You want more specific information about reachability, but you
>     just want to do it when the network is stressed and undergoing change.
>      >
>      > So the "works now" way of not summarizing these important
>     prefixes has the state in the network when it's working, so you know
>     adding and removing it is something the network is already capable
>     of handling.
>      >
>      > New signaling that *only* is created when things start failing,
>     tests the infrastructure at exactly the wrong time.
> 
>      > If a failing network can handle the extra state, then a
>     functioning stable network of course can too.
> 
>      >>> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/lsr>
>      >>>
>      >
>      >
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 3 Jan 2022 19:33:58 +0100

Hi Peter,

Take SR-MPLS and RFC8667.

Take RFC7810

Take RFC5120

literally anything which uses inter-area leaking today.

Thx,
R.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 03 Jan 2022 14:23:11 -0500

Peter Psenak <[email-masked]> writes:

> typically you want to summarize all prefixes inside the area when advertising
> outside the area. And you want to know about some of these prefixes when they
> are lost to help convergence.
>
>> You want more specific information about reachability, but you just want to do
>> it when the network is stressed and undergoing change.
>> So the "works now" way of not summarizing these important prefixes has the
>> state in the network when it's working, so you know adding and removing it is
>> something the network is already capable of handling.
>> New signaling that *only* is created when things start failing, tests the
>> infrastructure at exactly the wrong time.
>
> In 99,99% of cases there will be only single pulse generated when one PE goes
> down. That itself is a very rare event itself.

You can say the same thing about all the regular state already carried in the IGP.

> We can easily limit the number of pulses generated on ABR to a single digit
> number to cover the unlikely case of many PEs in area becoming unreachable at
> the same time.
>
> no, that's not what we claim. We want network to be summarized all times and
> generate limited number of pulses at any given time to help the network converge
> fast in case where single (or very few) PEs in an area go down.

And I'm saying if a prefix is important enough to merit a bunch of new protocol extensions and state, then it's important enough to simply be left out of the summarization in the first place.

And then people get what they want, w/o protocol changes/upgrades, and it's using time tested and hardened IGP code and designs.

Why doesn't this work?

Thanks,
Chris.

---

From: Tony Li <[email-masked]>
Date: Mon, 3 Jan 2022 13:08:57 -0800

> On Jan 3, 2022, at 11:23 AM, Christian Hopps <[email-masked]> wrote:
> 

+1

T

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 3 Jan 2022 14:17:25 -0800

Happy New Year to All!

Hi Peter,
Top-pasting:

I think that it is possible for the summarizing ABR to get disconnected
from the IGP area in such a way that the summarization is still valid. If
such a case is valid, would the ABR generate PULSE for each disconnected PE?

Regards,
Greg

---

From: Aijun Wang <[email-masked]>
Date: Tue, 4 Jan 2022 12:26:37 +0800

Hi, Christian and Tony:

Following your idea, the network will be filled with the large amounts of loop back addresses, will be one inextensible solution which has been discussed previously. 
And, once such loopack address failures, the nodes in other areas will also be notified. 
That is to say, such solution is not optimized both in normal situations and failures situations.

Aijun Wang
China Telecom

> On Jan 4, 2022, at 05:09, Tony Li <[email-masked]> wrote:
> 
> 
>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 4 Jan 2022 01:31:01 -0500

> On Jan 3, 2022, at 11:26 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Christian and Tony:
> 

I stand by what I said: "... if a prefix is important enough to merit a bunch of new protocol extensions and state, then it's important enough to simply be left out of the summarization in the first place."

> And, once such loopack address failures, the nodes in other areas will also be notified. 

No different than what is being proposed.

> That is to say, such solution is not optimized both in normal situations and failures situations.

It is optimized. It is optimized for optimal delivery to that prefix. No unseemly protocol changes required.

So yet again, either the prefix is important (it is reasonable for it to take up signaling/state) or it isnt (don't special case it). Nothing I've read in the hundreds of emails has convinced me otherwise.

Thanks,
Chris.
[as wg member]

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 4 Jan 2022 16:09:15 +0800

Hi, Christian:

In our concerned scenarios, it is not one or small part of the prefixes that is important. 
Instead, the loopback addresses of all PEs(for overlay BGP/BGP VPN services), or all Ps(for SRv6 tunnel service) are all important. 
Extract them out of the summary addresses and advertise them into IGP directly is not the optimize solution-----This will certainly increase the IGP's pressure in normal situation, and weaken the WG' efforts to introduce several solutions for the flood reduction effects.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Tuesday, January 4, 2022 2:31 PM
To: Aijun Wang <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Tony Li <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>; Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; lsr <[email-masked]>; Peter Psenak <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Thanks,
Chris.
[as wg member]

---

From: Peter Psenak <[email-masked]>
Date: Tue, 4 Jan 2022 10:51:47 +0100

Chris,

> You can say the same thing about all the regular state already carried in the IGP.

not really. Node failures happens significanly less often than link 
flaps. That's the fact that any ISP can confirm.

> And then people get what they want, w/o protocol changes/upgrades, and it's using time tested and hardened IGP code and designs.

let's imagine you have 100k inter-area prefixes in the network - 1k 
prefixes per area, 100 areas, 2 ABRs per area. With summarization you 
compress to 1 summary per area. You will have 100 summary prefixes 
advertised, each by two ABRs, so 200 summary prefixes.

If one PE fails you will have  200 summaries + 2 pulses (2 ABRs per area).

If one PE fails in every area at the same time you will have 200 
summaries + 200 pulses.

If we limit the number of pulses per ABR to 10, regardless of how many 
PE fail at the same time, you will end up with 200 summaries and 2k pulses.

Without summarization you will have 200k states.

In the unrealistic worst case you will have 200 summaries and 2k pulses.

2,2k is in the order of the magnitude less then 200k. And we solved the 
problem of PE down for any realistic case.

Peter

---

From: Peter Psenak <[email-masked]>
Date: Tue, 4 Jan 2022 10:52:26 +0100

Hi Greg,

On 03/01/2022 23:17, Greg Mirsky wrote:
> from the IGP area in such a way that the summarization is still valid. 
> If such a case is valid, would the ABR generate PULSE for 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 
> <ppsenak=[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Chris,
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 4 Jan 2022 10:58:23 +0100

Hi Robert,

> Take SR-MPLS and RFC8667.

for MPLS summarization is practically not possible, we have been through 
that.

> Take RFC7810

TE metric is only advertised for links, not for prefixes.

> Take RFC5120

I do not see any relevance 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 <[email-masked] 
>      >  > We want network to be summarized all times
>      >
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     Chris,
>      >
>      >      >
>      >      > Peter Psenak <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> writes:
>      >      >
>      >      >> On 03/01/2022 16:21, Christian Hopps wrote:
>      >      >>>
>      >      >>>> On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg)
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> 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
>      >      >>>
>      >      >>> I think this does in fact capture the problem trying to be
>      >     solved here, nicely.
>      >      >>
>      >      >> not really.
>      >      >> In fact assigning addresses to the nodes in a way that
>     they are
>      >     part of the
>      >      >> summary is the right thing to do.
>      >      >
>      >      > No, not if you want more detailed information about specific
>      >     reachability it's not. And ....
>      >
>      >
>      >      >
>      >      >> The problem we are trying to solve is to use the
>     summarization
>      >     but without the
>      >      >> loss of the fast notification of the node down event.
>      >      >
>      >      > You want more specific information about reachability, but you
>      >      >
>      >      > So the "works now" way of not summarizing these important
>      >      >
>      >      > New signaling that *only* is created when things start
>     failing,
>      >      >
>      >      > If a failing network can handle the extra state, then a
>      >     no, that's not what we claim. We want network to be
>     summarized all
>      >     times
>      >      >
>      >      > Thanks,
>      >      > Chris.
>      >      >
>      >      >>
>      >      >> thanks,
>      >      >> Peter
>      >      >>
>      >      >>
>      >      >>> One solution very simple solution that works today is:
>      >      >>> - Tell the customer they can't do this, but they *can*
>     modify
>      >     their addressing
>      >      >>> (this is literally what they do for a living) so that they
>      >     don't have this
>      >      >>> problem.
>      >      >>> Do we *really* want modify our IGPs (a BIG ask) with some
>      >     pretty questionable
>      >      >>> changes, just to save the operators the trouble of doing
>     their
>      >     job correctly?
>      >      >>> Maybe the answer here is this isn't a good idea, and we
>     should
>      >     move on...
>      >      >>> Thanks,
>      >      >>> Chris.
>      >      >>> [as wg member]
>      >      >>> _______________________________________________
>      >      >>> Lsr mailing list
>      >      >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      >>> https://www.ietf.org/mailman/listinfo/lsr
>      >     <https://www.ietf.org/mailman/listinfo/lsr
>     <https://www.ietf.org/mailman/listinfo/lsr>>
>      >      >>>
>      >      >
>      >      >
>      >
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Jan 2022 11:42:12 +0100

Peter,

> for MPLS summarization is practically not possible, we have been through

The point is that the proposed solution is applicable to only a subset of
real practical deployments even if everyone would agree that this is a cool
idea.

> TE metric is only advertised for links, not for prefixes.

So it is ok to leak 1000s of link information and it is not ok to leak 100s
of PE loopbacks ?

Best,
R.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 4 Jan 2022 11:50:57 +0100

Robert,

On 04/01/2022 11:42, Robert Raszuk wrote:
> The point is that the proposed solution is applicable to only a subset 
> of real practical deployments even if everyone would agree that this is 
> a cool idea.

sure, it's applicable in cases where summarization is used.

> So it is ok to leak 1000s of link information and it is not ok to leak 
> 100s of PE loopbacks ?

link information are never leaked.

thanks,
Peter

---

From: Christian Hopps <[email-masked]>
Date: Tue, 04 Jan 2022 09:10:31 -0500

"Aijun Wang" <[email-masked]> writes:

> Extract them out of the summary addresses and advertise them into IGP directly
> is not the optimize solution-----This will certainly increase the IGP's pressure
> in normal situation, and weaken the WG' efforts to introduce several solutions
> for the flood reduction effects.

I don't see how this addresses my point.

Having extra prefixes advertised is not in and of itself a bad thing, even if there are a good number of them. You gain a lot by advertising these prefixes that you've identified as "Very Important", so unless the protocol literally can't handle it, it just seems like Good Design (KISS) to me.

Thanks,
Chris.
[as wg member]

> Cc: Christian Hopps <[email-masked]>; Tony Li <[email-masked]>; Robert
> Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>; Hannes
> Gredler <[email-masked]>; Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]>; lsr <[email-masked]>; Peter Psenak
> <[email-masked]>
> I stand by what I said: "... if a prefix is important enough to merit a bunch of
>> new protocol extensions and state, then it's important enough to simply be
>> left out of the summarization in the first place."
>
>>>> And I'm saying if a prefix is important enough to merit a bunch of new
>>>> protocol extensions and state, then it's important enough to simply be left
>>>> out of the summarization in the first place.
>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Jan 2022 09:13:43 -0800

Hi Peter,
I'm probably missing something in the current PULSE but I cannot find the
mechanism that limits the number of the pulses. Do you envision that being
like a throttling mechanism? But delaying the propagation of notification
for some events might cause more instability in a network.

Regards,
Greg

---

From: Peter Psenak <[email-masked]>
Date: Tue, 4 Jan 2022 19:08:00 +0100

Hi Greg,

On 04/01/2022 18:13, Greg Mirsky wrote:
> Hi Peter,
> I'm probably missing something in the current PULSE but I cannot find 
> the mechanism that limits the number of the pulses. Do you envision that 
> being like a throttling mechanism? But delaying the propagation of 
> notification for some events might cause more instability in a network.

no. It's a limit not a delay. If too many edge nodes loose connectivity 
to the ABR in its area, it's a result of the severe event like area 
partition or loss of area connectivity from ABR. These are not types of 
events that we 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 <[email-masked] 
>      > <ppsenak=[email-masked]
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Jan 2022 20:05:50 +0100

>
> 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 loose connectivity
> events that we are trying to address with pulses.

 Is the proposed solution really sound ?

- It *may* signal PE loopback going down only in subset of deployments,
- It *may* signal PE loopback going down only in some types of failure
scenarios,
- It *may* signal PE loopback going down only if the PE going down is lucky
enough among the list of first N to be processed by the ABR
etc ...

Now what about cases where PEs have 10 IPv4 and 20 IPv6 loopbacks - are we
going to trigger pulses containing all of those 30 addresses ?

How about folks not doing next hop self and using peer's IP address for
some SAFIs ? Are we going to also pulse all connected leaves if they are
part of some  summary ?

So pulse is a hint ... if the blind blast succeeds remote PEs *may* trigger
switchover to a backup path (if available).

Don't we have too much uncertainty in this proposal ?

Thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 Jan 2022 11:53:37 -0800

Hi Peter,
thank you for your response. I'm looking forward to the new 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 Peter Psenak <[email-masked]> wrote:

> >      >      > Peter Psenak <[email-masked] <mailto:[email-masked]>
> >      >      >>> I think this does in fact capture the problem trying to
> be
> >      >     solved here, nicely.
> >      >      >>
> >      >      >> not really.
> >      >      >> In fact assigning addresses to the nodes in a way that
> >     they are
> >      >     part of the
> >      >      > No, not if you want more detailed information about
> specific
> >      >      >> The problem we are trying to solve is to use the
> >     summarization
> >      >     but without the
> >      >     In 99,99% of cases there will be only single pulse generated
> when
> >      >     one PE
> >      >      >>> - Tell the customer they can't do this, but they *can*
> >     modify
> >      >     their addressing
> >      >      >>> (this is literally what they do for a living) so that
> they
> >      >     don't have this
> >      >      >>> problem.
> >      >      >>> changes, just to save the operators the trouble of doing
> >     their
> >      >     job correctly?
> >      >      >>> Maybe the answer here is this isn't a good idea, and we
> >     should
> >      >     move on...
> >      >      >>> Thanks,
> >      >      >>> Chris.
> >      >      >>> [as wg member]

---

From: Aijun Wang <[email-masked]>
Date: Wed, 5 Jan 2022 07:01:56 +0800

Hi, Greg:

https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8 has some description for such considerations: 
“ In order to reduce the unnecessary advertisements of PUAM
   messages on ABRs, the ABRs should support the configuration of the
   protected prefixes.  Based on such information, the ABR will only
   advertise the PUAM message when the protected prefixes(for example,
   the loopback addresses of PEs that run BGP) that within the summary
   address is missing.”

Aijun Wang
China Telecom

> On Jan 5, 2022, at 03:56, Greg Mirsky <[email-masked]> wrote:
> 
> 
> Hi Peter,
> thank you for your response. I'm looking forward to the new 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
>

---

From: Aijun Wang <[email-masked]>
Date: Wed, 5 Jan 2022 07:05:59 +0800

I think the mentioned solution can also address Robert and Christian’s concerns.

Aijun Wang
China Telecom

> On Jan 5, 2022, at 07:02, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Greg:
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Jan 2022 00:55:04 +0100

Hi Aijun,

In most deployments summary routes are already crafted carefully to only
cover those destinations which are important and should be reachable from
outside of the area.

So I see no point in building yet another policy to select a subset of
summaries to be PUA eligible.

Along those lines I do not buy into the notion of "some prefixes within
summaries to be more important than others" - it is simply impossible to
say that this PE is more important than the other one in all
practical cases.

If we are to roll out a mechanism to signal unreachability it better be
robust and dependable - not just an optional hint. With that I would
welcome solution which says - if we have more then X prefixes (or % of
prefixes) to be advertised by ABR we stop advertising the summary covering
them (or deaggregate the summary).

Thx,
R.

On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang <[email-masked]>
wrote:

> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8 has
> some description for such considerations:
>> >      >      > Peter Psenak <[email-masked] <mailto:[email-masked]
>> >
>> >      >      >>> Do we *really* want modify our IGPs (a BIG ask) with
>> some
>> >      >     pretty questionable

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 5 Jan 2022 14:58:52 +0800

Hi, Robert:

From: [email-masked] <[email-masked]> On Behalf Of Robert Raszuk
Sent: Wednesday, January 5, 2022 7:55 AM
To: Aijun Wang <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Aijun,

In most deployments summary routes are already crafted carefully to only cover those destinations which are important and should be reachable from outside of the area. 

So I see no point in building yet another policy to select a subset of summaries to be PUA eligible. 

Along those lines I do not buy into the notion of "some prefixes within summaries to be more important than others" - it is simply impossible to say that this PE is more important than the other one in all practical cases. 

If we are to roll out a mechanism to signal unreachability it better be robust and dependable - not just an optional hint. With that I would welcome solution which says - if we have more then X prefixes (or % of prefixes) to be advertised by ABR we stop advertising the summary covering them (or deaggregate the summary). 

[WAJ] Actually, https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7 has proposed similar solutions, although it should be revised to reflect the concerns in this thread and give more careful control for the advertisement of PUA/PULSE information. 

“Considering the balances of reachable information and unreachable

   information announcement capabilities, the implementation of this

   mechanism should set one MAX_Address_Announcement (MAA) threshold

   value that can be configurable.  Then, the ABR should make the

   following decisions to announce the prefixes:

   1.  If the number of unreachable prefixes is less than MAA, the ABR

   should advertise the summary address and the PUAM.

   2.  If the number of reachable address is less than MAA, the ABR

   should advertise the detail reachable address only.

   3.  If the number of reachable prefixes and unreachable prefixes

   exceed MAA, then advertise the summary address with MAX metric.”

Welcome more idea to address such concerns in more reasonable 

Thx,

R.

 

On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Aijun Wang

China Telecom

On Jan 5, 2022, at 07:02, Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Greg:

 

Aijun Wang

China Telecom

On Jan 5, 2022, at 03:56, Greg Mirsky <[email-masked] <mailto:[email-masked]> > wrote:

Hi Peter,

Regards,

Greg

On Tue, Jan 4, 2022 at 10:08 AM Peter Psenak <[email-masked] <mailto:[email-masked]> > wrote:

Hi Greg,

thanks,
Peter

> 
> Regards,
> Greg
> 
> On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak <[email-masked] <mailto:[email-masked]>  
> <mailto:[email-masked] <mailto:[email-masked]> >> wrote:
> 
>     Hi Greg,
> 
>      > <ppsenak=[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >
>     <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>>
>      > wrote:
>      >
>      >     Chris,
>      >
>      >      > Peter Psenak <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >
>     <mailto:[email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> >>> writes:
>      >      >
>      >     <ginsberg=[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >
>      >     <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>> wrote:
>      >      >>>>
>      >      >>>> Tony –
>      >      >>> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>
>      > [email-masked] <mailto:[email-masked]>  <mailto:[email-masked] <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]> 
>     <mailto:[email-masked] <mailto:[email-masked]> >>

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Jan 2022 10:46:38 +0100

Robert,

On 04/01/2022 20:05, Robert Raszuk wrote:
> */"[LES2:] It is reasonable to limit the rate of pulses sent. "/*
> 
> - It *may* signal PE loopback going down only if the PE going down is 
> lucky enough among the list of first N to be processed by the ABR
> etc ...
> 
> Now what about cases where PEs have 10 IPv4 and 20 IPv6 loopbacks - are 
> we going to trigger pulses containing all of those 30 addresses ?
> 

one can pick which ones to pulse - e.g. tag them at the source and pulse 
based on ABR based on the tag value.

So can one set the limit of pulses on ABR if the default value is not 
good enough.

> 
> So pulse is a hint ... if the blind blast succeeds remote PEs *may* 
> trigger switchover to a backup path (if available).
> 

the proposal addresses 99% of realistic PE down scenarios in network 
where summarization is used. That's what we are trying to improve.

For the remaining 1%, things will work as of today, I'm not worried.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Jan 2022 12:22:08 +0100

Peter,

Two other points ..

#1 - Imagine PE

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Jan 2022 12:27:16 +0100

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 time just
fine.

#2 - The PULSE expiration timer may be different between various
implementations. It may even be configurable. So you will have a
network where there are many different timers in place. Now further imagine
that PE restarting (even without data plane being maintained) within IBGP
holdtime ... less them 180 sec. So remote PEs never see a BGP path removal
of the "affected" next hops. Does the proposal assume that after removing
the path based on PULSE reception the remote PEs will all by itself
recompute best path after PULSE timer expires (no other control plane event
will be seen).

Many thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Jan 2022 12:43:36 +0100

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 
> time just fine.

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.

> network where there are many different timers in place. 

there will be default mentioned in the spec that all implementations 
should honor. Having a knob to tune it is up to the implementation.

> Now further 
> imagine that PE restarting (even without data plane being maintained) 
> within IBGP holdtime ... less them 180 sec. So remote PEs never see a 
> BGP path removal of the "affected" next hops. Does the proposal assume 
> that after removing the path based on PULSE reception the remote PEs 
> will all by itself recompute best path after PULSE timer expires (no 
> other control plane event will be seen).

yes, the ingress PE reacting to Pulse would have to re-evaluate the BGP 
best paths of affected prefixes after the pulse expiration.

thanks,
Peter

> 
> Many thx,
> R.
> 
> 
> 
> 
> 
> On Wed, Jan 5, 2022 at 12:22 PM Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Peter,
> 
>     Two other points ..
> 
>     #1 - Imagine PE 
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Jan 2022 12:57:19 +0100

> would tear down the adjacency anyway.

So are you going to add to the draft special handling in this case ?

There is difference between losing adj due to restart for few seconds and
keeping the damage within an area to blasting PULSES globally when it
happens.

Note also that even if we loose adj data plane can stay intact in some area
topologies with GR enabled.

So it is becoming quite interesting to capture this or if not provide
sufficient and easy guidelines to operators to tune PULSEs to match their
network.

> best paths of affected prefixes after the pulse expiration.

"would have to" sounds like a normative MUST to me. Is this going to be
also captured in the new version of the draft ?

Thx,
R.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Jan 2022 13:16:26 +0100

Robert,

> So are you going to add to the draft special handling in this case ?

we could mention it, but there is noting special about it really.

> 
> There is difference between losing adj due to restart for few seconds 
> and keeping the damage within an area to blasting PULSES globally when 
> it happens.

same happens without a pulse today without a summarization - ABR 
propagates the loss of PE prefix(es) to remote areas/domains. ABR does 
not distinguish between the "few seconds restart" and permanent loss if 
the router losses adjacencies.

> 
> Note also that even if we loose adj data plane can stay intact in some 
> area topologies with GR enabled.

from the control plane perspective, loosing adjacency means loosing 
reachability and we react. We are not changing any of it.

> sufficient and easy guidelines to operators to tune PULSEs to match 
> their network.
> 

the draft is specifying IGPs extensions for pulse. The handling of the 
pulse by the interesting apps is not something we should be specifying 
in this draft. Also such handling is a local behavior on the ingress PE.

But we can certainly add some non normative guidelines and 
recommendations for BGP handling of Summary Component Reachability Loss 
Pulse.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 5 Jan 2022 13:29:21 +0100

> same happens without a pulse today without a summarization

We have established that this discussion is about this scenario:

" it's applicable in cases where summarization is used."

and in such cases under some scenarios PULSES can actually make things
worse.
The goal is (or should be) not to make it worse when not needed.

- -

> in this draft. Also such handling is a local behavior on the ingress PE.

The draft is proposing an ephemeral signaling with mandatory timeout.

An alternative could be the non ephemeral nature of the PULSE. You signal
down then you clear it by signaling up. If UP never happens you clear it at
next (or 2nd next) LSDB full sync.

I think this is proper to discuss both on the list and in the draft how to
use it instead of leaving lots of challenges and interpretations to
potential users/apps of this new extension.

Many thx,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Jan 2022 09:39:47 -0800

Hi Aijun,
thank you for pointing that out. I agree that in some deployment scenarios,
only a subset of PEs will be required to be monitored by an ABR. But, as I
look at the problem, the general use case should be the worst case
scenario, i.e., all PEs in the area being monitored.

Just to be clear, I maintain my opinion that this problem is not a routing
protocol problem but a problem to be addressed by the appropriate OAM
mechanism like the Alarm Indication Signal.

Regards,
Greg

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 5 Jan 2022 18:27:07 -0500

Hi Robert

The goal of the draft is providing egress protection when summarization is
used similar to RFC 8679 Egress protection framework, but without the
complexities.

An IGP RIB within a domain is made up on connected interfaces and
loopbacks. Of the two types, the critical prefix to be tracked is the /32
or /128 host routes on egress PE which is the BGP next-hop attribute via
next-hop-self rewrite.  So both connected and loopbacks can be placed in
the same range for large aggregation domains, however due to the
criticality of the next hop attribute the loopbacks are placed in a
separate range, and so not summarized and flooded domain wide.

The BGP next hop attribute is an MPLS exact match FEC binding for the LSP.
Flooding of loopbacks workaround  is typically done for MPLS domain due to
issue with RFC 5283 inter area extension feature not being viable solution
for LPM summary matching,  thus all the prefixes still have to be flooded
 in LDP, so no net reduction in host route flooding.

With the PUA/Pulse feature allows the domain wide flooding of the loopback
host routes is now possible as can now we take advantage and of
summarization.

Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the tracking
of BGP next-hop-attribute component prefixes is critically important to
improved convergence and not rely on BGP dead timers to expire.  Even with
BFD, LFA/RLFA/TILFA local protection , PIC and other optimizations we still
need an optimization to track the summary route component prefixes to speed
up convergence providing  egress PE protection.

Kind Regards

Gyan

On Tue, Jan 4, 2022 at 6:55 PM Robert Raszuk <[email-masked]> wrote:

>> thank you for your response. I'm looking forward to the new 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
>>
>>> >      >      >>> I think this does in fact capture the problem trying
>>> to be
>>> >      >     solved here, nicely.
>>> >      >      >>
>>> >      >      >> not really.
>>> >      >     advertising outside the area. And you want to know about
>>> some
>>> >     of these
>>> >      >     In 99,99% of cases there will be only single pulse
>>> generated when
>>> >      >     one PE
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Jan 2022 01:25:42 +0100

Gyan,

Everyone agrees that indicating down events is a good thing. Please observe
that the discussion is about how to do it, not if to do it.

There is nothing similar in mechanics of local protection (RFC8679) and
ingress protection (this discussion). Just like local repair works very
differently from end to end repair on ingress. Both mechanisms also have
very different achievable connectivity restoration timers .. local can
easily protect in 10s of ms while ingress in 100s or 1000s of ms at it's
best.

Now both PUA/PULSE suggest to use IGP flooding to propagate bad news ...
number of issues have been identified with this approach. It beats me why
we are not using issue tracker in LSR WG. But maybe this type of issue
tracking is reserved for WG docs only.

I suggested BGP double recursion or simply BGP aggregated withdraws
which we could (and perhaps will) pursue in parallel. Greg is also right to
suggest that perhaps out of routing protocols approach should be used and
such bad news should be triggered by OAM.

So all in all I am not sure what point are you trying to highlight in your
below message.

Thx,
R.

On Thu, Jan 6, 2022 at 12:27 AM Gyan Mishra <[email-masked]> wrote:

> The BGP next hop attribute is an MPLS exact match FEC binding for the
> LSP.  Flooding of loopbacks workaround  is typically done for MPLS domain
> due to issue with RFC 5283 inter area extension feature not being viable
> solution for LPM summary matching,  thus all the prefixes still have to be
> flooded  in LDP, so no net reduction in host route flooding.
>
>>>> >      >     We can easily limit the number of pulses generated on ABR
>>>> to
>>>> >     a single
>>>> >      >     network converge fast in case where single (or very few)
>>>> PEs
>>>> >     in an area
>>>> >      >     go down.
>>>> >      >
>>>> >      >     thanks,
>>>> >      >     Peter
>>>> >      >
>>>> >      >
>>>> >      >
>>>> >      >      >
>>>> >      >      > Thanks,
>>>> >      >      > Chris.
>>>> >      >      >
>>>> >      >      >>
>>>> >      >      >> thanks,
>>>> >      >      >> Peter
>>>> >      >      >>
>>>> >      >      >>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 6 Jan 2022 08:58:18 +0800

Hi, Robert and Greg:

The reason that we select the IGP for advertising such “important bad news” is that the potential receivers located in the same IGP as ABR. The nodes within the IGP are all potential receiver for such news, then it is efficient to advertise them via IGP.

Using other OAM mechanism to signals such information is possible but it require the PUB/SUB mechanism. Or else, how to identify the receivers for such news?

Aijun Wang
China Telecom

> On Jan 6, 2022, at 08:26, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Gyan,
> 
> Everyone agrees that indicating down events is a good thing. Please observe that the discussion is about how to do it, not if to do it. 
> 
> There is nothing similar in mechanics of local protection (RFC8679) and ingress protection (this discussion). Just like local repair works very differently from end to end repair on ingress. Both mechanisms also have very different achievable connectivity restoration timers .. local can easily protect in 10s of ms while ingress in 100s or 1000s of ms at it's best. 
> 
> Now both PUA/PULSE suggest to use IGP flooding to propagate bad news ... number of issues have been identified with this approach. It beats me why we are not using issue tracker in LSR WG. But maybe this type of issue tracking is reserved for WG docs only. 
> 
> I suggested BGP double recursion or simply BGP aggregated withdraws which we could (and perhaps will) pursue in parallel. Greg is also right to suggest that perhaps out of routing protocols approach should be used and such bad news should be triggered by OAM. 
> 
> So all in all I am not sure what point are you trying to highlight in your below message. 
> 
> Thx,
> R.
> 
>> The goal of the draft is providing egress protection when summarization is used similar to RFC 8679 Egress protection framework, but without the complexities.  
>> 
>> An IGP RIB within a domain is made up on connected interfaces and loopbacks. Of the two types, the critical prefix to be tracked is the /32 or /128 host routes on egress PE which is the BGP next-hop attribute via next-hop-self rewrite.  So both connected and loopbacks can be placed in the same range for large aggregation domains, however due to the criticality of the next hop attribute the loopbacks are placed in a separate range, and so not summarized and flooded domain wide.  
>> 
>> The BGP next hop attribute is an MPLS exact match FEC binding for the LSP.  Flooding of loopbacks workaround  is typically done for MPLS domain due to issue with RFC 5283 inter area extension feature not being viable solution for LPM summary matching,  thus all the prefixes still have to be flooded  in LDP, so no net reduction in host route flooding.  
>> 
>> With the PUA/Pulse feature allows the domain wide flooding of the loopback host routes is now possible as can now we take advantage and of summarization.
>> 
>> Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the tracking of BGP next-hop-attribute component prefixes is critically important to improved convergence and not rely on BGP dead timers to expire.  Even with BFD, LFA/RLFA/TILFA local protection , PIC and other optimizations we still need an optimization to track the summary route component prefixes to speed up convergence providing  egress PE protection.
>> 
>> Kind Regards 
>> 
>> Gyan
>> 
>>>> On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang <[email-masked]> wrote:
>> Gyan Mishra
>> Network Solutions Architect 
>> Email [email-masked]
>> M 301 502-1347
>> 
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Jan 2022 17:25:50 -0800

Hi Aijun,
thank you for posting the crucial questions. I think that we need to
consider a construct analogous to the Ethernet OAM's Maintenance
Association. We may refer to it, for now, as EVPN MA and it includes all
PEs that belong to a given EVPN. If that is the case, the news of a PE
being disconnected needs to be propagated in EVPN MAs that the PE is
registered for. (I have a feeling that Robert is smiling now as I'm
stepping closer and closer to using the EVPN control plane to propagate the
bad news. It might well be the case.) What still remains an open question
for me, is the definition of "bad news" we want to propagate. That seems to
be coming from the underlay network and it doesn't look like a simple
condition.
What do you think?

Regards,
Greg

On Wed, Jan 5, 2022 at 4:58 PM Aijun Wang <[email-masked]> wrote:

> Hi, Robert and Greg:
>
> The reason that we select the IGP for advertising such “important bad
> news” is that the potential receivers located in the same IGP as ABR. The
> nodes within the IGP are all potential receiver for such news, then it is
> efficient to advertise them via IGP.
>
> Using other OAM mechanism to signals such information is possible but it
> require the PUB/SUB mechanism. Or else, how to identify the receivers for
> such news?
>
>
>
> Aijun Wang
> China Telecom
>
> Everyone agrees that indicating down events is a good thing. Please
> observe that the discussion is about how to do it, not if to do it.
>
>> The goal of the draft is providing egress protection when summarization
>> is used similar to RFC 8679 Egress protection framework, but without the
>> complexities.
>>
>> With the PUA/Pulse feature allows the domain wide flooding of the
>> loopback host routes is now possible as can now we take advantage and of
>> summarization.
>>
>> Even independent of MPLS in an IPv4, IPv6 or SRv6 environment the
>> tracking of BGP next-hop-attribute component prefixes is critically
>> important to improved convergence and not rely on BGP dead timers to
>> expire.  Even with BFD, LFA/RLFA/TILFA local protection , PIC and other
>> optimizations we still need an optimization to track the summary route
>> component prefixes to speed up convergence providing  egress PE protection.
>>
>> Kind Regards
>>
>> Gyan
>>
>>>>> >      > from the IGP area in such a way that the summarization is
>>>>> still
>>>>> >     valid.
>>>>> >      >     prefixes has the state in the network when it's working,
>>>>> so
>>>>> >     you know
>>>>> >      >     digit number to cover the unlikely case of many PEs in
>>>>> area
>>>>> >     becoming
>>>>> >      >      >>> (this is literally what they do for a living) so
>>>>> that they
>>>>> >      >     don't have this
>>>>> >      >      >>> problem.

---

From: <[email-masked]>
Date: Thu, 6 Jan 2022 08:09:11 +0000

Hi Gyan,

You are referring to both summarization and BGP PIC (edge).
BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge relies on the presence of the specific (/32) prefix information in the FIB. Hence it’s not clear to me how you can have both prefix summarization and BGP PIC edge benefits in the FIB on the BGP ingress node.

Taking the example from [1], below is a typical FIB chain for BGP Pic edge:

   IP Leaf:    Pathlist:    IP Leaf:           Pathlist:
   --------  +-------+     --------          +----------+
   VPN-IP1-->|BGP-NH1|-->IGP-IP1(BGP NH1)--->|IGP-NH1,I1|--->Adjacency1
     |       |BGP-NH2|-->....      |         |IGP-NH2,I2|--->Adjacency2
     |       +-------+             |         +----------+
     |                             |
     |                             |
     v                             v
   OutLabel-List:                OutLabel-List:
   +----------------------+      +----------------------+
   |VPN-L11 (VPN-IP1, NH1)|      |IGP-L11 (IGP-IP1, NH1)|
   |VPN-L21 (VPN-IP1, NH2)|      |IGP-L12 (IGP-IP1, NH2)|
   +----------------------+      +----------------------+

           Figure 2 Shared Hierarchical Forwarding Chain at iPE

[1] https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2

To help me get the picture, could you please highlight/draw the change(s) that you have in mind assuming IGP prefix summarization and PULSE? (More specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")

Thanks,
Regards,
-Bruno

Orange Restricted
From: Lsr <[email-masked]> On Behalf Of Gyan Mishra
Sent: Thursday, January 6, 2022 12:27 AM
To: Robert Raszuk <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Robert

Kind Regards

Gyan

On Tue, Jan 4, 2022 at 6:55 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Aijun,

Thx,
R.

On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
I think the mentioned solution can also address Robert and Christian’s concerns.
Aijun Wang
China Telecom

On Jan 5, 2022, at 07:02, Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Greg:

   address is missing.”

Aijun Wang
China Telecom

On Jan 5, 2022, at 03:56, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Peter,

Regards,
Greg

On Tue, Jan 4, 2022 at 10:08 AM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

thanks,
Peter

>
> Regards,
> Greg
>
> On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Greg,
>
>      > <ppsenak=[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>>
>      > wrote:
>      >
>      >     Chris,
>      >
>      >      > Peter Psenak <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> writes:
>      >      >
>      >     <ginsberg=[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>      >     <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >      >>>>
>      >      >>>> Tony –
>      >      >>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 6 Jan 2022 10:25:08 +0100

Bruno,

the PIC is used unchanged with PULSE.

The only difference is that the PIC is triggered by the pulse arrival, 
instead of the IGP route removal. We have made a prototype of it and it 
works fine.

thanks,
Peter

On 06/01/2022 09:09, [email-masked] wrote:
> BGP PIC is quite old story, but if my memory serve me well, BGP PIC edge 
> relies on the presence of the specific (/32) prefix information in the 
> FIB. Hence it’s not clear to me how you can have both prefix 
> summarization and BGP PIC edge benefits in the FIB on the BGP ingress node.
> 
> IP Leaf:Pathlist:IP Leaf:Pathlist:
> 
> --------+-------+--------+----------+
> 
> ||BGP-NH2|-->....||IGP-NH2,I2|--->Adjacency2
> 
> |+-------+|+----------+
> 
> ||
> 
> ||
> 
> vv
> 
> OutLabel-List:OutLabel-List:
> 
> +----------------------++----------------------+
> 
> |VPN-L11 (VPN-IP1, NH1)||IGP-L11 (IGP-IP1, NH1)|
> 
> |VPN-L21 (VPN-IP1, NH2)||IGP-L12 (IGP-IP1, NH2)|
> 
> +----------------------++----------------------+
> 
> [1] 
> https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2 
> <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2>
> 
> To help me get the picture, could you please highlight/draw the 
> change(s) that you have in mind assuming IGP prefix summarization and 
> PULSE? (More specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
> 
> Thanks,
> 
> Regards,
> 
> -Bruno
> 
> Orange Restricted
> 
> *From:*Lsr <[email-masked]> *On Behalf Of *Gyan Mishra
> *Sent:* Thursday, January 6, 2022 12:27 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* Greg Mirsky <[email-masked]>; Les Ginsberg (ginsberg) 
> <[email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang 
> <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony 
> Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr 
> <[email-masked]>; Peter Psenak <[email-masked]>
> *Subject:* Re: [Lsr] BGP vs PUA/PULSE
> 
> Hi Robert
> 
> loopbacks. Of the two types, the critical prefix to be tracked is the 
> /32 or /128 host routes on egress PE which is the BGP next-hop attribute 
> via next-hop-self rewrite.  So both connected and loopbacks can be 
> placed in the same range for large aggregation domains, however due to 
> the criticality of the next hop attribute the loopbacks are placed in a 
> LSP.  Flooding of loopbacks workaround  is typically done for MPLS 
> domain due to issue with RFC 5283 inter area extension feature not being 
> viable solution for LPM summary matching,  thus all the prefixes still 
> have to be flooded  in LDP, so no net reduction in host route flooding.
> 
>     In most deployments summary routes are already crafted carefully to
>     only cover those destinations which are important and should be
>     reachable from outside of the area.
> 
>     Along those lines I do not buy into the notion of "some prefixes
>     within summaries to be more important than others" - it is simply
>     impossible to say that this PE is more important than the other one
>     in all practical cases.
> 
>     If we are to roll out a mechanism to signal unreachability it better
>     be robust and dependable - not just an optional hint. With that I
>     would welcome solution which says - if we have more then X prefixes
>     (or % of prefixes) to be advertised by ABR we stop advertising the
>     summary covering them (or deaggregate the summary).
> 
>     Thx,
> 
>     R.
> 
>     On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             On Jan 5, 2022, at 07:02, Aijun Wang
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
> 
>             Hi, Greg:
> 
>             https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8
>             <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8> has
>             protected prefixes.Based on such information, the ABR will only
> 
>                 On Jan 5, 2022, at 03:56, Greg Mirsky
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
> 
>                 Hi Peter,
> 
>                 thank you for your response. I'm looking forward to the
>                 new 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 Peter Psenak
>                 <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                     Hi Greg,
> 
>                      > On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak
>                     <[email-masked] <mailto:[email-masked]>
>                      >      > Happy New Year to All!
>                      >      > Hi Peter,
>                      >      > Top-pasting:
>                      >      > In 99,99% of cases there will be only
>                     single pulse generated when
>                      >     one PE
>                      >      > goes down. That itself is a very rare
>                     event itself.
>                      >      >
>                      >      > We can easily limit the number of pulses
>                     generated on ABR to a single
>                      >      > digit number to cover the unlikely case of
>                     many PEs in area becoming
>                      >      > unreachable at the same time.
>                      >      >
>                      >      > I think that it is possible for the
>                     summarizing ABR to get
>                      >     disconnected
>                      >      > from the IGP area in such a way that the
>                     summarization is still
>                      >     valid.
>                      >      > If such a case is valid, would the ABR
>                     generate PULSE for each
>                      >      > disconnected PE?
>                      >
>                      >      > Regards,
>                      >      > Greg
>                      >      > On Mon, Jan 3, 2022 at 8:56 AM Peter Psenak
>                      >      > <ppsenak=[email-masked]
>                     <mailto:[email-masked]>>
>                     <mailto:[email-masked]>>>>
>                      >      > wrote:
>                      >      >
>                      >      >     Chris,
>                      >      >
>                      >      >     On 03/01/2022 17:18, Christian Hopps
>                     wrote:
>                      >      >      >
>                      >      >      > Peter Psenak <[email-masked]
>                     <mailto:[email-masked]> <mailto:[email-masked]
>                     <mailto:[email-masked]>>
>                      >     <mailto:[email-masked]
>                     <mailto:[email-masked]> <mailto:[email-masked]
>                     <mailto:[email-masked]>>>> writes:
>                      >      >      >
>                      >      >      >> On 03/01/2022 16:21, Christian
>                     Hopps wrote:
>                      >      >      >>>
>                      >      >      >>>> On Nov 29, 2021, at 7:39 PM, Les
>                     Ginsberg (ginsberg)
>                      >      >     <ginsberg=[email-masked]
>                     <mailto:[email-masked]>>
>                      >      >     <mailto:[email-masked]
>                     <mailto:[email-masked]>>>> 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 reachability
>                     ASAP. Unfortunately,
>                      >     customer
>                      >      >     is unable to assign addresses which
>                     are outside of the summary to
>                      >      >     these nodes.
>                      >      >      >>>
>                      >      >      >>> I think this does in fact capture
>                     the problem trying to be
>                      >      >     solved here, nicely.
>                      >      >      >>
>                      >      >      >> not really.
>                      >      >      >> In fact assigning addresses to the
>                     nodes in a way that
>                      >     they are
>                      >      >     part of the
>                      >      >      >> summary is the right thing to do.
>                      >      >      >
>                      >      >      > No, not if you want more detailed
>                     information about specific
>                      >      >     reachability it's not. And ....
>                      >      >
>                      >      >
>                      >      >     typically you want to summarize all
>                     prefixes inside the area when
>                      >      >     advertising outside the area. And you
>                     want to know about some
>                      >     of these
>                      >      >     prefixes when they are lost to help
>                     convergence.
>                      >      >
>                      >      >
>                      >      >      >
>                      >      >      >> The problem we are trying to solve
>                     is to use the
>                      >     summarization
>                      >      >     but without the
>                      >      >      >> loss of the fast notification of
>                     the node down event.
>                      >      >      >
>                      >      >      > You want more specific information
>                     about reachability, but you
>                      >      >     just want to do it when the network is
>                     stressed and
>                      >     undergoing change.
>                      >      >      >
>                      >      >      > So the "works now" way of not
>                     summarizing these important
>                      >      >     prefixes has the state in the network
>                     when it's working, so
>                      >     you know
>                      >      >     adding and removing it is something
>                     the network is already
>                      >     capable
>                      >      >     of handling.
>                      >      >      >
>                      >      >      > New signaling that *only* is
>                     created when things start
>                      >     failing,
>                      >      >     tests the infrastructure at exactly
>                     the wrong time.
>                      >      >
>                      >      >     In 99,99% of cases there will be only
>                     single pulse generated when
>                      >      >     one PE
>                      >      >     goes down. That itself is a very rare
>                     event itself.
>                      >      >
>                      >      >     We can easily limit the number of
>                     pulses generated on ABR to
>                      >     a single
>                      >      >     digit number to cover the unlikely
>                     case of many PEs in area
>                      >     becoming
>                      >      >     unreachable at the same time.
>                      >      >
>                      >      >
>                      >      >      >
>                      >      >      > If a failing network can handle the
>                     extra state, then a
>                      >      >     functioning stable network of course
>                     can too.
>                      >      >
>                      >      >     no, that's not what we claim. We want
>                     network to be
>                      >     summarized all
>                      >      >     times
>                      >      >     and generate limited number of pulses
>                     at any given time to
>                      >     help the
>                      >      >     network converge fast in case where
>                     single (or very few) PEs
>                      >     in an area
>                      >      >     go down.
>                      >      >
>                      >      >     thanks,
>                      >      >     Peter
>                      >      >
>                      >      >
>                      >      >
>                      >      >      >
>                      >      >      > Thanks,
>                      >      >      > Chris.
>                      >      >      >
>                      >      >      >>
>                      >      >      >> thanks,
>                      >      >      >> Peter
>                      >      >      >>
>                      >      >      >>
>                      >      >      >>> One solution very simple solution
>                     that works today is:
>                      >      >      >>> - Tell the customer they can't do
>                     this, but they *can*
>                      >     modify
>                      >      >     their addressing
>                      >      >      >>> (this is literally what they do
>                     for a living) so that they
>                      >      >     don't have this
>                      >      >      >>> problem.
>                      >      >      >>> Do we *really* want modify our
>                     IGPs (a BIG ask) with some
>                      >      >     pretty questionable
>                      >      >      >>> changes, just to save the
>                     operators the trouble of doing
>                      >     their
>                      >      >     job correctly?
>                      >      >      >>> Maybe the answer here is this
>                     isn't a good idea, and we
>                      >     should
>                      >      >     move on...
>                      >      >      >>> Thanks,
>                      >      >      >>> Chris.
>                      >      >      >>> [as wg member]
>                      >      >      >>>
>                      >      >      >>> Lsr mailing list
>                      >      >      >>> [email-masked]
>                     <mailto:[email-masked]> <mailto:[email-masked]
>                     <mailto:[email-masked]>> <mailto:[email-masked]
>                     <mailto:[email-masked]>
>                      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>                      >      >      >>>
>                     <https://www.ietf.org/mailman/listinfo/lsr>>>
>                      >      >      >>>
>                      >      >      >
>                      >      >      >
>                      >      >
>                      >      >   
>                      >      >     Lsr mailing list
>                      >      > [email-masked] <mailto:[email-masked]>
>                     <mailto:[email-masked] <mailto:[email-masked]>>
>                     <mailto:[email-masked] <mailto:[email-masked]>
>                      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>                      >      > https://www.ietf.org/mailman/listinfo/lsr
>                     <https://www.ietf.org/mailman/listinfo/lsr>>>
>                      >      >
>                      >
> 
> /Network Solutions Architect /
> 
> /Email [email-masked] <mailto:[email-masked]>/
> 
> /M 301 502-1347/
>

---

From: Peter Psenak <[email-masked]>
Date: Thu, 6 Jan 2022 10:30:45 +0100

Greg,

On 05/01/2022 18:39, Greg Mirsky wrote:
> Hi Aijun,
> thank you for pointing that out. I agree that in some deployment 
> scenarios, only a subset of PEs will be required to be monitored by an 
> ABR. But, as I look at the problem, the general use case should be the 
> worst case scenario, i.e., all PEs in the area being monitored.
> 
> Just to be clear, I maintain my opinion that this problem is not a 
> routing protocol problem but a problem to be addressed by the 
> appropriate OAM mechanism like the Alarm Indication Signal.

please note that without the use of summarizatiion it is the routing 
protocol, namely IGP, that advertises the loss of reachability of PE's 
address. I see no reason why with the use of summarization this suddenly 
changes and becomes an OAM problem.

thanks,
Peter

> 
> Regards,
> Greg
> 
> On Tue, Jan 4, 2022 at 3:01 PM Aijun Wang <[email-masked] 
>>     thank you for your response. I'm looking forward to the new
>>     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
>>
>>         >      > In 99,99% of cases there will be only single pulse
>>         generated when
>>         >     one PE
>>         >      > goes down. That itself is a very rare event itself.
>>         >      >
>>         >      > We can easily limit the number of pulses generated on
>>         ABR to a single
>>         >      > digit number to cover the unlikely case of many PEs
>>         in area becoming
>>         >      > I think that it is possible for the summarizing ABR
>>         to get
>>         >     disconnected
>>         >      > If such a case is valid, would the ABR generate PULSE
>>         for each
>>         >      > disconnected PE?
>>         >
>>         >      >     On 03/01/2022 17:18, Christian Hopps wrote:
>>         >      >      >
>>         >     <mailto:[email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked] <mailto:[email-masked]>>>> writes:
>>         >      >      >
>>         >      >      >> On 03/01/2022 16:21, Christian Hopps wrote:
>>         >      >      >>>
>>         >      >      >>>> On Nov 29, 2021, at 7:39 PM, Les Ginsberg
>>         (ginsberg)
>>         >      >      >>>>    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 reachability ASAP.
>>         Unfortunately,
>>         >     customer
>>         >      >     is unable to assign addresses which are outside
>>         of the summary to
>>         >      >     these nodes.
>>         >      >      >>>
>>         >      >      >>> I think this does in fact capture the
>>         problem trying to be
>>         >      >     solved here, nicely.
>>         >      >      >>
>>         >      >      >> not really.
>>         >      >      >> In fact assigning addresses to the nodes in a
>>         way that
>>         >     they are
>>         >      >     part of the
>>         >      >      > No, not if you want more detailed information
>>         about specific
>>         >      >     typically you want to summarize all prefixes
>>         inside the area when
>>         >      >     advertising outside the area. And you want to
>>         know about some
>>         >     of these
>>         >      >     prefixes when they are lost to help convergence.
>>         >      >
>>         >      >
>>         >      >      >
>>         >      >      >> The problem we are trying to solve is to use the
>>         >     summarization
>>         >      >     but without the
>>         >      >      >> loss of the fast notification of the node
>>         down event.
>>         >      >      >
>>         >      >      > You want more specific information about
>>         reachability, but you
>>         >      >     just want to do it when the network is stressed and
>>         >     undergoing change.
>>         >      >      >
>>         >      >      > So the "works now" way of not summarizing
>>         these important
>>         >      >     prefixes has the state in the network when it's
>>         working, so
>>         >     you know
>>         >      >     adding and removing it is something the network
>>         is already
>>         >     capable
>>         >      >     of handling.
>>         >      >      >
>>         >      >      > New signaling that *only* is created when
>>         things start
>>         >     failing,
>>         >      >     tests the infrastructure at exactly the wrong time.
>>         >      >
>>         >      >     In 99,99% of cases there will be only single
>>         pulse generated when
>>         >      >     one PE
>>         >      >     goes down. That itself is a very rare event itself.
>>         >      >
>>         >      >     digit number to cover the unlikely case of many
>>         PEs in area
>>         >     becoming
>>         >      >      > If a failing network can handle the extra
>>         state, then a
>>         >      >     functioning stable network of course can too.
>>         >      >
>>         >      >     no, that's not what we claim. We want network to be
>>         >     summarized all
>>         >      >     times
>>         >      >     and generate limited number of pulses at any
>>         given time to
>>         >     help the
>>         >      >     network converge fast in case where single (or
>>         very few) PEs
>>         >     in an area
>>         >      >     go down.
>>         >      >
>>         >      >     thanks,
>>         >      >     Peter
>>         >      >
>>         >      >
>>         >      >
>>         >      >      >
>>         >      >      > Thanks,
>>         >      >      > Chris.
>>         >      >      >
>>         >      >      >>
>>         >      >      >> thanks,
>>         >      >      >> Peter
>>         >      >      >>
>>         >      >      >>
>>         >      >      >>> One solution very simple solution that works
>>         today is:
>>         >      >      >>> - Tell the customer they can't do this, but
>>         they *can*
>>         >     modify
>>         >      >     their addressing
>>         >      >      >>> (this is literally what they do for a
>>         living) so that they
>>         >      >     don't have this
>>         >      >      >>> problem.
>>         >      >      >>> Do we *really* want modify our IGPs (a BIG
>>         ask) with some
>>         >      >     pretty questionable
>>         >      >      >>> changes, just to save the operators the
>>         trouble of doing
>>         >     their
>>         >      >     job correctly?
>>         >      >      >>> Maybe the answer here is this isn't a good
>>         idea, and we
>>         >     should
>>         >      >     move on...
>>         >      >      >>> Thanks,
>>         >      >      >>> Chris.
>>         >      >      >>> [as wg member]
>>         >      >      >>> _______________________________________________
>>         >      >      >>> Lsr mailing list
>>         >      >      >>> [email-masked] <mailto:[email-masked]>
>>         >      >      >>> https://www.ietf.org/mailman/listinfo/lsr
>>         >      >     <https://www.ietf.org/mailman/listinfo/lsr
>>         >      >     _______________________________________________
>>         >      >     Lsr mailing list
>>         >      >     <https://www.ietf.org/mailman/listinfo/lsr

---

From: <[email-masked]>
Date: Thu, 6 Jan 2022 09:40:35 +0000

Peter,

Thanks for your answer.
Please see inline [Bruno]

> From: Peter Psenak <[email-masked]>
> Sent: Thursday, January 6, 2022 10:25 AM
> 
> Bruno,
> 

[Bruno] OK. Therefore, from a FIB standpoint, does this mean that the scaling properties are also unchanged compared to loopback leaking (no aggregation on ABR)?
In which case, compared to leaking loopbacks, the key/only benefit of ABR summarization + PULSE is the reduction of the number of (IS-IS) LSP being flooded (before failure, and after failure if multiple PE fails at the same time)?

If so this seem to partially contradict the below statement from Gyan as we only get partial advantage of the summarization.

> > *Sent:* Thursday, January 6, 2022 12:27 AM
[...]

> instead of the IGP route removal. We have made a prototype of it and it

[Bruno] OK thanks. I believe you, I was just trying to more precisely understand the benefits and limits.

--Bruno
 
> >                     <mailto:[email-masked]>>> wrote:
> >                      >
> >                      >     Hi Greg,
> >                      >
> ______________________________________________________________________
> ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

Orange Restricted

---

From: Peter Psenak <[email-masked]>
Date: Thu, 6 Jan 2022 11:02:34 +0100

Bruno,

> [Bruno] OK. Therefore, from a FIB standpoint, does this mean that the scaling properties are also unchanged compared to loopback leaking (no aggregation on ABR)?

that is correct.

> In which case, compared to leaking loopbacks, the key/only benefit of ABR summarization + PULSE is the reduction of the number of (IS-IS) LSP being flooded (before failure, and after failure if mul…

it's the reduction of number of prefixes that would need to be 
advertised by IGP and installed in foowarding of all routers.

thanks,
Peter

---

From: <[email-masked]>
Date: Thu, 6 Jan 2022 10:18:40 +0000

Peter,

> Sent: Thursday, January 6, 2022 11:03 AM
> 
> Bruno,
> 
> > [Bruno] OK. Therefore, from a FIB standpoint, does this mean that the scaling
> properties are also unchanged compared to loopback leaking (no aggregation on
> ABR)?
> 
> that is correct.

OK. Clear. Thanks.
IMHO that point has been missing in some of the threads. (not from you)

> > In which case, compared to leaking loopbacks, the key/only benefit of ABR
> summarization + PULSE is the reduction of the number of (IS-IS) LSP being
> flooded (before failure, and after failure if multiple PE fails at the same time)?
> 

In sync with the benefits on the IGP signaling part.
For the forwarding part:
- I agree for pure MPLS LSR/P routers not installing BGP routes
- But for PE/ingress nodes and IP transit routers installing BGP routes, since nothing change in the FIB, I would assume that this provides no reduction on the number of prefix installed in the FIB (well, at least when BGP PIC edge is used).

Thanks,
--Bruno 

> thanks,
> Peter
> 
> 
> >
> > If so this seem to partially contradict the below statement from Gyan as we only
> get partial advantage of the summarization.
> >
> >>>              <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-
> unreachable-
> >> annoucement-08#section-8> has
> >>> If you have received this email in error, please notify the sender and delete
> this
> >> message and its attachments.

Orange Restricted

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Jan 2022 12:31:41 +0100

Peter,

So far you and others have been saying all along that one of the
applications which uses PULSE can be BGP.

If so I am afraid this is not PIC (== Prefix *Independent *Convergence)
anymore. And I think this was Bruno's valid point.

Today BGP registers with RIB next hops for tracking, When next hop goes
down or metric changes BGP get's notification. So now there needs to be a
new construct stating that registered next hop went away based on PULSE
signaling and *all* best paths need to be recomputed (or in case of
multipath enabled - removed). So yes this is a trigger, but it is *PER
PREFIX*.

That is my current understanding of how PULSE will be used. All of this is
a guess as you keep this part as an implementation detail/secret :). That
is also compatible with the notion of recomputation of the removed best
path when PULSE expires.

Now one could potentially do it in a different way - PIC style - that is
first to preinstall in FIB active and backup paths all going to the next
hop X and simply invalidate this next hop X when PULSE arrives with single
adj rewrite - directly in the FIB itself.

But in this case PULSE will never be heard by BGP or for that matter by any
other app - not giving them a chance to select another best path in case of
no iBGP multipath to be enabled. You could also propagate this to both BGP
and FIB.

What seems big unknown in the latter case is the operation aspect of those
events in the light of the ephemeral nature of PULSE. I am sure you are
going in either case to generate a syslog message upon PULSE reception.
Extending current RIB, building shadow ephemeral RIB or bypassing it to
talk directly between IGP and FIB is another operational concern.

Thx,
Robert.

PS. Also keep in mind that in SRv6 used say for VPN applications you do not
want to signal /128 next hops but SID locator prefix of the remote egress
PE :) This is going to be fun !

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Jan 2022 12:53:12 +0100

Apologies ... want to correct myself for clarity:

was: "active and backup paths all going to the next hop X"

should be: "active paths all going to the next hop X and backup paths going
to different next hops"

On Thu, Jan 6, 2022 at 12:31 PM Robert Raszuk <[email-masked]> wrote:

> But in this case PULSE will never be heard by BGP or for that matter by
> any other app - not giving them a chance to select another best path in
> case of no iBGP multipath to be enabled. You could also propagate this to
> both BGP and FIB.
>
> PS. Also keep in mind that in SRv6 used say for VPN applications you do
> not want to signal /128 next hops but SID locator prefix of the remote
> egress PE :) This is going to be fun !
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 6 Jan 2022 14:36:05 +0000

The way I read this is that other applications could use the generic IGP pulse mechanism as opposed to other applications using the route unreachable signals conveyed using the IGP pulse mechanism.
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, January 6, 2022 at 6:54 AM
To: "Peter Psenak (ppsenak)" <[email-masked]>
Cc: Hannes Gredler <[email-masked]>, Bruno Decraene <[email-masked]>, Tony Li <[email-masked]>, Shraddha Hegde <[email-masked]>, lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

should be: "active paths all going to the next hop X and backup paths going to different next hops"

On Thu, Jan 6, 2022 at 12:31 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Peter,

So far you and others have been saying all along that one of the applications which uses PULSE can be BGP.

If so I am afraid this is not PIC (== Prefix Independent Convergence) anymore. And I think this was Bruno's valid point.

Today BGP registers with RIB next hops for tracking, When next hop goes down or metric changes BGP get's notification. So now there needs to be a new construct stating that registered next hop went away based on PULSE signaling and *all* best paths need to be recomputed (or in case of multipath enabled - removed). So yes this is a trigger, but it is *PER PREFIX*.

That is my current understanding of how PULSE will be used. All of this is a guess as you keep this part as an implementation detail/secret :). That is also compatible with the notion of recomputation of the removed best path when PULSE expires.

Now one could potentially do it in a different way - PIC style - that is first to preinstall in FIB active and backup paths all going to the next hop X and simply invalidate this next hop X when PULSE arrives with single adj rewrite - directly in the FIB itself.

But in this case PULSE will never be heard by BGP or for that matter by any other app - not giving them a chance to select another best path in case of no iBGP multipath to be enabled. You could also propagate this to both BGP and FIB.

What seems big unknown in the latter case is the operation aspect of those events in the light of the ephemeral nature of PULSE. I am sure you are going in either case to generate a syslog message upon PULSE reception. Extending current RIB, building shadow ephemeral RIB or bypassing it to talk directly between IGP and FIB is another operational concern.

Thx,
Robert.

PS. Also keep in mind that in SRv6 used say for VPN applications you do not want to signal /128 next hops but SID locator prefix of the remote egress PE :) This is going to be fun !

On Thu, Jan 6, 2022 at 10:25 AM Peter Psenak <[email-masked]<mailto:[email-masked]>> wrote:
Bruno,

thanks,
Peter

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 6 Jan 2022 13:51:49 -0500

Hi Bruno

As far as BGP PIC (edge) it is completely orthogonal to summarization
framework the PUA/PULSE solutions is addressing.

Let’s say for example you have ingress area A and egress area B and both
have summaries of the other area.  So all LPM longer matches for ingress
area A exist within ingress area A and the summary for area A only  exists
in area B and vice versa.

I will call source area the area where the prefixes reside.  I will call
the destination area the area where the loopbacks are summarized into the
alternate area.

As far as BGP PIC edge the pre programmed backup path backup path is
installed to BGP RIB on source Area eBGP PE-CE peering for alternate backup
path for instantaneous convergence.  So summarization does not come into
play here with PIC Edge as it is on the source AS where the LPM routes
exists locally to PE.  Also with BGP PIC Edge the backup path next hop that
gets pre programmed is the eBGP external link subnet that is not advertised
into the IGP as next-hop-self next hop rewrite to loopback0 is what is
advertised into IGP for PE-RR peering iBGP peering.  So the host routes
being summarized are completely orthogonal to BGP PIC Edge.

BGP PIC (core) H-FIB updates would have the loopbacks in the H-FIB on PE
and P routers which would get updated when PE failover occurs.  For the
source Area the LPM host routes would already exist so no change here.  For
the destination area the summary routes would be programmed into the H-FIB
instead of host routes.  I don’t see any issue here as well or change to
current behavior.

For BGP next hop tracking IGP callback, BGP is making a callback to IGP so
that process would be the same.  But now the IGP would have the ephemeral
PUA/Pulse bad info to now send back to BGP would be the net change.

Kind Regards

Gyan

On Thu, Jan 6, 2022 at 3:09 AM <[email-masked]> wrote:

> relies on the presence of the specific (/32) prefix information in the FIB.
> Hence it’s not clear to me how you can have both prefix summarization and
> BGP PIC edge benefits in the FIB on the BGP ingress node.
>
>
>
> To help me get the picture, could you please highlight/draw the change(s)
> that you have in mind assuming IGP prefix summarization and PULSE? (More
> specifically regarding the IGP leaf “IGP-IP1(BGP NH1)")
>
>
>
> Thanks,
>
> Regards,
>
> -Bruno
>
>
>
>
>
> Orange Restricted
>
> *From:* Lsr <[email-masked]> *On Behalf Of *Gyan Mishra
> *Cc:* Greg Mirsky <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang <
> [email-masked]>; Shraddha Hegde <[email-masked]>; Tony
> Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <
> [email-masked]>; Peter Psenak <[email-masked]>
> *Network Solutions Architect *
>

*Gyan Mishra*

*M 301 502-1347*

---

From: Peter Psenak <[email-masked]>
Date: Fri, 7 Jan 2022 08:44:45 +0100

Bruno,

> - But for PE/ingress nodes and IP transit routers installing BGP routes, since nothing change in the FIB, I would assume that this provides no reduction on the number of prefix installed in the FIB…

we are talking purely IGP prefixes here. Summarization itself results in 
reduction of number of IGP prefixes in FIB.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Fri, 7 Jan 2022 09:17:33 +0100

Robert,

On 06/01/2022 12:31, Robert Raszuk wrote:
> If so I am afraid this is not PIC (== Prefix _Independent _Convergence) 
> down or metric changes BGP get's notification. So now there needs to be 
> a new construct stating that registered next hop went away based on 
> PULSE signaling and *all* best paths need to be recomputed (or in case 
> of multipath enabled - removed). So yes this is a trigger, but it is 
> *PER PREFIX*.

not necessarily. Pulse can be treated similarly as the BGP NH down and 
it would still result it PIC like behavior.

> 
> That is my current understanding of how PULSE will be used. All of this 
> is a guess as you keep this part as an implementation detail/secret :). 

pretty much, but it's not a rocket science and people will figure it out.

> That is also compatible with the notion of recomputation of the removed 
> best path when PULSE expires.
> 
> hop X and simply invalidate this next hop X when PULSE arrives with 
> single adj rewrite - directly in the FIB itself.

you see, you are already finding out the PIC way :)

> case of no iBGP multipath to be enabled. You could also propagate this 
> to both BGP and FIB.

again, it's an implementation choice, there are multiple ways to do it.

> 
> What seems big unknown in the latter case is the operation aspect of 
> those events in the light of the ephemeral nature of PULSE. I am sure 
> you are going in either case to generate a syslog message upon PULSE 
> reception. Extending current RIB, building shadow ephemeral RIB or 
> bypassing it to talk directly between IGP and FIB is another operational 
> concern.

several ways to implement that local behavior.

> egress PE :) This is going to be fun !

it does not change any of the above though :)

thanks,
Peter

---

From: <[email-masked]>
Date: Fri, 7 Jan 2022 14:02:06 +0000

Hi Gyan,

Orange Restricted
From: Gyan Mishra <[email-masked]>
Sent: Thursday, January 6, 2022 7:52 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Christian Hopps <[email-masked]>; Greg Mirsky <[email-masked]>; Hannes Gredler <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Peter Psenak <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Bruno

As far as BGP PIC (edge) it is completely orthogonal to summarization framework the PUA/PULSE solutions is addressing.
[Bruno] Not completely because BGP PIC edge relies on the presence of a FIB structure specific to each BGP next-hop (typically loopback when BGP next-hop self is used)

Let’s say for example you have ingress area A and egress area B and both have summaries of the other area.  So all LPM longer matches for ingress area A exist within ingress area A and the summary for area A only  exists in area B and vice versa.

I will call source area the area where the prefixes reside.  I will call the destination area the area where the loopbacks are summarized into the alternate area.

As far as BGP PIC edge the pre programmed backup path backup path is installed to BGP RIB on source Area eBGP PE-CE peering for alternate backup path for instantaneous convergence.
[Bruno] I was referring to BGP PIC edge on the ingress PE. Please refer to iPE in https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-17#section-2.2

King regards,
--Bruno

  So summarization does not come into play here with PIC Edge as it is on the source AS where the LPM routes exists locally to PE.  Also with BGP PIC Edge the backup path next hop that gets pre programmed is the eBGP external link subnet that is not advertised into the IGP as next-hop-self next hop rewrite to loopback0 is what is advertised into IGP for PE-RR peering iBGP peering.  So the host routes being summarized are completely orthogonal to BGP PIC Edge.

BGP PIC (core) H-FIB updates would have the loopbacks in the H-FIB on PE and P routers which would get updated when PE failover occurs.  For the source Area the LPM host routes would already exist so no change here.  For the destination area the summary routes would be programmed into the H-FIB instead of host routes.  I don’t see any issue here as well or change to current behavior.

For BGP next hop tracking IGP callback, BGP is making a callback to IGP so that process would be the same.  But now the IGP would have the ephemeral PUA/Pulse bad info to now send back to BGP would be the net change.

Kind Regards

Gyan

On Thu, Jan 6, 2022 at 3:09 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Thanks,
Regards,
-Bruno

Orange Restricted
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: Thursday, January 6, 2022 12:27 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Peter Psenak <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Robert

Kind Regards

Gyan

Thx,
R.

   address is missing.”

Aijun Wang
China Telecom

Hi Peter,

Regards,
Greg

thanks,
Peter

Gyan Mishra

M 301 502-1347

Thank you.
--

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 7 Jan 2022 12:12:00 -0500

Thanks Bruno for the reference and clarification.

Gyan
On Fri, Jan 7, 2022 at 9:02 AM <[email-masked]> wrote:

> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Thursday, January 6, 2022 7:52 PM
> *To:* DECRAENE Bruno INNOV/NET <[email-masked]>
> *Cc:* Aijun Wang <[email-masked]>; Christian Hopps <
> [email-masked]>; Greg Mirsky <[email-masked]>; Hannes Gredler <
> [email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Peter
> Psenak <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha
> Hegde <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]
> >
> [Bruno] Not completely because BGP PIC edge relies on the presence of a
> FIB structure specific to each BGP next-hop (typically loopback when BGP
> next-hop self is used)
>
>
>
> path for instantaneous convergence.
>
> [Bruno] I was referring to BGP PIC edge on the ingress PE. Please refer to
> iPE in
>   So summarization does not come into play here with PIC Edge as it is on
> the source AS where the LPM routes exists locally to PE.  Also with BGP PIC
> Edge the backup path next hop that gets pre programmed is the eBGP external
> link subnet that is not advertised into the IGP as next-hop-self next hop
> rewrite to loopback0 is what is advertised into IGP for PE-RR peering iBGP
> peering.  So the host routes being summarized are completely orthogonal to
> BGP PIC Edge.
>
>
>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 21:07:54 +0000

Chris/Tony -

We have received requests from real customers who both need to summarize AND would like better response time to loss of reachability to individual nodes.
If they could operate at the necessary scale without summarizing they would have already - so telling customers to simply make sure they don't use summaries isn't helpful.

There are then two ways to respond:

1)Sorry, when you use summaries you lose the ability to receive state information about individual prefixes covered by the summary. There is nothing we can do to help you.

This seems to be what the two of you are saying.

2)We can provide a way to improve response time for the loss of reachability to individual destinations covered by a summary, but its use will be limited to isolated failures. Failures which affect a significant number of destinations at the same time will realize no benefit from the solution. If this limitation is acceptable then we have proposals that we think will be useful.

That's what we are trying to do.

   Les

From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: Monday, January 3, 2022 1:09 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

On Jan 3, 2022, at 11:23 AM, Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

+1

T

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 Jan 2022 13:29:58 -0800

Hi Les,
thank you for bringing the real-life scenarios to the discussion. In your
opinion, what prevents an operator from monitoring a remote PE using a
multi-hop BFD? Do you have an estimated number of such sessions each PE
must handle? What could be the required guaranteed failure detection time?

Best regards,
Greg

On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> Chris/Tony –
>
>
>
> We have received requests from real customers who both need to summarize
> AND would like better response time to loss of reachability to individual
> nodes.
>
> If they could operate at the necessary scale without summarizing they
> would have already – so telling customers to simply make sure they don’t
> use summaries isn’t helpful.
>
>
>
> 1)Sorry, when you use summaries you lose the ability to receive state
> information about individual prefixes covered by the summary. There is
> nothing we can do to help you.
>
>
>
> 2)We can provide a way to improve response time for the loss of
> reachability to individual destinations covered by a summary, but its use
> will be limited to isolated failures. Failures which affect a significant
> number of destinations at the same time will realize no benefit from the
> solution. If this limitation is acceptable then we have proposals that we
> think will be useful.
>
>
>
> That’s what we are trying to do.
>
>
>
>    Les
>
>
>
>
>
>
>
> *From:* Tony Li <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Monday, January 3, 2022 1:09 PM
> *To:* Christian Hopps <[email-masked]>
> *Cc:* Peter Psenak (ppsenak) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <
> [email-masked]>; Aijun Wang <[email-masked]>; Hannes
> Gredler <[email-masked]>; lsr <[email-masked]>
> And then people get what they want, w/o protocol changes/upgrades, and
> it's using time tested and hardened IGP code and designs.
>
>
>
>
>
> +1
>
>
>
> T
>
>

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 13:41:13 -0800

Les,

> If they could operate at the necessary scale without summarizing they would have already – so telling customers to simply make sure they don’t use summaries isn’t helpful.

To be clear: I think the suggestion was to not summarize the endpoints that you want detailed information about. Summarizing the rest of the area is certainly sensible.  This should not be hard to accomplish: simply advertise the loopbacks for the relevant systems out of another prefix and then leak them.

This should give you both scalability and specific information. It also has the advantage that the scale pressure is present in the steady state, not in failure scenarios. Failing into the worst case situation is always a serious concern.  Having to add heuristic mechanisms to prevent scalability failures is pretty indicative that this is not a very robust approach.

If response time really is the key concern, then why are we relying on flooding? We know that that’s not rapid as it will be hop-by-hop with arbitrary delay. If response time really is the priority, then the other alternatives we’ve discussed (BGP, BFD, a pub-sub mechanism) would all seem to be preferable.

Bottom line: this doesn’t seem like it should be in the IGP.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 10 Jan 2022 23:55:52 +0100

Les,

> AND would like better response time to loss of reachability to individual

We all agree the request is legitimate.

But do they realize that to practically employ what you are proposing (new
PDU flooding) requires 100% software upgrade to all IGP nodes in the entire
network ? Do they also realize that to effectively use it requires data
plane change (sure software but data plane code is not as simple as PI) on
all ingress PEs ?

And with scale requirements you are describing it seems this would be 1000s
of nodes (if not more). That's massive if compared to
alternative approaches to achieve the same or even better results.

Many thx,
Robert

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 23:19:21 +0000

Greg –

The obvious issue is scale. Since you need a full mesh you are talking about N**2 behavior – so it doesn’t take many nodes to require thousands of BFD sessions.

In terms of detect time, we are trying to get an order of magnitude improvement from normal BGP session timers – so we are aiming for a modest number of seconds.

   Les

From: Greg Mirsky <[email-masked]>
Sent: Monday, January 10, 2022 1:30 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Tony Li <[email-masked]>; Christian Hopps <[email-masked]>; Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,
thank you for bringing the real-life scenarios to the discussion. In your opinion, what prevents an operator from monitoring a remote PE using a multi-hop BFD? Do you have an estimated number of such sessions each PE must handle? What could be the required guaranteed failure detection time?

Best regards,
Greg

On Mon, Jan 10, 2022 at 1:08 PM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Chris/Tony –

   Les

+1

T

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jan 2022 00:27:03 +0100

>  we are trying to get an order of magnitude improvement from normal BGP
> session timers
>

Please observe that "normal BGP session timers" play no role in this if we
are serious about the objective.

Just like ABR get's the information about PE down events so can the local
area BGP Route Reflector(s). I can argue that BGP withdrawal of subject
next hop can be triggered from such RR much faster then all ABRs in said
area will get and process local IGP flooding from all peers.

Then you need to compare the speed of flooding via 10s of IGP nodes vs at
most two RR hops to get to ingress PEs with the precious information.

I think the conclusion is obvious. Along the same lines OAM can do the job.
The problem with that however is the need for a new transport to propagate
that information around.

Best,
R.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 Jan 2022 15:36:19 -0800

Hi Les,
thank you for the detailed clarifications. Please find my follow-up notes
in-lined below under the GIM>> tag.

Regards,
Greg

On Mon, Jan 10, 2022 at 3:19 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Greg –
>
>
>
> The obvious issue is scale. Since you need a full mesh you are talking
> about N**2 behavior – so it doesn’t take many nodes to require thousands of
> BFD sessions.
>
GIM>> If I understand the scenario correctly, N represents the number of
PEs, not the number of routers in ASes. If that is the case, what could be
a good estimate for N?

>
>
> In terms of detect time, we are trying to get an order of magnitude
> improvement from normal BGP session timers – so we are aiming for a modest
> number of seconds.
>
GIM>> That is very helpful information, thank you. Then, we can expect that
a one-second interval for the transmission of a BFD Control packet would be
acceptable and guarantee failure detection within three seconds. If that is
the case, I'll note that many platforms support thousands of BFD sessions
at 3.3 msec intervals. It appears to me that the case we're discussing
produces/processes 330 times fewer BFD packets per session. Should somewhat
help with the scaling, would you agree?

>
>
>    Les
>
>
>
>
>
> *From:* Greg Mirsky <[email-masked]>
> *Sent:* Monday, January 10, 2022 1:30 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Tony Li <[email-masked]>; Christian Hopps <[email-masked]>;
> Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>;
> Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>;
> lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jan 2022 00:36:48 +0100

Les,

> about N**2 behavior – so it doesn’t take many nodes to require thousands of

That does sound scary doesn't it ? 1000s is a rather big number ... :)

Well good news is that we have recently finished work and moved to IESG
with unsolicited BFD proposal:

https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-09

That means that you can use BFD probes with zero configured session(s) yet
get full benefit of remote liveness discovery. Just imagine when BGP
registered with the RIB request to track given the next hop you trigger
such BFD probes at requested frequency.

Zero change to control plane nor data plane. Yet full benefit.

And while we are at this point let's observe that most if not all real PEs
can respond to BFD in line cards and the amount of such traffic would be
completely negligible when considering forwarding performance of today's
production PEs both in terms of PPS or LC throughput.

Cheers,
Robert.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 23:37:41 +0000

Tony –

I understand what Chris wrote.
And if customers could do what he suggested then they would not have an issue.

But there are deployments where what he suggested is not possible – largely I think because the set of “prefixes of interest” is in itself large.

So while not all customers have an issue, some customers do and we are trying to find a way to address those deployments.

As far as the alternative proposals, I will comment on them if/when there is something visible – but I think they will all suffer from scale issues.

   Les

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Monday, January 10, 2022 1:41 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>; Aijun Wang <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 00:07:08 +0000

Robert -

From: Robert Raszuk <[email-masked]>
Sent: Monday, January 10, 2022 2:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Tony Li <[email-masked]>; Christian Hopps <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Shraddha Hegde <[email-masked]>; Aijun Wang <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Les,

[LES:] It does not seem to me that everyone does agree on that – but I appreciate that you agree.

But do they realize that to practically employ what you are proposing (new PDU flooding) requires 100% software upgrade to all IGP nodes in the entire network ? Do they also realize that to effectively use it requires data plane change (sure software but data plane code is not as simple as PI) on all ingress PEs ?

[LES:] As far as forwarding, as Peter has indicated, we have a POC and it works fine. And there are many possible ways for implementations to go.
It may or may not require 100% software upgrade – but I agree a significant number of nodes have to be upgraded to at least support pulse flooding.

And with scale requirements you are describing it seems this would be 1000s of nodes (if not more). That's massive if compared to alternative approaches to achieve the same or even better results.

[LES:] Be happy to review other solutions if/when someone writes them up.
I think what is overlooked in the discussion of other solutions is that reachability info is provided by the IGP. If all the IGP advertises is a summary then how would individual loss of reachability become known at scale?
You seem focused on the notification delivery mechanism only.

   Les

Many thx,
Robert

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jan 2022 01:14:37 +0100

Hi Les,

*> You seem focused on the notification delivery mechanism only.*

Not really. For me, an advertised summary is like a prefix when you are
dialing a country code. Call signaling knows to go north if you are calling
a crab shop in Alaska.

Now such direction does not indicate if the shop is open or has crabs.

That info you need to get over the top as a service. So I am much more in
favor to make the service to tell you directly or indirectly that it is
available.

Best,
R.

On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> Robert -
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Monday, January 10, 2022 2:56 PM
> Peter Psenak (ppsenak) <[email-masked]>; Shraddha Hegde <
> *[LES:] It does not seem to me that everyone does agree on that – but I
> appreciate that you agree.*
>
>
>
> *[LES:] As far as forwarding, as Peter has indicated, we have a POC and it
> works fine. And there are many possible ways for implementations to go.*
>
> *It may or may not require 100% software upgrade – but I agree a
> significant number of nodes have to be upgraded to at least support pulse
> flooding.*
>
>
>
>
>
> And with scale requirements you are describing it seems this would be
> 1000s of nodes (if not more). That's massive if compared to
> *[LES:] Be happy to review other solutions if/when someone writes them up.*
>
> *I think what is overlooked in the discussion of other solutions is that
> reachability info is provided by the IGP. If all the IGP advertises is a
> summary then how would individual loss of reachability become known at
> scale?*
>
> *You seem focused on the notification delivery mechanism only.*
>
>
>
> *   Les*
>
>
>
> Many thx,
>
> Robert
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 00:25:08 +0000

Greg –

Inline.

Sent: Monday, January 10, 2022 3:36 PM

Hi Les,
thank you for the detailed clarifications. Please find my follow-up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Mon, Jan 10, 2022 at 3:19 PM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Greg –

The obvious issue is scale. Since you need a full mesh you are talking about N**2 behavior – so it doesn’t take many nodes to require thousands of BFD sessions.
GIM>> If I understand the scenario correctly, N represents the number of PEs, not the number of routers in ASes. If that is the case, what could be a good estimate for N?

[LES:] Even a modest sized N = 100 (which is certainly not a high number) leads to 10000 BFD sessions. N= 500 => 250,000 sessions. Etc.

In terms of detect time, we are trying to get an order of magnitude improvement from normal BGP session timers – so we are aiming for a modest number of seconds.
GIM>> That is very helpful information, thank you. Then, we can expect that a one-second interval for the transmission of a BFD Control packet would be acceptable and guarantee failure detection within three seconds. If that is the case, I'll note that many platforms support thousands of BFD sessions at 3.3 msec intervals. It appears to me that the case we're discussing produces/processes 330 times fewer BFD packets per session. Should somewhat help with the scaling, would you agree?

[LES:] Nodes which can support thousands of BFD sessions are likely already using many BFD sessions for other purposes. In particular, fast detection of local failures is always going to be a priority – so if a node has thousands of neighbors – it will likely have thousands of single hop BFD sessions. Not to mention the plethora of other OAM uses cases being defined. And the network-wide traffic impact as these new BFD sessions are largely multi-hop. Are you really arguing that the introduction of many thousands of BFD sessions is something we should not be concerned about?
   Les

   Les

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 10, 2022 1:30 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

Best regards,
Greg

   Les

+1

T

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jan 2022 01:30:18 +0100

Hi Les,

*[LES:] Even a modest sized N = 100 (which is certainly not a high number)
> leads to 10000 BFD sessions. N= 500 => 250,000 sessions. Etc.*
>
>
Are you doing N^2 ? Why ? All you need to keep in mind is number of those
sessions per PE so in worst case (N-1) - here 99 and 499.

And as we already established, configuration is optional as you can use
auto config.

Thx,
R.

*[LES:] Nodes which can support thousands of BFD sessions are likely
> already using many BFD sessions for other purposes. In particular, fast
> detection of local failures is always going to be a priority – so if a node
> has thousands of neighbors – it will likely have thousands of single hop
> BFD sessions. Not to mention the plethora of other OAM uses cases being
> defined. And the network-wide traffic impact as these new BFD sessions are
> largely multi-hop. Are you really arguing that the introduction of many
> thousands of BFD sessions is something we should not be concerned about? *
>
> *   Les*
>
>
>
>    Les
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 00:33:53 +0000

Robert –

The numbers are network-wide – not per node.
And no one has mentioned config as an issue in this thread – though no doubt some operators might have concerns in that area.

  Les

From: Robert Raszuk <[email-masked]>
Sent: Monday, January 10, 2022 4:30 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Tony Li <[email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

Are you doing N^2 ? Why ? All you need to keep in mind is number of those sessions per PE so in worst case (N-1) - here 99 and 499.

And as we already established, configuration is optional as you can use auto config.

Thx,
R.

   Les

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 16:43:29 -0800

Les,

> But there are deployments where what he suggested is not possible – largely I think because the set of “prefixes of interest” is in itself large.

Well, the alleged customers have not come forward to explain the situation. I would welcome more specifics, even under NDA. It’s hard to relate to allegations of scale without specifics. If the area has that many PEs in it, then is really too large to be a single area in the first place?

> As far as the alternative proposals, I will comment on them if/when there is something visible – but I think they will all suffer from scale issues.

They have been proposed here and have not been refuted.

Everything always suffers from scale issues, so that’s not exactly constructive.

I would be more than happy to write up the pub-sub proposal, but … it’s not my customer and it’s not in my charter to contribute to your revenue. :)

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jan 2022 01:43:54 +0100

The point I am making is that the total number of BFD sessions in the
entire network is irrelevant.

While looking scary (even if divided by 2) those numbers should not be
even exposed to operators or used as counterargument. What may matter is a
hypothetical scale on a per smallest PE * number of bytes each session
consumes in the control plane. Rest is offloaded to the data plane.

Bottom line is that I prefer to see this problem be addressed in the
service layer - but will defend BFD alternative based on practical view and
facts.

Cheers,
Robert

On Tue, Jan 11, 2022 at 1:34 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> And no one has mentioned config as an issue in this thread – though no
> doubt some operators might have concerns in that area.
>
>
>
>   Les
>
>
>
>
>
> *Sent:* Monday, January 10, 2022 4:30 PM
> *Cc:* Greg Mirsky <[email-masked]>; Tony Li <[email-masked]>;
> Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>;

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 00:44:06 +0000

Some comments from Robert offline cause me to issue a correction.
As BFD sessions are bidirectional we are talking about a Combination of (n,2) – so in the case of 500 nodes the actual number of BFD sessions network-wide is 124750.

   Les

From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, January 10, 2022 4:34 PM
To: Robert Raszuk <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Robert –

  Les

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 10, 2022 4:30 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

Thx,
R.

   Les

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 16:57:09 -0800

> On Jan 10, 2022, at 4:44 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 

Which sounds terrifying until you realize that it’s 499 per node.

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 Jan 2022 17:09:51 -0800

Hi Les,
in this case, using multi-hop BFD will add, in my estimation, 10 Mbyte/sec
of extra traffic if the network is IPv4. Is it a real scaling concern these
days?

Regards,
Greg

On Mon, Jan 10, 2022 at 4:44 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> As BFD sessions are bidirectional we are talking about a Combination of
> (n,2) – so in the case of 500 nodes the actual number of BFD sessions
> network-wide is 124750.
>
>
>
>    Les
>
>
>
>
>
> *From:* Lsr <[email-masked]> *On Behalf Of * Les Ginsberg (ginsberg)
> *Sent:* Monday, January 10, 2022 4:34 PM
> *Cc:* Greg Mirsky <[email-masked]>; Christian Hopps <
> [email-masked]>; Aijun Wang <[email-masked]>; Shraddha
> Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <
> [email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 01:14:11 +0000

Tony –

I could be more specific regarding my opinion about various alternatives that have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to me to comment on proposals which have not actually been defined.
If someone (not necessarily you) wants to write up any of these proposals then we (the WG/Routing Area) could have a meaningful discussion about such alternatives.

In the meantime, we started with the IGPs because:

a)IGPs have the raw reachability info – they don’t have to get it from some other entity
b)IGPs have the reliable flooding mechanism

Given that we want to address a real deployment issue in a timely manner, we want to move forward.

We – meaning the WG/IETF – are tasked with defining practical solutions to real problems. It’s fine to object to a proposal – but that doesn’t get us to a solution.
I am not saying that you specifically are responsible for defining an alternate solution – but if “we” are to progress then we either need to accept an IGP solution or define an alternative.

Now, if you are saying the problem doesn’t need to be solved – then we just disagree.

   Les

Sent: Monday, January 10, 2022 4:43 PM

Les,

Tony

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 Jan 2022 17:28:30 -0800

Hi Les,
do you see anything that requires further specification in addition to RFC
5883?

Regards
Greg

On Mon, Jan 10, 2022, 17:14 Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> Tony –
>
>
>
> I could be more specific regarding my opinion about various alternatives
> that have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make
> sense to me to comment on proposals which have not actually been defined.
>
> If someone (not necessarily you) wants to write up any of these proposals
> then we (the WG/Routing Area) could have a meaningful discussion about such
> alternatives.
>
>
>
> We – meaning the WG/IETF – are tasked with defining practical solutions to
> real problems. It’s fine to object to a proposal – but that doesn’t get us
> to a solution.
>
> I am not saying that you specifically are responsible for defining an
> alternate solution – but if “we” are to progress then we either need to
> accept an IGP solution or define an alternative.
>
>
>
> *Sent:* Monday, January 10, 2022 4:43 PM
> *Cc:* Christian Hopps <[email-masked]>; Peter Psenak (ppsenak) <
> [email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <
> But there are deployments where what he suggested is not possible –
> largely I think because the set of “prefixes of interest” is in itself
> large.
>
>
>
>
>
> Well, the alleged customers have not come forward to explain the
> situation. I would welcome more specifics, even under NDA. It’s hard to
> relate to allegations of scale without specifics. If the area has that many
> PEs in it, then is really too large to be a single area in the first place?
>
>
>
>
>
>  So while not all customers have an issue, some customers do and we are
> trying to find a way to address those deployments.
>
>
>
> As far as the alternative proposals, I will comment on them if/when there
> is something visible – but I think they will all suffer from scale issues.
>
>
>
>
>
> I would be more than happy to write up the pub-sub proposal, but … it’s
> not my customer and it’s not in my charter to contribute to your revenue. :)
>
>
>
> Tony
>
>

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 17:35:06 -0800

Les,

> I could be more specific regarding my opinion about various alternatives that have been mentioned (BFD, OAM, BGP, pub-sub) – but it doesn’t make sense to me to comment on proposals which have not a…

The proposals have been put forth in adequate detail for a preliminary discussion. They appear to be tractable and implementable and thus seem like feasible alternatives.

> Given that we want to address a real deployment issue in a timely manner, we want to move forward.

You want to move forward.  Not the rest of us.

>  We – meaning the WG/IETF – are tasked with defining practical solutions to real problems.

No. Our job is standardizing solutions. We are not tasked with defining them. Proof: you can unilaterally go off and define, implement, and deploy whatever solution you like today. We cannot stop you.  In fact, it’s none of our business.

However, when it comes to standardizing it, that’s when we (the IETF WG) get involved. At that point, the bar is somewhat raised. That’s when you have to convince the rest of us that you have a good solution to the problem.

We are in no rush to move forward with a bad solution. Especially at scale. :-)

> It’s fine to object to a proposal – but that doesn’t get us to a solution.

The problem needs to be solved.  No question. It doesn’t need to be solved with a rush to a bad solution. Architecturally, putting liveness reporting into the IGP is just a bad idea, for all of the reasons that we’ve already articulated, repeatedly. Our arguments have met with stubborn and somewhat disrespectful rejection without clear rationale about why our arguments are incorrect. This does not build consensus.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Jan 2022 20:36:12 -0500

Greg

I believe the scalability context for multi hop BFD is the operational
complexity introduced with the number of sessions especially  within very
large domains with inordinate number of routers. Single hop BFD is more
manageable and is predominately user by operators for underlay failure
detection.  Also in a case where single hop BFD by an operators for failure
detection does that preclude the use of multi hop BFD as well and any
caveats with using both simultaneously.

Kind Regards

Gyan

On Mon, Jan 10, 2022 at 8:28 PM Greg Mirsky <[email-masked]> wrote:

>> We – meaning the WG/IETF – are tasked with defining practical solutions
>> to real problems. It’s fine to object to a proposal – but that doesn’t get
>> us to a solution.
>>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Christian Hopps <[email-masked]>
Date: Mon, 10 Jan 2022 20:43:21 -0500

>> But there are deployments where what he suggested is not possible – largely I think because the set of “prefixes of interest” is in itself large.

maybe isn't saying nearly enough.

"Large" of course is too imprecise. But, more importantly, how do we know that this "large" amount hasn't arisen from bad network design choices.

Thanks,
Chris.
[as wg member]

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 10 Jan 2022 17:50:17 -0800

Hi Gyan,
thank you for sharing the operator's perspective and experience on using
the multi-hop BFD. Thinking of additional challenges, I may add the
authentication of BFD Control packets. But the extra-processing can be
significantly reduced by draft-ietf-bfd-optimizing-authentication-13 -
Optimizing BFD Authentication
<https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/>.
As for using single- and multi-hop BFD sessions simultaneously, that should
not present any problem as each type uses a different assigned destination
UDP port number.

Regards,
Greg

On Mon, Jan 10, 2022 at 5:36 PM Gyan Mishra <[email-masked]> wrote:

>> do you see anything that requires further specification in addition to
>> RFC 5883?
>>
>> Regards
>> Greg
>>
>>> If someone (not necessarily you) wants to write up any of these
>>> proposals then we (the WG/Routing Area) could have a meaningful discussion
>>> about such alternatives.
>>>
>>>
>>>
>>> As far as the alternative proposals, I will comment on them if/when
>>> there is something visible – but I think they will all suffer from scale
>>> issues.
>>>
>>>
>>>
>>>
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 10 Jan 2022 21:15:46 -0500

Hi Greg

Thanks for the reference.

Agreed on the different UDP port 3784 and 4784 to differentiate the single
hop and multi hop sessions respectively.

In the multi hop BFD scenario to monitor the egress PE loopbacks in the
case where an RR exists and all PEs are Route-Reflector Clients, the BFD
multi hop BFD session would monitor PE to RR iBGP peering underlay path,
however how would an ingress PE monitor the liveliness of egress PE.

Also as best practice is to keep the RR out of the forwarding plane not
in-line - off to the side a as the RR is meant to handle control plane only
and not data plane traffic as it maybe on a different lower end  platform
type then the P and PE nodes such as  a NFV VNF VM virtualized box.  So it
would be difficult for the multi hop BFD PE to RR to be able to monitor the
PE to PE LSP forwarding plane failure path.

Kind Regards

Gyan

On Mon, Jan 10, 2022 at 8:50 PM Greg Mirsky <[email-masked]> wrote:

>>>> I could be more specific regarding my opinion about various
>>>> alternatives that have been mentioned (BFD, OAM, BGP, pub-sub) – but it
>>>> doesn’t make sense to me to comment on proposals which have not actually
>>>> been defined.
>>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 02:35:13 +0000

Tony –

Probably too many emails in one day on this – but did want to respond to a few points.
Inline.

Sent: Monday, January 10, 2022 5:35 PM

Les,

[LES:] I believe some of the alternate proposals are tractable – which is not to say that I prefer them.
But I don’t want to ask questions like “How do you do this…?” in the absence of a writeup.  I am assuming that if we had a writeup the authors would have done their best to define a complete solution and then we could meaningfully review and comment. But without a writeup it is hard for me to say – “Oh yes – this is much better. Let’s abandon the IGP approach and go this way.”

[LES:] Agreed – and that is what we are trying to do.

[LES:] We have responded positively to comments about our solution – particularly in the area of scale. (Next version of pulse draft will be out soon – we preferred to enjoy the holidays. 😊)
And I apologize if anything I said was seen as disrespectful. I have tried very hard to confine my responses to technical issues.  We do disagree on some things – but I don’t see that as disrespect.

   Les

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 22:42:41 -0800

Les,

> But I don’t want to ask questions like “How do you do this…?” in the absence of a writeup.  I am assuming that if we had a writeup the authors would have done their best to define a complete soluti…

Well, you’re free to do that of course.  And I’m free to object to your draft.

Here we sit, stuck.

> [LES:] We have responded positively to comments about our solution – particularly in the area of scale. (Next version of pulse draft will be out soon – we preferred to enjoy the holidays. 😊)

No one will begrudge you some recreation. :)

The proposals approach to handling scale issues is to sweep things under the rug, which is very unsatisfying.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jan 2022 10:08:05 +0100

Hi Les,

> then we (the WG/Routing Area) could have a meaningful discussion about such

Since you keep asking for a write up on an alternate solution(s) and since
you clearly stated that your connectivity restoration goals is in seconds
please kindly consider the below solution.

Keep in mind that this solution has shipped around 2003-2004 and is used
all over the world in properly configured networks.

* In an area PEs peer with IBGP sessions to RRs
* RRs are (in vast majority of cases) part of IGP hence hear the same
flooding as would local area ABRs
* RRs deploy next hop tracking hence they can react in an event driven
fashion to PE down events
* RRs then either trigger withdraw or implicit withdraw of service routes
(*1*)
* Those are received only to those ingress PEs who care via RTC filtering

Without doing anything else you get connectivity restoration in seconds
today zero code change, zero protocol extension, zero noise.

(*1*) Now if one would like to further optimize this step it is really easy
to either withdraw all prefixes describing say all routes on the PEs or
simply withdraw previously advertised PE next hop. One message just like
PULSE except without trashing IGP and targeted to those who need it.

I do not see why the optimization (*1*) would not work out of the box. BGP
natively uses recursion so service route can resolve via another BGP route
then via IGP summary.

Hope this helps to understand my suggestion. I also do not see this needs
to be a draft or RFC as this is basic BGP 101.

Cheers,
R.

PS,. I do realize especially after you said that you want to improve the
situation where BGP reacts only after 3 x 60 sec keepalives to trigger
action that some networks may disable next hop validation on RRs. Some may
not even want to run IGP on service RRs. Sure this is ok in some
topologies. But in such cases there are other ways to detect state of local
area PEs on such RRs.

---

From: John E Drake <[email-masked]>
Date: Fri, 14 Jan 2022 16:24:35 +0000

Hi,

Comment inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Monday, January 10, 2022 7:15 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

[External Email. Be cautious of content]

Hi Les,

> You seem focused on the notification delivery mechanism only.

Not really. For me, an advertised summary is like a prefix when you are dialing a country code. Call signaling knows to go north if you are calling a crab shop in Alaska.

That info you need to get over the top as a service. So I am much more in favor to make the service to tell you directly or indirectly that it is available.

[JD]  Right.  Just because a node is up and connected to the network does not imply that a given application is active on it.

Best,
R.

On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Robert -

Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>

Les,

[LES:] It does not seem to me that everyone does agree on that - but I appreciate that you agree.

[LES:] As far as forwarding, as Peter has indicated, we have a POC and it works fine. And there are many possible ways for implementations to go.
It may or may not require 100% software upgrade - but I agree a significant number of nodes have to be upgraded to at least support pulse flooding.

   Les

Many thx,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 06:52:43 +0800

Hi, John:
Please note if the node is down, the service will not be accessed.
We are discussing the “DOWN” notification, not the “UP” notification.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 00:25, John E Drake <jdrake=[email-masked]> wrote:
> 
> 
> Hi,
>  
> Comment inline below.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) <[email-masked]> wrote:
> Robert -
>

---

From: John E Drake <[email-masked]>
Date: Sat, 15 Jan 2022 00:29:47 +0000

Correct, but as Tony, Robert and I have noted, a node being up does not mean that an application on that node is up, which means that your proposed solution is probably a solution to the wrong problem.  Further, Robert’s solution is probably a solution to the right problem.

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Friday, January 14, 2022 5:53 PM
To: John E Drake <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi, John:

On Jan 15, 2022, at 00:25, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Hi,

Comment inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Monday, January 10, 2022 7:15 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Christian Hopps <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Les,

Best,
R.

Les,

   Les

Many thx,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 08:40:23 +0800

When the node is up, all the following process are passed to the application layer. This is the normal procedures of the IGP should do.
According to your logic, IGP are solving the wrong problem now?

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:30, John E Drake <jdrake=[email-masked]> wrote:
> 
>

---

From: John E Drake <[email-masked]>
Date: Sat, 15 Jan 2022 00:47:33 +0000

I don’t think so.  Today things just work, at a given time scale.  What you said you are trying to do is reduce the time scale for detecting that an application on a node has failed.  However, conflating the health of a node with the health of an application on that node seems to be inherently flawed.

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Friday, January 14, 2022 7:40 PM
To: John E Drake <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Robert Raszuk <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

On Jan 15, 2022, at 08:30, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 14, 2022 5:53 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Hannes Gredler <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi, John:

Hi,

Comment inline below.

Yours Irrespectively,

John

Hi Les,

Best,
R.

Les,

   Les

Many thx,
Robert

---

From: Christian Hopps <[email-masked]>
Date: Fri, 14 Jan 2022 19:56:09 -0500

Indeed, and in fact the IGP should only be dealing with the reachability to the node, not with the node or applications liveness.

Thanks,
Chris.
[as wg member]

> On Jan 14, 2022, at 7:47 PM, John E Drake <[email-masked]> wrote:
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 09:06:25 +0800

Hi, Christian and John:

No. I think you all may misunderstand the proposal. What we are detecting is actually the reachability/liveness of node that connected to the application, not the application itself.
And, I think the node liveness is same as the node reachability. They will all influence or break the path to their connected service if their forwarding function is failed.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:56, Christian Hopps <[email-masked]> wrote:
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 14 Jan 2022 20:25:06 -0500

I understand the proposal. As I've stated elsewhere, I do not believe there is a problem here that needs solving. The "problem" was created by the user by summarizing prefixes that should not have been summarized -- they mis-configured their network. The routing protocols works just fine (act very quickly) if you don't incorrectly summarize "really important prefixes".

I was simply pointing out that IGPs also don't deal in liveness since that keeps coming up.

Thanks,
Chris.

> On Jan 14, 2022, at 8:06 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Christian and John:
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 14 Jan 2022 20:26:09 -0500

> On Jan 14, 2022, at 8:25 PM, Christian Hopps <[email-masked]> wrote:
> 

Sorry that was "as wg member".

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 09:50:19 +0800

Hi, Christian:

We should consider the balance and efficiency for the summary or not summary.
If you don’t summary, then all the areas will be filled with the specified detail routes(all PE’s loopback, may also include all P’s loopback). This can certainly increase the burden of the routers. 

But with summary, all these specific routes need not exist in the routing table. The nodes within the IGP need only be notified when one node is failure to accelerate the switchover of the overlay service. 
And, you can also select to not using such mechanism, then the service will be backhole for some time until the service/application find this abnormal phenomenon.
PUA/PULSE are just the mechanism to reduce the abnormal durations, it is one kind of FRR technique.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 09:26, Christian Hopps <[email-masked]> wrote:
> 
> 
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 14 Jan 2022 21:06:50 -0500

Yes, having worked intimately with these IGPs for > 20 years now, I understand the use and the implications of using summary routes. :)

My opinion remains unchanged.

Thanks,
Chris.
[as wg member]

> On Jan 14, 2022, at 8:50 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Christian:
>

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 24 Jan 2022 10:38:40 +0800

Hi, Christian, Acee:

It seems that experts within LSR can't converged to one standard solutions, then how about we forward them also into experimental track, and let the implementation and market to select/determine?
With the experimental deployment experiences, we can get the most suitable solutions.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Christian Hopps
Sent: Saturday, January 15, 2022 10:07 AM
To: Aijun Wang <[email-masked]>
Cc: John E Drake <[email-masked]>; Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Thanks,
Chris.
[as wg member]

---

From: Christian Hopps <[email-masked]>
Date: Sun, 23 Jan 2022 22:48:17 -0500

[This is with my chair hat on; however, I am not making any actually calls on rough consensus as that would come from both Acee and I after we have discussed things and come to an agreement]

First: Just because people are disagreeing doesn't mean that we accept failure in this WG and start "standardizing" multiple solutions to everything. As a group we will discuss things and then the WG chairs will make a call on whether we have rough consensus or *not*.

The recent acceptance of multiple experimental track drafts was borderline a (big) mistake, and one huge negative against doing it was that someone was inevitably going suggest we do it the next time they wanted to get their draft published when there was any sort of contention over solutions.

Our job as a WG is not to publish RFCs simply because people write drafts. It's to produce standards for solutions (*) to problems (*) that need fixing (*).

As a WG we have to decide if (*) {is good enough, that actually exist, are worth trying to fix}. The chairs have to decide if the WG has reached at least a rough consensus on all of the (*)s, and if not, we simply do not move forward with that work.

Not getting agreement from a bunch of experts in the WG basically means the work is not going to move forward.

Thanks,
Chris.
[As WG chair]

"Aijun Wang" <[email-masked]> writes:

> Hi, Christian, Acee:
>
> It seems that experts within LSR can't converged to one standard solutions, then
> how about we forward them also into experimental track, and let the
> implementation and market to select/determine?
> Cc: John E Drake <[email-masked]>; Robert Raszuk <[email-masked]>; Les
> Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>;
> Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler
> <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>
>> If you don’t summary, then all the areas will be filled with the specified
>> detail routes(all PE’s loopback, may also include all P’s loopback). This can
>> certainly increase the burden of the routers.
>>
>> But with summary, all these specific routes need not exist in the routing
>> table. The nodes within the IGP need only be notified when one node is failure
>> to accelerate the switchover of the overlay service.
>>>> I understand the proposal. As I've stated elsewhere, I do not believe there
>>>> is a problem here that needs solving. The "problem" was created by the user
>>>> by summarizing prefixes that should not have been summarized -- they
>>>> mis-configured their network. The routing protocols works just fine (act
>>>> very quickly) if you don't incorrectly summarize "really important
>>>> prefixes".
>>>>
>>>>>>> I don’t think so. Today things just work, at a given time scale. What you
>>>>>>> said you are trying to do is reduce the time scale for detecting that an
>>>>>>> application on a node has failed. However, conflating the health of a
>>>>>>> node with the health of an application on that node seems to be
>>>>>>> inherently flawed.
>>>>>>>
>>>>>>> Yours Irrespectively,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Robert Raszuk
>>>>>>> <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde
>>>>>>> <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler
>>>>>>> <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak)
>>>>>>> <[email-masked]>
>>>>>>> Correct, but as Tony, Robert and I have noted, a node being up does not
>>>>>>> mean that an application on that node is up, which means that your
>>>>>>> proposed solution is probably a solution to the wrong problem. Further,
>>>>>>> Robert’s solution is probably a solution to the right problem.
>>>>>>>
>>>>>>> Yours Irrespectively,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg)
>>>>>>> <[email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde
>>>>>>> <[email-masked]>; Tony Li <[email-masked]>; Hannes Gredler
>>>>>>> <[email-masked]>; lsr <[email-masked]>; Peter Psenak (ppsenak)
>>>>>>> <[email-masked]>
>>>>>>> Cc: Christian Hopps <[email-masked]>; Aijun Wang
>>>>>>> <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
>>>>>>> Cc: Tony Li <[email-masked]>; Christian Hopps <[email-masked]>; Peter
>>>>>>> Psenak (ppsenak) <[email-masked]>; Shraddha Hegde
>>>>>>> <[email-masked]>; Aijun Wang <[email-masked]>; Hannes
>>>>>>> But do they realize that to practically employ what you are proposing
>>>>>>> (new PDU flooding) requires 100% software upgrade to all IGP nodes in the
>>>>>>> entire network ? Do they also realize that to effectively use it requires
>>>>>>> data plane change (sure software but data plane code is not as simple as
>>>>>>> PI) on all ingress PEs ?
>>>>>>>
>>>>>>> 1000s of nodes (if not more). That's massive if compared to alternative
>>>>>>> approaches to achieve the same or even better results.
>>>>>>>
>>>>>>> I think what is overlooked in the discussion of other solutions is that
>>>>>>> scale?

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 23 Jan 2022 23:42:39 -0500

Hi Chris

Just about every vendor out there recommended best practice is to layout
address plan to take advantage of summarization wherever possible and that
as well includes PE loopback next hop attribute to limit the router load as
well as size of LSDB in the backbone as well as domain wide.

I think you would be hard pressed to find any vendor that would say go
ahead and flood loopbacks domain wide and don’t summarize.

In large domains flooding domain wide is not feasible and summarization is
requirement even for the critical loopback BGP next hops for most operators.

RFC 5302 talks about the ramifications of flooding in ISIS domain in
section 1.2 excerpt below:

1.2 <https://datatracker.ietf.org/doc/html/rfc5302#section-1.2>.  Scalability

   The disadvantage to performing the domain-wide prefix distribution
   described above is that it has an impact on the scalability of IS-IS.
   Areas within IS-IS help scalability in that LSPs are contained within
   a single area.  This limits the size of the link state database,
   which in turn limits the complexity of the shortest path computation.

   Further, the summarization of the prefix information aids scalability
   in that the abstraction of the prefix information removes the sheer
   number of data items to be transported and the number of routes to be
   computed.

   It should be noted quite strongly that the distribution of prefixes
   on a domain-wide basis impacts the scalability of IS-IS in the second
   respect.  It will increase the number of prefixes throughout the
   domain.  This will result in increased memory consumption,
   transmission requirements, and computation requirements throughout
   the domain.

   It must also be noted that the domain-wide distribution of prefixes
   has no effect whatsoever on the first aspect of scalability, namely
   the existence of areas and the limitation of the distribution of the
   link state database.

Gyan
On Fri, Jan 14, 2022 at 9:07 PM Christian Hopps <[email-masked]> wrote:

> Yes, having worked intimately with these IGPs for > 20 years now, I
> understand the use and the implications of using summary routes. :)
>
> > If you don’t summary, then all the areas will be filled with the
> specified detail routes(all PE’s loopback, may also include all P’s
> loopback). This can certainly increase the burden of the routers.
> >
> > But with summary, all these specific routes need not exist in the
> routing table. The nodes within the IGP need only be notified when one node
> is failure to accelerate the switchover of the overlay service.
> > And, you can also select to not using such mechanism, then the service
> will be backhole for some time until the service/application find this
> abnormal phenomenon.
> >>> I understand the proposal. As I've stated elsewhere, I do not believe
> there is a problem here that needs solving. The "problem" was created by
> the user by summarizing prefixes that should not have been summarized --
> they mis-configured their network. The routing protocols works just fine
> (act very quickly) if you don't incorrectly summarize "really important
> prefixes".
> >>>
> >>>> No. I think you all may misunderstand the proposal. What we are
> detecting is actually the reachability/liveness of node that connected to
> the application, not the application itself.
> >>>> And, I think the node liveness is same as the node reachability. They
> will all influence or break the path to their connected service if their
> forwarding function is failed.
> >>>>
> >>>> Aijun Wang
> >>>> China Telecom
> >>>>
> >>>>> Indeed, and in fact the IGP should only be dealing with the
> reachability to the node, not with the node or applications liveness.
> >>>>>
> >>>>> Thanks,
> >>>>> Chris.
> >>>>> [as wg member]
> >>>>>
> >>>>>> I don’t think so.  Today things just work, at a given time scale.
> What you said you are trying to do is reduce the time scale for detecting
> that an application on a node has failed.  However, conflating the health
> of a node with the health of an application on that node seems to be
> inherently flawed.
> >>>>>>
> >>>>>> Yours Irrespectively,
> >>>>>>
> >>>>>> John
> >>>>>>
> >>>>>>
> >>>>>> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Robert Raszuk <
> [email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <
> [email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <
> >>>>>> When the node is up, all the following process are passed to the
> application layer. This is the normal procedures of the IGP should do.
> >>>>>> Correct, but as Tony, Robert and I have noted, a node being up does
> not mean that an application on that node is up, which means that your
> >>>>>> Cc: Robert Raszuk <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Christian Hopps <[email-masked]>; Shraddha Hegde <
> [email-masked]>; Tony Li <[email-masked]>; Hannes Gredler <
> >>>>>> Cc: Christian Hopps <[email-masked]>; Aijun Wang <
> [email-masked]>; Peter Psenak (ppsenak) <[email-masked]>
> >>>>>> Not really. For me, an advertised summary is like a prefix when you
> are dialing a country code. Call signaling knows to go north if you are
> calling a crab shop in Alaska.
> >>>>>>
> >>>>>> That info you need to get over the top as a service. So I am much
> more in favor to make the service to tell you directly or indirectly that
> it is available.
> >>>>>>
> >>>>>> [JD]  Right.  Just because a node is up and connected to the
> network does not imply that a given application is active on it.
> >>>>>>
> >>>>>> Best,
> >>>>>> R.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Cc: Tony Li <[email-masked]>; Christian Hopps <[email-masked]>;
> >>>>>> We have received requests from real customers who both need to
> summarize AND would like better response time to loss of reachability to
> individual nodes.
> >>>>>>
> >>>>>> But do they realize that to practically employ what you are
> proposing (new PDU flooding) requires 100% software upgrade to all IGP
> nodes in the entire network ? Do they also realize that to effectively use
> it requires data plane change (sure software but data plane code is not as
> simple as PI) on all ingress PEs ?
> >>>>>>
> >>>>>> [LES:] As far as forwarding, as Peter has indicated, we have a POC
> and it works fine. And there are many possible ways for implementations to
> go.
> >>>>>> It may or may not require 100% software upgrade – but I agree a
> flooding.
> >>>>>> And with scale requirements you are describing it seems this would
> be 1000s of nodes (if not more). That's massive if compared to alternative
> >>>>>> I think what is overlooked in the discussion of other solutions is
> that reachability info is provided by the IGP. If all the IGP advertises is
> a summary then how would individual loss of reachability become known at
> scale?
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Christian Hopps <[email-masked]>
Date: Mon, 24 Jan 2022 00:50:15 -0500

Ok, I guess I'll repeat what I said, as I don't believe anything new was presented here.

    Yes, having worked intimately with these IGPs for > 20 years now,
    I understand the use and the implications of using summary
    routes. :)

"If a prefix is important enough to consider seriously hacking the routing protocol to signal the prefix being unreachable, then that prefix is important enough to not summarize to begin with." IOW; KISS

I'd prefer to not keep repeating this when presented with the same arguments, so please take any silence on my part as my opinion being unchanged.

Thanks,
Chris.
[As WG member]

Gyan Mishra <[email-masked]> writes:

> Hi Chris 
>
>
> Just about every vendor out there recommended best practice is to
> layout address plan to take advantage of summarization wherever
> possible and that as well includes PE loopback next hop attribute to
> limit the router load as well as size of LSDB in the backbone as well
> as domain wide.  
>
> I think you would be hard pressed to find any vendor that would say
> go ahead and flood loopbacks domain wide and don’t summarize.
>
> In large domains flooding domain wide is not feasible and
> summarization is requirement even for the critical loopback BGP next
> hops for most operators.
>
> 1.2.  Scalability
>     Yes, having worked intimately with these IGPs for > 20 years now,
>     I understand the use and the implications of using summary
>     routes. :)
>
>     > If you don’t summary, then all the areas will be filled with
>     the specified detail routes(all PE’s loopback, may also include
>     all P’s loopback). This can certainly increase the burden of the
>     routers.
>     >
>     > But with summary, all these specific routes need not exist in
>     the routing table. The nodes within the IGP need only be notified
>     when one node is failure to accelerate the switchover of the
>     overlay service.
>     > And, you can also select to not using such mechanism, then the
>     service will be backhole for some time until the service/
>     application find this abnormal phenomenon.
>     > PUA/PULSE are just the mechanism to reduce the abnormal
>     durations, it is one kind of FRR technique.
>     >
>     > Aijun Wang
>     > China Telecom
>     >
>     >>> I understand the proposal. As I've stated elsewhere, I do not
>     believe there is a problem here that needs solving. The "problem"
>     was created by the user by summarizing prefixes that should not
>     have been summarized -- they mis-configured their network. The
>     routing protocols works just fine (act very quickly) if you don't
>     incorrectly summarize "really important prefixes".
>     >>>
>     >>>> No. I think you all may misunderstand the proposal. What we
>     are detecting is actually the reachability/liveness of node that
>     connected to the application, not the application itself.
>     >>>> And, I think the node liveness is same as the node
>     reachability. They will all influence or break the path to their
>     connected service if their forwarding function is failed.
>     >>>>
>     >>>> Aijun Wang
>     >>>> China Telecom
>     >>>>
>     >>>>>> I don’t think so.  Today things just work, at a given time
>     scale.  What you said you are trying to do is reduce the time
>     scale for detecting that an application on a node has failed. 
>     However, conflating the health of a node with the health of an
>     application on that node seems to be inherently flawed.   
>     >>>>>>
>     >>>>>> Yours Irrespectively,
>     >>>>>>
>     >>>>>> John
>     >>>>>>
>     >>>>>>
>     >>>>>> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Robert
>     Raszuk <[email-masked]>; Christian Hopps <[email-masked]>;
>     Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>;
>     Hannes Gredler <[email-masked]>; lsr <[email-masked]>; Peter
>     Psenak (ppsenak) <[email-masked]>
>     >>>>>> When the node is up, all the following process are passed
>     to the application layer. This is the normal procedures of the
>     IGP should do.
>     >>>>>> Correct, but as Tony, Robert and I have noted, a node
>     being up does not mean that an application on that node is up,
>     which means that your proposed solution is probably a solution to
>     the wrong problem.  Further, Robert’s solution is probably a
>     solution to the right problem.
>     >>>>>>
>     >>>>>> Yours Irrespectively,
>     >>>>>>
>     >>>>>> John
>     >>>>>>
>     >>>>>>
>     >>>>>> Cc: Robert Raszuk <[email-masked]>; Les Ginsberg
>     (ginsberg) <[email-masked]>; Christian Hopps <
>     [email-masked]>; Shraddha Hegde <[email-masked]>; Tony
>     [email-masked]>; Shraddha Hegde <[email-masked]
>     >; Tony Li <[email-masked]>; Hannes Gredler <[email-masked]>;
>     >>>>>> Not really. For me, an advertised summary is like a prefix
>     when you are dialing a country code. Call signaling knows to go
>     north if you are calling a crab shop in Alaska.
>     >>>>>>
>     >>>>>> That info you need to get over the top as a service. So I
>     am much more in favor to make the service to tell you directly or
>     indirectly that it is available.
>     >>>>>>
>     >>>>>> [JD]  Right.  Just because a node is up and connected to
>     the network does not imply that a given application is active on
>     it.
>     >>>>>>
>     >>>>>> Best,
>     >>>>>> R.
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>>
>     >>>>>> Cc: Tony Li <[email-masked]>; Christian Hopps <
>     [email-masked]>; Peter Psenak (ppsenak) <[email-masked]>;
>     Shraddha Hegde <[email-masked]>; Aijun Wang <
>     [email-masked]>; Hannes Gredler <[email-masked]>;
>     lsr <[email-masked]>
>     >>>>>> We have received requests from real customers who both
>     need to summarize AND would like better response time to loss of
>     reachability to individual nodes.
>     >>>>>>
>     >>>>>> But do they realize that to practically employ what you
>     are proposing (new PDU flooding) requires 100% software upgrade
>     to all IGP nodes in the entire network ? Do they also realize
>     that to effectively use it requires data plane change (sure
>     software but data plane code is not as simple as PI) on all
>     ingress PEs ?
>     >>>>>>
>     >>>>>> [LES:] As far as forwarding, as Peter has indicated, we
>     have a POC and it works fine. And there are many possible ways
>     for implementations to go.
>     >>>>>> It may or may not require 100% software upgrade – but I
>     agree a significant number of nodes have to be upgraded to at
>     least support pulse flooding.
>     >>>>>>
>     >>>>>>
>     >>>>>> And with scale requirements you are describing it seems
>     this would be 1000s of nodes (if not more). That's massive if
>     compared to alternative approaches to achieve the same or even
>     better results.
>     >>>>>>
>     >>>>>> I think what is overlooked in the discussion of other
>     solutions is that reachability info is provided by the IGP. If
>     all the IGP advertises is a summary then how would individual
>     loss of reachability become known at scale?

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 24 Jan 2022 17:16:00 +0800

Hi, Chris:
We should notice here that it is not "a prefix", it's possible for "all node's loopback address, or even some link's address".
Gyan's reference for RFC5302 state clearly the disadvantage of non-summarization, and the operators have followed this approach also about 20 years, then you just propose to divert to another direction?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Monday, January 24, 2022 1:50 PM
To: Gyan Mishra <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>; Hannes Gredler <[email-masked]>; John E Drake <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Thanks,
Chris.
[As WG member]

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 24 Jan 2022 17:18:17 +0800

Hi, Christian:

OK, let's try to converge into one standard. But it should be IGP based, or else should be discussed by other WG.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Monday, January 24, 2022 11:48 AM
To: Aijun Wang <[email-masked]>
Cc: 'Christian Hopps' <[email-masked]>; [email-masked]; 'John E Drake' <[email-masked]>; 'Robert Raszuk' <[email-masked]>; 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Shraddha Hegde' <[email-masked]>; 'Tony Li' <[email-masked]>; 'Hannes Gredler' <[email-masked]>; 'lsr' <[email-masked]>; 'Peter Psenak (ppsenak)' <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Thanks,
Chris.
[As WG chair]

"Aijun Wang" <[email-masked]> writes:

> Hi, Christian, Acee:
>
> It seems that experts within LSR can't converged to one standard 
> solutions, then how about we forward them also into experimental 
> track, and let the implementation and market to select/determine?
> Cc: John E Drake <[email-masked]>; Robert Raszuk 
> <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; 
> Christian Hopps <[email-masked]>; Shraddha Hegde 
>> routing table. The nodes within the IGP need only be notified when 
>> one node is failure to accelerate the switchover of the overlay service.
>>>>>>> What you said you are trying to do is reduce the time scale for 
>>>>>>> detecting that an application on a node has failed. However, 
>>>>>>> conflating the health of a node with the health of an 
>>>>>>> <[email-masked]>; Christian Hopps <[email-masked]>; 
>>>>>>> Shraddha Hegde <[email-masked]>; Tony Li 
>>>>>>> <[email-masked]>; Hannes Gredler <[email-masked]>; lsr 
>>>>>>> Correct, but as Tony, Robert and I have noted, a node being up 
>>>>>>> does not mean that an application on that node is up, which 
>>>>>>> means that your proposed solution is probably a solution to the 
>>>>>>> wrong problem. Further, Robert’s solution is probably a solution to the right problem.
>>>>>>>
>>>>>>> Yours Irrespectively,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>
>>>>>>> <[email-masked]>; Christian Hopps <[email-masked]>; 
>>>>>>> Shraddha Hegde <[email-masked]>; Tony Li 
>>>>>>> <[email-masked]>; Hannes Gredler <[email-masked]>; lsr 
>>>>>>> <[email-masked]>; Shraddha Hegde 
>>>>>>> <[email-masked]>; Tony Li <[email-masked]>; Hannes 
>>>>>>> Gredler <[email-masked]>; lsr <[email-masked]>; Peter Psenak 
>>>>>>> (ppsenak) <[email-masked]>
>>>>>>> Cc: Tony Li <[email-masked]>; Christian Hopps 
>>>>>>> <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; 
>>>>>>> Shraddha Hegde <[email-masked]>; Aijun Wang 
>>>>>>> <[email-masked]>; Hannes Gredler <[email-masked]>; 
>>>>>>> lsr <[email-masked]>
>>>>>>> proposing (new PDU flooding) requires 100% software upgrade to 
>>>>>>> all IGP nodes in the entire network ? Do they also realize that 
>>>>>>> to effectively use it requires data plane change (sure software 
>>>>>>> but data plane code is not as simple as
>>>>>>> PI) on all ingress PEs ?
>>>>>>>
>>>>>>> And with scale requirements you are describing it seems this 
>>>>>>> would be 1000s of nodes (if not more). That's massive if 
>>>>>>> compared to alternative approaches to achieve the same or even better results.
>>>>>>>
>>>>>>> I think what is overlooked in the discussion of other solutions 
>>>>>>> is that reachability info is provided by the IGP. If all the IGP 
>>>>>>> advertises is a summary then how would individual loss of 
>>>>>>> reachability become known at scale?

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Jan 2022 10:27:59 +0100

Aijun,

> and the operators have followed this approach also about 20 years

For the record that assertion is just not true.

Most operators for over 20 years run MPLS encapsulation and with that they
are already leaking *all* loopbacks of the edge nodes domain wide. None of
the networks have issues to handle that.

See IGP scaling limits do not really reach ceiling based on number of
prefixes, but based on network stability.

Only RFC5283 brought the ability to summarize and replace LDP FEC
exact match to the longest match, but not many operators moved since their
original deployments there.

SR-MPLS also requires leaking domain wide.

So this is not like Chris is advocating some revolution here.

Said all of the above, I love inter-area summarization and I do agree that
it is a good thing. But let's keep the arguments honest - that's the point.

Cheers,
R.

On Mon, Jan 24, 2022 at 10:16 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Chris:
> We should notice here that it is not "a prefix", it's possible for "all
> node's loopback address, or even some link's address".
> Gyan's reference for RFC5302 state clearly the disadvantage of
> non-summarization, and the operators have followed this approach also about
> 20 years, then you just propose to divert to another direction?
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> [email-masked]>; Hannes Gredler <[email-masked]>; John E
> Drake <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>;
> Peter Psenak (ppsenak) <[email-masked]>; Robert Raszuk <
> [email-masked]>; Shraddha Hegde <[email-masked]>; Tony Li <
> [email-masked]>; lsr <[email-masked]>
> "If a prefix is important enough to consider seriously hacking the routing
> protocol to signal the prefix being unreachable, then that prefix is
> important enough to not summarize to begin with." IOW; KISS
>
> I'd prefer to not keep repeating this when presented with the same
> arguments, so please take any silence on my part as my opinion being
> unchanged.
>
> Thanks,
> Chris.
> [As WG member]
>
>
>

---

From: Christian Hopps <[email-masked]>
Date: Mon, 24 Jan 2022 04:29:53 -0500

"Aijun Wang" <[email-masked]> writes:

> non-summarization, and the operators have followed this approach also about 20
> years, then you just propose to divert to another direction?
>

For 20 years we haven't needed PUA/PULSE, now your saying we do, so I'm saying don't use summarization *for these special prefixes it suddenly doesn't work for*.

I have *never* said do not use summarization. I've have tried very hard to say very clearly "for those special prefixes" every time I have responded to this thread. It's very frustrating.

I'm saying do not summarize these "super important prefixes" -- these prefixes you want to modify the summarization process because summarization doens't work for them"

Again KISS applies here:

      If the summarization process *doesn't work* for a given prefix P, then *don't use summarization* for prefix P!

Thanks,
Chris.
[As wg member]

> Cc: Christian Hopps <[email-masked]>; Aijun Wang <[email-masked]>;
> Hannes Gredler <[email-masked]>; John E Drake <[email-masked]>; Les
> Ginsberg (ginsberg) <[email-masked]>; Peter Psenak (ppsenak)
> <[email-masked]>; Robert Raszuk <[email-masked]>; Shraddha Hegde
> <[email-masked]>; Tony Li <[email-masked]>; lsr <[email-masked]>
> protocol to signal the prefix being unreachable, then that prefix is important
> enough to not summarize to begin with." IOW; KISS
>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 24 Jan 2022 10:40:30 +0100

> ahead and flood loopbacks domain wide and don’t summarize.

it's actually not unheard off @ all (flood loopbacks flat). and with node
SID it's almost a must if you want SR without lots of reinventing of
seamless MPLS ...

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Jan 2022 10:57:28 +0100

Chris,

I would like to state one important point ...

Some folks used terms "for those special prefixes" or  "super important
prefixes"  only to smooth the discussion. But  there is not such a thing.
All what is being discussed is all PEs. Some want to also add SR segment
endpoints.

No one will be selecting a subset of the above. That's even more drastic
for the PUA/PULSE approach as it inherently contains a cliff effect.

Thx,
R.

On Mon, Jan 24, 2022 at 10:40 AM Christian Hopps <[email-masked]> wrote:

> For 20 years we haven't needed PUA/PULSE, now your saying we do, so I'm
> saying don't use summarization *for these special prefixes it suddenly
> doesn't work for*.
>
> I have *never* said do not use summarization. I've have tried very hard to
> say very clearly "for those special prefixes" every time I have responded
> to this thread. It's very frustrating.
>
> I'm saying do not summarize these "super important prefixes" -- these
> prefixes you want to modify the summarization process because summarization
> doens't work for them"
>
> Again KISS applies here:
>
>       If the summarization process *doesn't work* for a given prefix P,
> then *don't use summarization* for prefix P!
>
> Thanks,
> Chris.
> [As wg member]
>
> > Best Regards
> >
> > Aijun Wang
> > China Telecom
> >
> [email-masked]>;
> important

---

From: Christian Hopps <[email-masked]>
Date: Mon, 24 Jan 2022 05:24:46 -0500

Robert Raszuk <[email-masked]> writes:

> Some folks used terms "for those special prefixes" or  "super
> important prefixes"  only to smooth the discussion. But  there is not
> such a thing. All what is being discussed is all PEs. Some want to
> also add SR segment endpoints. 
>
> No one will be selecting a subset of the above. That's even more
> drastic for the PUA/PULSE approach as it inherently contains a cliff
> effect. 

There are plenty more prefixes in an IGP domain than just PE loopbacks. For example, all the internal networks, and those are great candidates for summarization.

We've been calling out these "important prefixes" for quite a while (and w/o the need for summarization) -- this is why we added admin tags way back when, to be able to identify "important" prefixes so e.g., routers could give them higher priority for insertion in their FIB, etc..

Thanks,
Chris.

>     > We should notice here that it is not "a prefix", it's possible
>     for "all node's loopback address, or even some link's address".
>     For 20 years we haven't needed PUA/PULSE, now your saying we do,
>     so I'm saying don't use summarization *for these special prefixes
>     it suddenly doesn't work for*.
>
>     I have *never* said do not use summarization. I've have tried
>     very hard to say very clearly "for those special prefixes" every
>     time I have responded to this thread. It's very frustrating.
>
>     I'm saying do not summarize these "super important prefixes" --
>     these prefixes you want to modify the summarization process
>     because summarization doens't work for them"
>
>     Again KISS applies here:
>
>           If the summarization process *doesn't work* for a given
>     prefix P, then *don't use summarization* for prefix P!
>
>     Thanks,
>     Chris.
>     [As wg member]
>
>     > Best Regards
>     >
>     > Aijun Wang
>     > China Telecom
>     >
>     > I'd prefer to not keep repeating this when presented with the
>     same arguments, so please take any silence on my part as my
>     opinion being unchanged.
>     >
>     > Thanks,
>     > Chris.
>     > [As WG member]
>     >
>     >
>     >
>     >> On Fri, Jan 14, 2022 at 9:07 PM Christian Hopps <
>     [email-masked]>
>     >> wrote:
>     >>
>     >>     > On Jan 14, 2022, at 8:50 PM, Aijun Wang <
>     >>     [email-masked]> wrote:
>     >>     >
>     >>     > Hi, Christian:
>     >>     >
>     >>     > We should consider the balance and efficiency for the
>     summary
>     >>     or not summary.
>     >>     > If you don’t summary, then all the areas will be filled
>     with
>     >>     > But with summary, all these specific routes need not
>     exist in
>     >>     > And, you can also select to not using such mechanism,
>     then the
>     >>     > PUA/PULSE are just the mechanism to reduce the abnormal
>     >>     > Aijun Wang
>     >>     > China Telecom
>     >>     >> On Jan 15, 2022, at 09:26, Christian Hopps <
>     [email-masked]>
>     >>     wrote:
>     >>     >>
>     >>     >>
>     >>     >>
>     >>     >>> On Jan 14, 2022, at 8:25 PM, Christian Hopps <
>     >>     [email-masked]> wrote:
>     >>     >>>
>     >>     >>> I understand the proposal. As I've stated elsewhere, I
>     do not
>     >>     >>> I was simply pointing out that IGPs also don't deal in
>     >>     liveness since that keeps coming up.
>     >>     >>
>     >>     >> Sorry that was "as wg member".
>     >>     >>
>     >>     >>>
>     >>     >>> Thanks,
>     >>     >>> Chris.
>     >>     >>>
>     >>     >>>>> On Jan 14, 2022, at 8:06 PM, Aijun Wang <
>     >>     [email-masked]> wrote:
>     >>     >>>>
>     >>     >>>> Hi, Christian and John:
>     >>     >>>>
>     >>     >>>> No. I think you all may misunderstand the proposal.
>     What we
>     >>     >>>> And, I think the node liveness is same as the node
>     >>     >>>> Aijun Wang
>     >>     >>>> China Telecom
>     >>     >>>>> On Jan 15, 2022, at 08:56, Christian Hopps <
>     >>     [email-masked]> wrote:
>     >>     >>>>>
>     >>     >>>>> Indeed, and in fact the IGP should only be dealing
>     with the
>     >>     reachability to the node, not with the node or
>     applications
>     >>     liveness.
>     >>     >>>>>
>     >>     >>>>> Thanks,
>     >>     >>>>> Chris.
>     >>     >>>>> [as wg member]
>     >>     >>>>>
>     >>     >>>>>> On Jan 14, 2022, at 7:47 PM, John E Drake <
>     >>     [email-masked]> wrote:
>     >>     >>>>>>
>     >>     >>>>>> I don’t think so.  Today things just work, at a
>     given time
>     >>     >>>>>>
>     >>     >>>>>> Yours Irrespectively,
>     >>     >>>>>>
>     >>     >>>>>> John
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> Juniper Business Use Only
>     >>     >>>>>> From: Aijun Wang <[email-masked]>
>     >>     >>>>>> Sent: Friday, January 14, 2022 7:40 PM
>     >>     >>>>>> To: John E Drake <[email-masked]>
>     >>     >>>>>> Cc: Les Ginsberg (ginsberg) <[email-masked]>;
>     Robert
>     >>     >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE
>     >>     >>>>>>
>     >>     >>>>>> [External Email. Be cautious of content]
>     >>     >>>>>>
>     >>     >>>>>> When the node is up, all the following process are
>     passed
>     >>     >>>>>> According to your logic, IGP are solving the wrong
>     problem
>     >>     now?
>     >>     >>>>>>
>     >>     >>>>>> Aijun Wang
>     >>     >>>>>> China Telecom
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> On Jan 15, 2022, at 08:30, John E Drake <jdrake=
>     >>     [email-masked]> wrote:
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> Correct, but as Tony, Robert and I have noted, a
>     node
>     >>     >>>>>>
>     >>     >>>>>> Yours Irrespectively,
>     >>     >>>>>>
>     >>     >>>>>> John
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> Juniper Business Use Only
>     >>     >>>>>> From: Aijun Wang <[email-masked]>
>     >>     >>>>>> Sent: Friday, January 14, 2022 5:53 PM
>     >>     >>>>>> To: John E Drake <[email-masked]>
>     >>     >>>>>> Cc: Robert Raszuk <[email-masked]>; Les Ginsberg
>     >>     >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE
>     >>     >>>>>>
>     >>     >>>>>> [External Email. Be cautious of content]
>     >>     >>>>>>
>     >>     >>>>>> Hi, John:
>     >>     >>>>>> Please note if the node is down, the service will
>     not be
>     >>     accessed.
>     >>     >>>>>> We are discussing the “DOWN” notification, not the
>     “UP”
>     >>     notification.
>     >>     >>>>>>
>     >>     >>>>>> Aijun Wang
>     >>     >>>>>> China Telecom
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> On Jan 15, 2022, at 00:25, John E Drake <jdrake=
>     >>     [email-masked]> wrote:
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> Hi,
>     >>     >>>>>>
>     >>     >>>>>> Comment inline below.
>     >>     >>>>>>
>     >>     >>>>>> Yours Irrespectively,
>     >>     >>>>>>
>     >>     >>>>>> John
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> Juniper Business Use Only
>     >>     >>>>>> From: Lsr <[email-masked]> On Behalf Of
>     Robert
>     >>     Raszuk
>     >>     >>>>>> Sent: Monday, January 10, 2022 7:15 PM
>     >>     >>>>>> To: Les Ginsberg (ginsberg) <[email-masked]>
>     >>     >>>>>> Cc: Christian Hopps <[email-masked]>; Aijun Wang
>     <
>     >>     >; Tony Li <[email-masked]>; Hannes Gredler <
>     [email-masked]>;
>     >>     >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE
>     >>     >>>>>>
>     >>     >>>>>> [External Email. Be cautious of content]
>     >>     >>>>>>
>     >>     >>>>>> Hi Les,
>     >>     >>>>>>
>     >>     >>>>>>> You seem focused on the notification delivery
>     mechanism
>     >>     only.
>     >>     >>>>>>
>     >>     >>>>>> Not really. For me, an advertised summary is like a
>     prefix
>     >>     >>>>>>
>     >>     >>>>>> Now such direction does not indicate if the shop is
>     open
>     >>     or has crabs.
>     >>     >>>>>>
>     >>     >>>>>> That info you need to get over the top as a
>     service. So I
>     >>     >>>>>>
>     >>     >>>>>> [JD]  Right.  Just because a node is up and
>     connected to
>     >>     >>>>>>
>     >>     >>>>>> Best,
>     >>     >>>>>> R.
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg
>     (ginsberg) <
>     >>     [email-masked]> wrote:
>     >>     >>>>>> Robert -
>     >>     >>>>>>
>     >>     >>>>>> From: Robert Raszuk <[email-masked]>
>     >>     >>>>>> Sent: Monday, January 10, 2022 2:56 PM
>     >>     >>>>>> To: Les Ginsberg (ginsberg) <[email-masked]>
>     >>     >>>>>> Cc: Tony Li <[email-masked]>; Christian Hopps <
>     >>     >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE
>     >>     >>>>>>
>     >>     >>>>>> Les,
>     >>     >>>>>>
>     >>     >>>>>> We have received requests from real customers who
>     both
>     >>     >>>>>>
>     >>     >>>>>> We all agree the request is legitimate.
>     >>     >>>>>>
>     >>     >>>>>> [LES:] It does not seem to me that everyone does
>     agree on
>     >>     that – but I appreciate that you agree.
>     >>     >>>>>>
>     >>     >>>>>> But do they realize that to practically employ what
>     you
>     >>     >>>>>>
>     >>     >>>>>> [LES:] As far as forwarding, as Peter has
>     indicated, we
>     >>     >>>>>> It may or may not require 100% software upgrade –
>     but I
>     >>     >>>>>>
>     >>     >>>>>>
>     >>     >>>>>> And with scale requirements you are describing it
>     seems
>     >>     >>>>>>
>     >>     >>>>>> [LES:] Be happy to review other solutions if/when
>     someone
>     >>     writes them up.
>     >>     >>>>>> I think what is overlooked in the discussion of
>     other
>     >>     >>>>>> You seem focused on the notification delivery
>     mechanism
>     >>     only.
>     >>     >>>>>>
>     >>     >>>>>> Les
>     >>     >>>>>>
>     >>     >>>>>> Many thx,
>     >>     >>>>>> Robert
>     >>     >>>>>>
>     >>     >>>>>> _______________________________________________
>     >>     >>>>>> Lsr mailing list
>     >>     >>>>>> [email-masked]
>     >>     >>>>>> https://www.ietf.org/mailman/listinfo/lsr
>     >>     >>>>>
>     >>     >>>>
>     >>     >>>
>     >>     >>
>     >>     >
>     >>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Jan 2022 11:41:52 +0100

Chris,

Of course there are more prefixes then PEs in the IGP.

But I understood as in the light of this discussion some folks attempted to
say that you can trim that set even more.

So for the purpose of the topic I would rather call them as service
endpoint nodes and do not attempt to make an impression that only some of
them are important. That includes all PEs or PEs & Segment endpoints.

Thx,
R.

On Mon, Jan 24, 2022 at 11:31 AM Christian Hopps <[email-masked]> wrote:

> There are plenty more prefixes in an IGP domain than just PE loopbacks.
> For example, all the internal networks, and those are great candidates for
> summarization.
>
> We've been calling out these "important prefixes" for quite a while (and
> w/o the need for summarization) -- this is why we added admin tags way back
> when, to be able to identify "important" prefixes so e.g., routers could
> give them higher priority for insertion in their FIB, etc..
>
> Thanks,
> Chris.
>
> >
> > Thx,
> > R.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >     >>     > We should consider the balance and efficiency for the
> >     summary
> >     >>     or not summary.
> >     >>     >> On Jan 15, 2022, at 09:26, Christian Hopps <
> >     [email-masked]>
> >     >>     wrote:
> >     >>     >>
> >     >>     >>
> >     >>     >>
> >     >>     >>>>>> According to your logic, IGP are solving the wrong
> >     problem
> >     >>     now?
> >     >>     >>>>>>
> >     >>     >>>>>> Aijun Wang
> >     >>     >>>>>> China Telecom
> >     >>     >>>>>>
> >     >>     >>>>>>
> >     >>     >>>>>> Please note if the node is down, the service will
> >     not be
> >     >>     accessed.
> >     >>     >>>>>> We are discussing the “DOWN” notification, not the
> >     “UP”
> >     >>     notification.
> >     >>     >>>>>>
> >     >>     >>>>>> Aijun Wang
> >     >>     >>>>>> China Telecom
> >     >>     >>>>>>
> >     >>     >>>>>>
> >     >>     >>>>>> From: Lsr <[email-masked]> On Behalf Of
> >     Robert
> >     >>     Raszuk
> >     >>     >>>>>>> You seem focused on the notification delivery
> >     mechanism
> >     >>     only.
> >     >>     >>>>>>
> >     >>     >>>>>> Now such direction does not indicate if the shop is
> >     open
> >     >>     or has crabs.
> >     >>     >>>>>>
> >     >>     >>>>>> On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg
> >     (ginsberg) <
> >     >>     >>>>>> [LES:] It does not seem to me that everyone does
> >     agree on
> >     >>     >>>>>> [LES:] Be happy to review other solutions if/when
> >     someone
> >     >>     writes them up.
> >     >>     >>>>>> You seem focused on the notification delivery
> >     mechanism
> >     >>     only.
> >     >>     >>>>>>
> >     >>     >>>>>> Les
> >     >>     >>>>>>
> >     >>     >>>>>> Many thx,
> >     >>     >>>>>> Robert
> >     >>     >>>>>>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 24 Jan 2022 13:35:14 +0100

Chris,

>        If the summarization process *doesn't work* for a given prefix P, then *don't use summarization* for prefix P!

above simply does not work.

1. so far nobody summarizes and it all works. True, reason being that 
the number of PEs in the network is typically below 10k. Also 
summarization with the MPLS data plane is problematic.

We are getting requests to design a next-gen networks that will include 
100k PEs. The summarization is essential in such scale.

2. We are only talking about PE addresses here, not the infrastructure 
links obviously - those are filtered out using other techniques. All the 
PE addresses are equally important, it's not possible to make only some 
of them important, while others not.

thanks,
Peter

---

From: Christian Hopps <[email-masked]>
Date: Mon, 24 Jan 2022 10:19:19 -0500

> 1. so far nobody summarizes and it all works. True, reason being that the number
> of PEs in the network is typically below 10k. Also summarization with the MPLS
> data plane is problematic.
>
> We are getting requests to design a next-gen networks that will include 100k
> PEs. The summarization is essential in such scale.

So pick a better design -- seriously.

It seems its time to think "outside the single IGP box" to handle the PE to PE functionality when you start contemplating 100k PEs. Especially when every PE probably doesn't need full-mesh hyper-adaptive knowledge of every other PE for doing their jobs.

In any case the inelegance of the proposed changes to the routing protocol are a giant flashing red warning light that the chosen design is not the right one.

Thanks,
Chris.
[as wg member]

>
> 2. We are only talking about PE addresses here, not the infrastructure links
> obviously - those are filtered out using other techniques. All the PE addresses
> are equally important, it's not possible to make only some of them important,
> while others not.
>
>
>
>
> thanks,
> Peter
>
>> Thanks,
>> Chris.
>> [As wg member]
>>
>>> Best Regards
>>>
>>> Aijun Wang
>>> China Telecom
>>>

---

From: Peter Psenak <[email-masked]>
Date: Mon, 24 Jan 2022 18:42:31 +0100

> It seems its time to think "outside the single IGP box" to handle the PE to PE functionality when you start contemplating 100k PEs. Especially when every PE probably doesn't need full-mesh hyper-ad…

- multiple IGPs do not solve the problem. You can stick BGP between 
them, but it brings its own issues. What else do you have?

- the point is we can scale IGPs to these numners with summarization 
easily. With summarization you have a perfect topology isolation and 
decent convergence if we solve the problem in hand.

- nobody claims every PE needs to talk to every PE. But any PE in any 
area may need to talk to some PEs from other areas.

> In any case the inelegance of the proposed changes to the routing protocol are a giant flashing red warning light that the chosen design is not the right one.

I don't understand the basis of the above statement.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Jan 2022 18:48:29 +0100

Hi Peter,

> area may need to talk to some PEs from other areas.

Thx for admitting that true statement.

The issue with PULSE is then why to send PULSES to those PEs which do not
need them ? Same for all the P routers which by design will never need them
?

Don't you see that the pub-sub model is architecturally much better suited
for the problem at hand ?

Thx,
R.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 24 Jan 2022 15:27:23 -0500

Peter Psenak <ppsenak=[email-masked]> writes:

>> It seems its time to think "outside the single IGP box" to handle the PE to PE
>> functionality when you start contemplating 100k PEs. Especially when every PE
>> probably doesn't need full-mesh hyper-adaptive knowledge of every other PE for
>> doing their jobs.
>
> - multiple IGPs do not solve the problem. You can stick BGP between them, but it
>  brings its own issues. What else do you have?

These aren't my customers bringing these demands to me -- so not my job. :) Maybe this doesn't even need to be done in routing at all.

> - the point is we can scale IGPs to these numners with summarization easily.
>  With summarization you have a perfect topology isolation and decent convergence
> if we solve the problem in hand.

But that the point, it's *not* easy at all, you are having to hack the routing protocol into doing non-normal ugly things to make it into a workable solution.

> - nobody claims every PE needs to talk to every PE. But any PE in any area may
>  need to talk to some PEs from other areas.

Definitely something to consider for looking at better fitting solutions. Putting this in the IGP provides way more than you need, which may be a hint at why that solution is not cleaning working for you.

Thanks,
Chris.

>
>
>> In any case the inelegance of the proposed changes to the routing protocol are
>> a giant flashing red warning light that the chosen design is not the right
>> one.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 25 Jan 2022 09:49:23 +0800

Hi, Christian、Robert、Tony:

1) Consider in the BGP scenario: every PE may receive the routes from other PEs, right? So, using the PUB/SUB model, every PE should subscribe the status of the other PEs, right? 
2) Consider in the tunnel scenario: every PE/P may select other PE/P as the tunnel endpoint, right?, So, using the PUB/SUB model, every P/PE should subscribe the status of other P/PEs, right?
Then, with the approach of PUB/SUB direction, the network will eventually evolved into full mesh like subscription. That is, every device in the network will care about every other device's status. Then, isn't the flooding mechanism the most efficient one?

If we take the no summary solution, for the above so called "important prefixes", then:
1) All the devices within the network will be filled with these detail prefixes in the normal state, right? 
2) When there is the massive failure as that you often worried, the status of such detailed prefixes will influence the IGP convergence, right?
3) And, when the massive failure recovery, the status of such detailed prefixes will influence AGAIN the performance of IGP, right?

But with the summary+PUA/PULSE(with the threshold control on ABRs as described in https://mailarchive.ietf.org/arch/msg/lsr/fnP1dwvWhT3oRduwXGK73NzQAUo/), 
1) There is NO stress for all the devices in the network to keep the above detailed "important prefixes" in the normal state, right?
2) There is CONTROLLED influence to the IGP when massive failure occur, right?
3) There is NO influence to the IGP performance when massive failure recovery, right?

Which one is the best option then?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Christian Hopps <[email-masked]> 
Sent: Tuesday, January 25, 2022 4:27 AM
To: Peter Psenak <ppsenak=[email-masked]>
Cc: Christian Hopps <[email-masked]>; 'John E Drake' <[email-masked]>; 'Gyan Mishra' <[email-masked]>; 'Robert Raszuk' <[email-masked]>; 'Les Ginsberg (ginsberg)' <[email-masked]>; 'Shraddha Hegde' <[email-masked]>; Aijun Wang <[email-masked]>; 'Tony Li' <[email-masked]>; 'Hannes Gredler' <[email-masked]>; [email-masked]
Subject: Re: [Lsr] BGP vs PUA/PULSE

Peter Psenak <ppsenak=[email-masked]> writes:

>>> 1. so far nobody summarizes and it all works. True, reason being 
>>> that the number of PEs in the network is typically below 10k. Also 
>>> We are getting requests to design a next-gen networks that will 
>>> include 100k PEs. The summarization is essential in such scale.
>> It seems its time to think "outside the single IGP box" to handle the 
>> PE to PE functionality when you start contemplating 100k PEs. 
>> Especially when every PE probably doesn't need full-mesh 
>> hyper-adaptive knowledge of every other PE for doing their jobs.
>

>  With summarization you have a perfect topology isolation and decent 
> convergence if we solve the problem in hand.

Thanks,
Chris.

>
>
>> In any case the inelegance of the proposed changes to the routing 
>> protocol are a giant flashing red warning light that the chosen 
>> design is not the right one.
>
>>> 2. We are only talking about PE addresses here, not the 
>>> infrastructure links obviously - those are filtered out using other 
>>> techniques. All the PE addresses are equally important, it's not 
>>> possible to make only some of them important, while others not.
>>>
>>>
>>>
>>>
>>> thanks,
>>> Peter
>>>
>>>> Thanks,
>>>> Chris.
>>>> [As wg member]
>>>>
>>>>> Best Regards
>>>>>
>>>>> Aijun Wang
>>>>> China Telecom
>>>>>
>>>>> John E Drake <[email-masked]>; Les Ginsberg (ginsberg) 
>>>>> <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; 
>>>>> Robert Raszuk <[email-masked]>; Shraddha Hegde 
>>>>> "If a prefix is important enough to consider seriously hacking the 
>>>>> routing protocol to signal the prefix being unreachable, then that 
>>>>> prefix is important enough to not summarize to begin with." IOW; 
>>>>> KISS
>>>>>
>>>>>> possible and that as well includes PE loopback next hop attribute 
>>>>>> to limit the router load as well as size of LSDB in the backbone 
>>>>>> as well as domain wide.
>>>>>>
>>>>>> I think you would be hard pressed to find any vendor that would 
>>>>>> say go ahead and flood loopbacks domain wide and don’t summarize.
>>>>>>
>>>>>> summarization is requirement even for the critical loopback BGP 
>>>>>> next hops for most operators.
>>>>>>
>>>>>> RFC 5302 talks about the ramifications of flooding in ISIS domain 
>>>>>> in section 1.2 excerpt below:
>>>>>>
>>>>>>
>>>>>> 1.2.  Scalability
>>>>>>
>>>>>> On Fri, Jan 14, 2022 at 9:07 PM Christian Hopps 
>>>>>> <[email-masked]>
>>>>>> wrote:
>>>>>>

---

From: Tony Li <[email-masked]>
Date: Mon, 24 Jan 2022 23:24:48 -0800

Hi Aijun,

> 1) Consider in the BGP scenario: every PE may receive the routes from other PEs, right? So, using the PUB/SUB model, every PE should subscribe the status of the other PEs, right? 

My understanding is that a PE typically only has tunnels to some other select number of PEs. Yes, each PE would register for the other PEs that it connects to.

> Then, with the approach of PUB/SUB direction, the network will eventually evolved into full mesh like subscription. That is, every device in the network will care about every other device's status.…

Efficient in what metric? In terms of the number of unique messages initiated, yes. However, that is not the metric that matters. What matters is the load on the network when there are failures and PUA dumps things into the L2 LSDB.

We specifically have to design routing protocols to operate in worst case scenarios. PUA means that there is no real upper bound to the worst case. Bad news that we weren’t expecting can just keep piling up. The worst scale point is when everything has failed. For ensuring stability that’s disasterous. And stability is way, way, way more important than efficiency.

> 1) All the devices within the network will be filled with these detail prefixes in the normal state, right? 

Yes.

> 2) When there is the massive failure as that you often worried, the status of such detailed prefixes will influence the IGP convergence, right?

Unlikely. If there are massive failures then prefixes will be withdrawn, not added.  State goes down. The stress on the network goes down. This is a highly desirable property.  Withdrawing state is not going to significantly affect the performance of the IGP.  SPF performance is O(n log n) for n = (# edges + #nodes).  The number of prefixes is relatively noise.

> 3) And, when the massive failure recovery, the status of such detailed prefixes will influence AGAIN the performance of IGP, right?

No.  Same reasoning.

> 1) There is NO stress for all the devices in the network to keep the above detailed "important prefixes" in the normal state, right?

True. Also irrelevant.

> 2) There is CONTROLLED influence to the IGP when massive failure occur, right?

Perhaps, but the grave concern is that the ‘controlled influence’ is adequate to maintain stability and yet providing some benefit.  Again, the feature is architected backwards: it adds stress under failure conditions. Exactly what we don’t want.

And whatever control is installed, some customer will dial it up to 11 and then call my CEO when their network melts down. No thank you.

> 3) There is NO influence to the IGP performance when massive failure recovery, right?

Irrelevant. The recovery time is irrelevant. Again, the primary requirement is stabiilty.

> Which one is the best option then?

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

Stability, stability, stability, and stability. Get the message?

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 25 Jan 2022 16:00:06 +0800

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 is coming from what you claimed stress? They are just messages, similar with your message that via other out-of-band channel.
Other responses inline. 

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, January 25, 2022 3:25 PM
To: Aijun Wang <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; Christian Hopps <[email-masked]>; Robert Raszuk <[email-masked]>; lsr <[email-masked]>
Subject: Re: [Lsr] BGP vs PUA/PULSE

Hi Aijun,

My understanding is that a PE typically only has tunnels to some other select number of PEs. Yes, each PE would register for the other PEs that it connects to.
[WAJ] No tunnel. You misunderstand the sentence, please read it again.

Efficient in what metric? In terms of the number of unique messages initiated, yes. However, that is not the metric that matters. What matters is the load on the network when there are failures and PUA dumps things into the L2 LSDB.
[WAJ] They are just messages. It's certainly no more than your out-of-band messages.

We specifically have to design routing protocols to operate in worst case scenarios. PUA means that there is no real upper bound to the worst case. Bad news that we weren’t expecting can just keep piling up. The worst scale point is when everything has failed. For ensuring stability that’s disasterous. And stability is way, way, way more important than efficiency.
[WAJ] There is control method at the ABR, why you always ignores it? It like that you do the summary work at ABR. 

Yes.

Unlikely. If there are massive failures then prefixes will be withdrawn, not added.  State goes down. The stress on the network goes down. This is a highly desirable property.  Withdrawing state is not going to significantly affect the performance of the IGP.  SPF performance is O(n log n) for n = (# edges + #nodes).  The number of prefixes is relatively noise.
[WAJ] If your above explanation is right, it is the same for PUA solution. Isn't it?

> 3) And, when the massive failure recovery, the status of such detailed prefixes will influence AGAIN the performance of IGP, right?

No.  Same reasoning.
[WAJ] Are you sure? State goes up, the stress on the network goes down?

> 1) There is NO stress for all the devices in the network to keep the above detailed "important prefixes" in the normal state, right?

True. Also irrelevant.
[WAJ] You can always ignores the merits of other solutions.

Perhaps, but the grave concern is that the ‘controlled influence’ is adequate to maintain stability and yet providing some benefit.  Again, the feature is architected backwards: it adds stress under failure conditions. Exactly what we don’t want.
And whatever control is installed, some customer will dial it up to 11 and then call my CEO when their network melts down. No thank you.
[WAJ] Again, no SPF stress under failure condition. No more message than your out-of-band solution.

Irrelevant. The recovery time is irrelevant. Again, the primary requirement is stabiilty.
[WAJ] Very curious, how to get such conclusion?

1) Leak PE loopbacks
2) Pub/Sub

Stability, stability, stability, and stability. Get the message?
[WAJ] From the above ranking, I begin again to doubt your expert's undestanding. Please notice again when the router receives PUA message, no SPF algorithm needed, Understand? Understand? Understand? 

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 09:54:43 +0100

> 3) Carry loopbacks in BGP and recurse

I would like to actually add to this list two alternatives which some
vendors have been shipping for decades:

X) Withdraw service routes based on the local next hop tracking trigger
(from local RR)
Y) Even Further Aggregate the withdraws as described in X

X alone gives you today max a few seconds of connectivity disruption - if
that is the overall goal we are heading to no 1-6 is required.

Y as described in
https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt   and/or
 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-nh-cost   can
even further reduce that. #3 above is even further speed up via native to
BGP recursion.

If BGP is not running there some service does and that service hopefully
has better convergence characteristics then BGP.

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 of
redundant egress connectivity.

I am perhaps restating the above but trying to look holistically at the
problem. Especially as some folks apparently still believe that "BGP is
slow" and that iBGP def timers of 180 sec are even relevant to the topic.
They are clearly not.

Many thx,
Robert

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 25 Jan 2022 17:30:35 +0800

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 of redundant egress connectivity. 

[WAJ] I think the goal is same as that we invented the BFD for BGP, or BFD for other protocol.  We have discussed several rounds that why we don’t want to reply on BFD for the previous mentioned two categories scenarios.

I am perhaps restating the above but trying to look holistically at the problem.

[WAJ]  Please refer to https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-3, but I think you have known them very well. This is also the start point of our solution.

Especially as some folks apparently still believe that "BGP is slow" and that iBGP def timers of 180 sec are even relevant to the topic. They are clearly not. 

[WAJ] What we are discussing is that the “BGP Peer Status Detection(BGP’s hello timer)” is slow.  For tunnel services, there is no timers at all.

Many thx,

Robert

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 10:36:25 +0100

Aijun,

On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang <[email-masked]>
wrote:

> *[WAJ] I think the goal is same as that we invented the BFD for BGP, or
> BFD for other protocol.  We have discussed several rounds that why we don’t
> want to reply on BFD for the previous mentioned two categories scenarios.*
>

You are completely missing the point. I never mentioned BFD. BFD is not
needed in neither X nor Y options listed in my note.

Especially as some folks apparently still believe that "BGP is slow" and
> that iBGP def timers of 180 sec are even relevant to the topic. They are
> clearly not.
>
> *[WAJ] What we are discussing is that the “BGP Peer Status Detection(BGP’s
> hello timer)” is slow.  For tunnel services, there is no timers at all.*
>

And the fundamental observation is that “BGP Peer Status Detection(BGP’s
hello timer)” is absolutely irrelevant to neither X nor Y.

If you and/or others do not understand this basic premise then we have an
issue.

And for tunnel services with no BGP there is other layer controlling the
service. Tunnel all by itself is pretty useless.

Kind regards,
R.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 25 Jan 2022 17:48:06 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Jan 25, 2022, at 17:36, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
>> On Tue, Jan 25, 2022 at 10:30 AM Aijun Wang <[email-masked]> wrote:
>> Hi, Robert:
>> 
>>  
>> 
> You are completely missing the point. I never mentioned BFD. BFD is not needed in neither X nor Y options listed in my note. 

[WAJ] X aims to how to withdraw the VPN prefixes with the mentioned extended communities, right? Y aims to how assist the RR get the prefix cost from one node that other than the RR itself. Right?
I think they all don’t answer the questions how to detect the failure of BGP peer. Right? For this requirement, you can only depend on the BGP hello timers, or BFD for BGP. Right?
What I try to answer is your question for the “ultimate goal”.

> And the fundamental observation is that “BGP Peer Status Detection(BGP’s hello timer)” is absolutely irrelevant to neither X nor Y. 
[WAJ]Yes. Then can I stated that X or Y is irrelevant to the discussed questions?
> 
> If you and/or others do not understand this basic premise then we have an issue. 
> 
> And for tunnel services with no BGP there is other layer controlling the service. Tunnel all by itself is pretty useless. 
[WAJ] For SRv6 tunnel services, which layer control? How?

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 10:59:02 +0100

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 think they all don’t answer the questions how to detect the failure of
> BGP peer. Right? For this requirement, you can only depend on the BGP hello
> timers, or BFD for BGP. Right?
>

Wrong. Let me explain.

PEs peer with iBGP sessions to a pair of RR in a local area. In the vast
majority of cases those RRs are IGP nodes. If so in exactly the same way as
ABRs, also RRs will be receiving local area link state flooding about PEs
going down.

That along with next hop tracking (local feature) will trigger event driven
service path invalidation followed by immediate withdrawal. Note that those
withdraws will be propagated via one or max two RR hops before reaching the
destination PE(s). That propagation speed is in milliseconds when measured
with solid BGP implementation. It can be much faster then flooding via 10s
of IGP nodes across two areas.

If RRs are running on x86 blades they do not need to be IGP nodes, but
nothing stops them from being passive IGP listeners.

That is how you detect the failures local to your areas on the BGP RRs. The
trigger is exactly the same for RRs as is for ABRs. Has been done and
deployed for decades now and works perfectly fine.

> [WAJ] For SRv6 tunnel services, which layer control? How?

Something runs over those tunnels right ? If not we have no issue anyway as
there is no service to be protected or :).

Thx,
R.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 25 Jan 2022 05:12:09 -0500

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 some value is still being produced by the discussion, if somewhat painfully.

Thanks,
Chris.

"Aijun Wang" <[email-masked]> writes:

> When the receivers receives the PUA information, the SPF algorithm will not be
> triggered, then where is coming from what you claimed stress? They are just
> messages, similar with your message that via other out-of-band channel.
> Other responses inline.
>
> Best Regards
>
> Aijun Wang
> China Telecom
>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Gyan Mishra
> <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>;
> Christian Hopps <[email-masked]>; Robert Raszuk <[email-masked]>; lsr
> <[email-masked]>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 25 Jan 2022 18:36:57 +0800

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 <[email-masked]> wrote:
> 
> 
> Aijun,
> 
>> [WAJ] X aims to how to withdraw the VPN prefixes with the mentioned extended communities, right?
> 
>> Y aims to how assist the RR get the prefix cost from one node that other than the RR itself. Right?
> 
> No. 
>  
> PEs peer with iBGP sessions to a pair of RR in a local area. In the vast majority of cases those RRs are IGP nodes. If so in exactly the same way as ABRs, also RRs will be receiving local area link state flooding about PEs going down. 
> 
> That along with next hop tracking (local feature) will trigger event driven service path invalidation followed by immediate withdrawal. Note that those withdraws will be propagated via one or max two RR hops before reaching the destination PE(s). That propagation speed is in milliseconds when measured with solid BGP implementation. It can be much faster then flooding via 10s of IGP nodes across two areas. 
> 
> If RRs are running on x86 blades they do not need to be IGP nodes, but nothing stops them from being passive IGP listeners.
> 
> That is how you detect the failures local to your areas on the BGP RRs. The trigger is exactly the same for RRs as is for ABRs. Has been done and deployed for decades now and works perfectly fine. 
> 
>  
> Something runs over those tunnels right ? If not we have no issue anyway as there is no service to be protected or :).
> 
> Thx,
> R.
>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 25 Jan 2022 12:34:54 +0100

> These aren't my customers bringing these demands to me -- so not my job. :) Maybe this doesn't even need to be done in routing at all.

I thought scaling IGPs to meet the real life deployment requirements is 
part of the LSR WG charter. If we say "go and fix it elsewhere", maybe 
we can close the WG.

> But that the point, it's *not* easy at all, you are having to hack the routing protocol into doing non-normal ugly things to make it into a workable solution.

why?

Flat ISIS networks with 3k PE nodes have been deployed. In such case, 
each router sees full topology of 3k+ nodes + 3k PE addresses.

With the 100k PE, split in 100 areas with the summarization in place, 
each router would see 1k nodes in its area + 1,1k prefixes. Less than 
the above. What is the problem?

> Definitely something to consider for looking at better fitting solutions. Putting this in the IGP provides way more than you need, which may be a hint at why that solution is not cleaning working f…

sorry, I don't get what you are trying to say here. You are claiming 
something does not work without providing any evidence as why that would 
be the case.

thanks,
Peter

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 12:46:20 +0100

If you have so many PEs in an area that you must summarize then putting RR
outside of this area I would call a bad design.

Thx
R.

On Tue, Jan 25, 2022, 11:37 Aijun Wang <[email-masked]> wrote:

> 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?
> That along with next hop tracking (local feature) will trigger event
> driven service path invalidation followed by immediate withdrawal. Note
> that those withdraws will be propagated via one or max two RR hops before
> reaching the destination PE(s). That propagation speed is in
> milliseconds when measured with solid BGP implementation. It can be much
> faster then flooding via 10s of IGP nodes across two areas.
>
> That is how you detect the failures local to your areas on the BGP RRs.
> The trigger is exactly the same for RRs as is for ABRs. Has been done and
> Something runs over those tunnels right ? If not we have no issue anyway
> as there is no service to be protected or :).
>
> Thx,
> R.
>
>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 25 Jan 2022 20:29:09 +0800

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 may satisfy your assumption.
We will not deploy the RR on every IGP area.

Aijun Wang
China Telecom

> On Jan 25, 2022, at 19:46, Robert Raszuk <[email-masked]> wrote:
> 
> 
> If you have so many PEs in an area that you must summarize then putting RR outside of this area I would call a bad design.
> 
> Thx
> R.
>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 25 Jan 2022 07:38:40 -0500

Peter Psenak <[email-masked]> writes:

>> These aren't my customers bringing these demands to me -- so not my job. :)
>> Maybe this doesn't even need to be done in routing at all.
>
> I thought scaling IGPs to meet the real life deployment requirements is part of
> the LSR WG charter. If we say "go and fix it elsewhere", maybe we can close the
> WG.

This is disingenuous. I think it's pretty clear that I'm not saying that "let's not fix scaling issues". I'm saying don't hack the hell out of the protocol to make it do something it's not designed to do.

Thanks,
Chris.

>> But that the point, it's *not* easy at all, you are having to hack the routing
>> protocol into doing non-normal ugly things to make it into a workable
>> solution.
>
> why?
>
> Flat ISIS networks with 3k PE nodes have been deployed. In such case, each
> router sees full topology of 3k+ nodes + 3k PE addresses.
>
> With the 100k PE, split in 100 areas with the summarization in place, each
> router would see 1k nodes in its area + 1,1k prefixes. Less than the above. What
> is the problem?
>
>>
>> Definitely something to consider for looking at better fitting solutions.
>> Putting this in the IGP provides way more than you need, which may be a hint
>> at why that solution is not cleaning working for you.
>
> sorry, I don't get what you are trying to say here. You are claiming something
> does not work without providing any evidence as why that would be the case.
>
> thanks,
> Peter
>
>> Thanks,
>> Chris.
>>
>>>
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 14:03:10 +0100

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 , that is close to the customer.
> There maybe some small network that may satisfy your assumption.
>

Thank you for educating me what "PE" stands for.

> We will not deploy the RR on every IGP area.

Great ! It's your network where you can do whatever you like there. But I
am so happy not to be one of your customers.

If you are given a recommendation to design the network in a way which
solves your requirement, then you dismiss it "just because" you can't
request any WG to standardize your solution to fit your network. It's not
how IETF operates.

Regards,
Robert.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 25 Jan 2022 21:09:32 +0800

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 Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> And the protocol extensions can not be justified based on the limited corner cases of broken network designs. 
> 
> Great ! It's your network where you can do whatever you like there. But I am so happy not to be one of your customers. 
> 
> If you are given a recommendation to design the network in a way which solves your requirement, then you dismiss it "just because" you can't request any WG to standardize your solution to fit your network. It's not how IETF operates.
> 
> Regards,
> Robert.
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 14:20:39 +0100

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
> the location of RR and PEs.
>

Please observe that if you really want to put RRs outside of your local
area for whatever reason (maybe you run RR as a service in the cloud) then
actually we can combine X from my additional point with Tony's proposal. It
just occurred to me like a really interesting deployment mode so let me
describe the WG. Maybe Tony can add this model to his draft in the possible
deployment section.

- - -

When network elements residing outside of the local area are interested in
node liveness of selected nodes in the area (for example BGP Route
Reflectors running in the cloud) they can register with node
liveness servers in an area to receive targetted notifications for
interested addresses.

Such notifications can be used to invalidate service next hops or tunnel
endpoints. Upon such action service information will be immediately
withdrawn.

That deployment model offers full flexibility with just a handful of
additional TCP or QUIC sessions needed and very little to no extra state
injected in the network.

- - -

That model also addresses some concerns associated with any to any
registrations. No longer PEs need to register anything with ABRs nor ABRs
need to pass that information around.

Best regards,
R.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 25 Jan 2022 23:01:10 +0800

Hi, Robert:

You mean make every PE as the register server?

Aijun Wang
China Telecom

> On Jan 25, 2022, at 21:21, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
> 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 the location of RR and PEs.
> 
> Please observe that if you really want to put RRs outside of your local area for whatever reason (maybe you run RR as a service in the cloud) then actually we can combine X from my additional point with Tony's proposal. It just occurred to me like a really interesting deployment mode so let me describe the WG. Maybe Tony can add this model to his draft in the possible deployment section. 
> 
> - - -
> 
> When network elements residing outside of the local area are interested in node liveness of selected nodes in the area (for example BGP Route Reflectors running in the cloud) they can register with node liveness servers in an area to receive targetted notifications for interested addresses. 
> 
> Such notifications can be used to invalidate service next hops or tunnel endpoints. Upon such action service information will be immediately withdrawn. 
> 
> That deployment model offers full flexibility with just a handful of additional TCP or QUIC sessions needed and very little to no extra state injected in the network. 
> 
> - - - 
> 
> That model also addresses some concerns associated with any to any registrations. No longer PEs need to register anything with ABRs nor ABRs need to pass that information around. 
> 
> Best regards,
> R.
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 16:02:13 +0100

No. Run this node liveness service on ABR or on any other IGP node in an
area.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 25 Jan 2022 23:07:08 +0800

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 <[email-masked]> wrote:
> 
> Hi, Robert:
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 25 Jan 2022 16:28:15 +0100

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 25 Jan 2022 16:01:30 +0000

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 PEs (100K total PEs) with 2 ABRs per area? 

Thanks,
Acee 

On 1/25/22, 5:20 AM, "Lsr on behalf of Christian Hopps" <[email-masked] on behalf of [email-masked]> wrote:

    Chair Hat:

    Thanks,
    Chris.

---

From: Aijun Wang <[email-masked]>
Date: Wed, 26 Jan 2022 07:48:31 +0800

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 <[email-masked]> wrote:
> 
> 
> 
> You may also provision this session by your management plane just like you push 1000s of configuration lines anyway to each network element. 
> 
>> On Tue, Jan 25, 2022 at 4:07 PM Aijun Wang <[email-masked]> wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 26 Jan 2022 00:57:30 +0100

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 is a a new IGP message type with new transport. While a
separate subsystem (which can in fact run on different core and have
independent memory space ie. be a different thread or process) it is both
functionally and operationally an IGP service. Just like PUA or PULSE.

Flooding is not MUST have paradigm for an IGP where IGP == Interior Gateway
Protocol. As you know some folks use BGP as IGP for MSDCs. Clearly BGP does
not use too much flooding.

Best,
Robert.

On Wed, Jan 26, 2022 at 12:48 AM Aijun Wang <[email-masked]>
wrote:

>> When network elements residing outside of the local area are interested
>> in node liveness of selected nodes in the area (for example BGP Route

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 26 Jan 2022 09:45:27 +0800

Hi, Robert:

From: Robert Raszuk <[email-masked]> 
Sent: Wednesday, January 26, 2022 7:58 AM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; Tony Li <[email-masked]>
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. 

Because to do it efficiently and in scalable manner close cooperation with LSDB is required. Management system is completely orthogonal to that. 

[WAJ] Then why reluctant to accept the solution that based on the current IGP mechanism?

IMO Tony's proposal is a a new IGP message type with new transport. While a separate subsystem (which can in fact run on different core and have independent memory space ie. be a different thread or process) it is both functionally and operationally an IGP service. Just like PUA or PULSE. 

[WAJ] There is already such message, and such transport within IGP, why design another what you called IGP-like message(actually it is not) and transport again? As said earlier, the PUA/PULSE is just also the same purpose message, it doesn’t influence the SPF efficiency. 

What’s the unsolved concerns regarding to the PUA/PULSE then?

People may argue that flooding can get the result that the message is sent to the unsolicited node. But as also we have discussed earlier, the PUB/SUB model will eventually dive into the full-mesh style.

And, we should consider the network are evolved to the stateless approach, for example, the SR/SRv6’s replace to RSVP/LDP etc. But PUB/SUB will let the PEs, especially the ABRs back to keep the (connection) state again. Do you still think it is one scalable solution?

Flooding is not MUST have paradigm for an IGP where IGP == Interior Gateway Protocol. As you know some folks use BGP as IGP for MSDCs. Clearly BGP does not use too much flooding. 

[WAJ] Then RSVP、PIM、LDP etc. can all be called IGP protocol? Certainly not.

Best,
Robert.

On Wed, Jan 26, 2022 at 12:48 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

Aijun Wang

China Telecom

On Jan 25, 2022, at 23:28, Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

On Tue, Jan 25, 2022 at 4:07 PM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Aijun Wang

China Telecom

On Jan 25, 2022, at 23:01, Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

Aijun Wang

China Telecom

On Jan 25, 2022, at 21:21, Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Aijun,

- - -

- - - 

Best regards,

R.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 27 Jan 2022 00:32:36 -0500

Maybe even use SDN / PCE centralized controller , stateful PCE which has
peer to each node to instantiate the LSP as well as now manage the
component prefixes state.  So we can drift completely out of the IGP realm
but we are choosing to stay in IGP realm with PUB/SUB.

The PUB/SUB model has been mentioned that it has very low overhead as  it
propagates the notification messaging using PUB/SUB model which is in
theory less chatting then PULSE and PUAM IGP flooding of the event
notification.

PULSE/PUAM also have the same very low overhead as it’s the same PUB/SUB
link Up/Down notification messaging being carried by the IGP and not via
separate protocol (out-of-band).

In the  PUB/SUB model in reality it is similar to and no different then IGP
flooding, as once a prefix goes Up / Down, the message is sent immediately
to all nodes in the area, no different then PUA/PULSE IGP flooding. The
ABRs flood over a TCP mesh to all routers in the area which is literally
identical to IGP flooding just using a different transport protocol.

Kind Regards

Gyan

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 27 Jan 2022 19:48:16 -0500

Sorry important correction in comparison PUB/SUB to PUAM/PULSE with regards
to flooding to be fair.

PUAM/PULSE use IGP flooding which is hop by propagation of the good or bad
news so all nodes in the area are in scope in the flood.

PUB/SUB focuses the interesting traffic on BGP egress PEs that need it by
terminating TCP sessions only on those PE devices.

The big question is does the WG want this solved with a solution that is
contained within the IGP or is having solution outside of the IGP ok such
the PUB/SUB model.

Thanks

Gyan

On Thu, Jan 27, 2022 at 12:32 AM Gyan Mishra <[email-masked]> wrote:

> In the  PUB/SUB model in reality it is similar to and no different then
> IGP flooding, as once a prefix goes Up / Down, the message is sent
> immediately to all nodes in the area, no different then PUA/PULSE IGP
> flooding. The ABRs flood over a TCP mesh to all routers in the area which
> is literally identical to IGP flooding just using a different transport
> protocol.
>
> Kind Regards
>
> Gyan
>
>> You may also provision this session by your management plane just like
>> you push 1000s of configuration lines anyway to each network element.
>>

*Gyan Mishra*

*M 301 502-1347*