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

From: Aijun Wang <[email-masked]>
Date: Sat, 27 Nov 2021 08:55:48 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 27, 2021, at 08:26, Robert Raszuk <[email-masked]> wrote:
> 
> Aijun, 
> 
> 
>> [WAJ] As Peter and I state several times, we want to find the generic solution for different scenarios. BGP exist or not.
> 
> Maybe you missed my point. I am not aware of any production router stack which would not support BGP. That is irrespective of if BGP is used for service distribution in any given network or not. 
> 
> Honestly I know deployments (hint MSDC) which do not use IGP, but I am not aware of any network which is not using BGP. 
[WAJ] For your proposed BGP solutions, Peter has responded you and I agree with his opinions with the followings additional comments:
[Option 1]: Can’t get the PIC effect. We should track the reachability of BGP NH.
[Option 2]: Even you tell the remote PE via BGP that it’s peer is down, but the IGP  is still telling him reachable. Will it puzzle the receiving node? 
[Option 3] BGP-LS is mainly used for transferring the topology information northbound to controller, we seldom use it to distribute topology information within the underlying network itself. This is IGP’s work.

> 
> But I am open to evaluate other protocols to distribute requested information. I am not stuck on BGP. As mentioned a lot of pub-sub message bus solutions fit that bill. 
> 
>> Selective leaking requires the additional configuration which we want to avoid from the beginning.
> 
> No one (well at least not me) would recommend any form of selective leaking by hand cfg. It goes without saying that subscription to selective leaking MUST be automated. 
[WAJ] If not via configuration, how to accomplish the selective reaction?
> 
>>  For reliability, they can be sent several times(operator can configure), doesn’t need last until the node is backup again.
> 
> That is interesting ... first time I hear that. And what if node which went down was removed from the network forever ? You will need to go to each ABR and manually stop PUAs/PULSES ? 

[WAJ] No. After the PUA advertise period, only the normal summary address will be remained. We focus only the “Down” moment, not “Down” state.
> 
>> [WAJ] P2MP tunnel should take different action. Only the failure endpoint will not be used.
> 
> Easy to say ... Sure you can remove the adj from FIB. But for how long - that is the question - very important when we are talking about any ephemeral form of signalling. 

[WAJ] If there is no other mechanism/protocol to bring up it, it will remain down.

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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 11:17:18 +0100

Aijun,

AJ] For your proposed BGP solutions, Peter has responded you and I agree
> with his opinions with the followings additional comments:
>

All Peter keeps saying is that the solution must work where BGP is non
existent. I question whether BGP in any network is non-existent. .

> [Option 1]: Can’t get the PIC effect. We should track the reachability of

Yes BGP option 2 as I described gives you PIC effect. In fact I am quite
convinced that if done right it can be much faster then IGP flooding
especially at scale. Please recall all safety belts build into IGP to slow
down churn when multiple events happens in a time scale. That will have a
negative effect on PUA/PULSE propagation speed at scale.

> [Option 2]: Even you tell the remote PE via BGP that it’s peer is down,
> but the IGP  is still telling him reachable. Will it puzzle the receiving
> node?
>

No. Not at all. Decent BGP implementation has a knob where you select over
which length of next hop should be used to resolve service routes. So if
you specify to resolve over /32 or /128 the presence of summary routes in
IGP will not affect it.

> [Option 3] BGP-LS is mainly used for transferring the topology information
> northbound to controller, we seldom use it to distribute topology
> information within the underlying network itself. This is IGP’s work.
>

Oh so now we are talking about topology information distribution ? Each
email from you brings a new surprise :)  In any case BGP-LS was just an
example of a SAFI. It would be ok to define a new SAFI for it. Or even
easier, use 1/1 or 2/1.

No one (well at least not me) would recommend any form of selective leaking
> by hand cfg. It goes without saying that subscription to selective leaking
> MUST be automated.
>

By subscription. Just like any producer can register with local RIB to
track some route it can also register with ABRs or RRs.

[WAJ] No. After the PUA advertise period, only the normal summary address
> will be remained. We focus only the “Down” moment, not “Down” state.
>

