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

[Peter Psenak <[e-mail]>]

Robert,

On 15/06/2022 14:47, Robert Raszuk wrote:
> Peter,
> 
> My question is precise .... your answer is pretty loose :)
> 
> Imagine I use summarization and as you many times said there is no BGP 
> running. So how do I indicate planned scheduled maintenance in such 
> cases ? Say from either ABRs or PEs/Ps itself ?

if nothing special is done, UPA will be triggered for prefixes that are 
advertised by the node which undergoes planned restart - as the 
reachable prefixes that are summarized will become unreachable as a 
result of the node going down.

> 
> In fact, looking practically that may be much more useful and needed 
> then signalling node failures.
> 
> And the issue I observed with using UPA is that as it is ephemeral it 
> may not work well during extended maintenance windows. Stateful 
> solutions however would work fine.

it works just fine for any node down case, being it a failure or planned 
maintenance. Traffic will initially switch to alternate path, if any, an 
later the native mechanism (BGP signalling, tunnel keepalive, etc), will 
take over and bring it to its final state.

thanks,
Peter

> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
> 
> On Wed, Jun 15, 2022 at 2:34 PM Peter Psenak <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Robert,
> 
>     On 15/06/2022 14:13, Robert Raszuk wrote:
>      > Peter,
>      >
>      >     the meaning of LSInfinity has been defined decades ago. No
>     matter how
>      >
>      >     much you may not like it, but it means unreachable.
>      >
>      >
>      > True. But that brings another question ... Do you envision to use
>     UPA
>      > also to indicate planned maintenance of a node ?
> 
>     depends on how the planned maintenance is performed. If yo just turn
>     the
>     node off, UPA will catch it. If you instead set OL-bit, or use link max
>     metric initially, it may or may not be used, depending on what the
>     ABR/ASBR is programmed to do. There is quite some flexibility if needed.
> 
>     thanks,
>     Peter
> 
> 
>      >
>      > Thx,
>      > R.
>      >
>