That means that any of my encapsulations will start dropping again in 60
sec (timer from PULSE draft). Oh that's pretty cool ! Note that again I am
using your and Peter's case where there is no service BGP on top to remove
service routes.

Easy to say ... Sure you can remove the adj from FIB. But for how long -
> that is the question - very important when we are talking about any
> ephemeral form of signalling.
>

Only for the case of actual p2p tunnel establishment like IPSec or L2TPv3.
In all other cases after PUA timer for all purposes of forwarding the
sending router will start to send again using summary. That is a
severe architecture/design issue IMO.

What "other" mechanism are you talking about ?

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Sat, 27 Nov 2021 18:59:19 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 27, 2021, at 18:17, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Aijun,
> 
>> AJ] For your proposed BGP solutions, Peter has responded you and I agree with his opinions with the followings additional comments:
> 
> All Peter keeps saying is that the solution must work where BGP is non existent. I question whether BGP in any network is non-existent. . 
>  
> Yes BGP option 2 as I described gives you PIC effect. In fact I am quite convinced that if done right it can be much faster then IGP flooding especially at scale. Please recall all safety belts build into IGP to slow down churn when multiple events happens in a time scale. That will have a negative effect on PUA/PULSE propagation speed at scale. 

[WAJ] If such thing happen, won’t the BGP update will also be affected? The underlying IGP are converging.
> No. Not at all. Decent BGP implementation has a knob where you select over which length of next hop should be used to resolve service routes. So if you specify to resolve over /32 or /128 the presence of summary routes in IGP will not affect it. 

[WAJ] When you recall the NH prefix, the 32/ or 128/ route is not exist within the RIB of receiving node, only the summary routes from IGP is existing. How to prefer the 32/ or /128 route?

> Oh so now we are talking about topology information distribution ? Each email from you brings a new surprise :)  In any case BGP-LS was just an example of a SAFI. It would be ok to define a new SAFI for it. Or even easier, use 1/1 or 2/1. 

[WAJ] Even with this non existing assumption, you will require the ABR to be configured with other PE for BGP sessions. Such design will let each ABR act again as RR, won’t you think it is redundant?
> By subscription. Just like any producer can register with local RIB to track some route it can also register with ABRs or RRs.

[WAJ] Register with Loc RIB is easy, but register with other node within IGP is not easy. There is currently no such mechanism within IGP, as Tony Li also confirmed.

> That means that any of my encapsulations will start dropping again in 60 sec (timer from PULSE draft). Oh that's pretty cool ! Note that again I am using your and Peter's case where there is no service BGP on top to remove service routes. 

[WAJ] The tunneled traffic will be diverted to other backup tunnel until the primary node is back again. The detection of the UP status of the primary node is depend on the tunnel technology itself. PUA/PULSE just notifies the tunnel endpoint is down.

> Only for the case of actual p2p tunnel establishment like IPSec or L2TPv3. In all other cases after PUA timer for all purposes of forwarding the sending router will start to send again using summary. That is a severe architecture/design issue IMO.
[WAJ] Using the backup tunnel until the primary node is brought up again.
> What "other" mechanism are you talking about ? 
[WAJ] Like what you mGRE at https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-s/mp-l3-vpns-15-s-book/ir-l3vpn-mgre.html#GUID-066024B8-051D-4891-931E-F8B463C008BA

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 14:58:27 +0100

Hi Aijun,

> The underlying IGP are converging.

You need to be able to distinguish local area convergence from hierarchical
domain wide churn. No BGP will not be affected at all neither in the local
area nor in any other area.

[WAJ] When you recall the NH prefix, the 32/ or 128/ route is not exist
> within the RIB of receiving node, only the summary routes from IGP is
> existing. How to prefer the 32/ or /128 route?
>

In Option-2 I suggested it does exist.

> [WAJ] Even with this non existing assumption, you will require the ABR to
> be configured with other PE for BGP sessions. Such design will let each ABR
> act again as RR, won’t you think it is redundant?
>

No. What you have envisioned would be a pretty ugly design. In Option-3 I
proposed ABR will just have 2 sessions to area-0/level-2 RRs (current or
new).

[WAJ] Register with Loc RIB is easy, but register with other node within
> IGP is not easy. There is currently no such mechanism within IGP, as Tony
> Li also confirmed.
>

Well there is at least one registration mechanism today with BGP where PE
registers with RRs on what is interesting for it. Check  out RFC4684.

[WAJ] The tunneled traffic will be diverted to other backup tunnel until
> the primary node is back again. The detection of the UP status of the
> primary node is depend on the tunnel technology itself. PUA/PULSE just
> notifies the tunnel endpoint is down.
>

Encapsulation does not require tunnel setup. Hint: MPLS over UDP. Show me
please where is the "tunnel" ?

:)

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Sat, 27 Nov 2021 23:19:48 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 27, 2021, at 21:59, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
>>> 
> You need to be able to distinguish local area convergence from hierarchical domain wide churn. No BGP will not be affected at all neither in the local area nor in any other area. 
[WAJ] The PUA/PULSE message doesn’t trigger the SPF calculation, how can the domain wide churn happen?
> In Option-2 I suggested it does exist.

[WAJ] Recall but still exists? Which vendor has such knob? Please give some references

> No. What you have envisioned would be a pretty ugly design. In Option-3 I proposed ABR will just have 2 sessions to area-0/level-2 RRs (current or new). 
> 
> 
> Well there is at least one registration mechanism today with BGP where PE registers with RRs on what is interesting for it. Check  out RFC4684. 

[WAJ]Just image your proposal in the whole picture: should every PE establish two BGP sessions with the RR? May the P router should also do so?
And then every PE  router configure it is interested all the loopack addresses of other PEs? Maybe all the P routers needs to do so?
Is it efficient than the IGP flooding?

> Encapsulation does not require tunnel setup. Hint: MPLS over UDP. Show me please where is the "tunnel" ? 
[WAJ] We are discussing tunnel, why the encapsulation jumps in?

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Nov 2021 16:31:44 +0100

> What churn has to do with SPF ?

[WAJ] Recall but still exists? Which vendor has such knob? Please give some
> references

Cisco IOS. Example XR - has been there for years :)

[WAJ]Just image your proposal in the whole picture: should every PE
> establish two BGP sessions with the RR?
>

Yes. Current practice in 99.9 % of networks. In fact there is usually more
then two IBGP sessions.

> May the P router should also do so?
>

If you want to do local protection sure - but this is just your choice. I
am not pushing you there.

> And then every PE  router configure it is interested all the loopack
> addresses of other PEs?
>

What it is interested in is all dynamic - based on selected BGP next paths
next hops.

> Maybe all the P routers needs to do so?
>

No. No need. P detect local PE failure via LOS or BFD.

> Is it efficient than the IGP flooding?

Yes.

> [WAJ] We are discussing tunnel, why the encapsulation jumps in?

We are discussing pros and cons of the proposal(s). Specifically we are
discussing where it works and where it does not. We are also discussing
alternative solutions to solve a valid problem.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Sun, 28 Nov 2021 00:02:02 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 27, 2021, at 23:32, Robert Raszuk <[email-masked]> wrote:
> 
> 

[WAJ] As we state earlier, the number of notification messages is well estimated, why the churn will occur even in massive failure? Is there any router can’t consume these countable LSA messages?

> Cisco IOS. Example XR - has been there for years :) 

[WAJ] To enable this feature, every PE/P router will be filled with the loopack addresses of other PEs. Is this extensible?
> 
> 
>> [WAJ]Just image your proposal in the whole picture: should every PE establish two BGP sessions with the RR?
> 
> Yes. Current practice in 99.9 % of networks. In fact there is usually more then two IBGP sessions. 
[WAJ]You just propose to add another one IB GP sessions. Can’t agree it will make the life of operator better.
> If you want to do local protection sure - but this is just your choice. I am not pushing you there. 
>  
>> And then every PE  router configure it is interested all the loopack addresses of other PEs?
> 
> What it is interested in is all dynamic - based on selected BGP next paths next hops. 
>  
> We are discussing pros and cons of the proposal(s). Specifically we are discussing where it works and where it does not. We are also discussing alternative solutions to solve a valid problem. 
> 
> Thx,
> R.