Re: [Lsr] Is UPA expected to trigger BGP best path calculation?

[Peter Psenak <[e-mail]>]

Hi Muthu,

On 01/04/2024 09:42, Muthu Arul Mozhi Perumal wrote:
> Hi Peter,
>
> Thanks for your response..
>
> First, to confirm if I understood correctly:
> <snip>
> The intent of UPA is to provide an event driven signal of the 
> transition of a destination from reachable to unreachable. It is not 
> intended to advertise a persistent state. UPA advertisements should 
> therefore be withdrawn after a modest amount of time, that would 
> provides sufficient time for UPA to be flooded network-wide and acted 
> upon by receiving nodes, but limits the presence of UPA in the network 
> to a short time period. The time the UPA is kept in the network SHOULD 
> also reflect the intended use-case for which the UPA was advertised.
> </snip>
>
> The withdrawal of the UPA signal does not imply that the prefix is 
> reable again, instead only that the (unreachable) signal is not valid 
> anymore, correct?

correct

>
> Any reason why "should therefore be withdrawn" is not using a BGP 14 
> keyword while "The time the UPA is kept in the network SHOULD also 
> reflect the intended use-case" is?

what is BGP 14? Do you mean BCP 14? If yes, we will change to uppercase.


>
> While I agree that this draft is about IGP extension and the intended 
> use-case/behavior is local and outside the scope of this draft, there 
> are certain operational implications (both good and bad) of the choice 
> made by the receiver, especially whether or not to trigger BGP best 
> path based on UPA. I think this is better described in at least an 
> informational draft (just like how BGP PIC is) for both the 
> implementer and the operator to weigh the pros vs cons of the choices..

well, I tend to disagree here. But you are free to write such a draft of 
course. Here I would like to keep the IGP UPA draft agnostic to the BGP 
usage of the UPA signal.


thanks,

Peter

>
> Regards,
> Muthu
>
> On Fri, Mar 22, 2024 at 6:44 PM Peter Psenak <[e-mail]> wrote:
>
>     Muthu,
>
>     On 18/03/2024 10:41, Muthu Arul Mozhi Perumal wrote:
>>     Hi all,
>>
>>     draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge
>>     as one the use cases for UPA in the presence of summarization.
>>     However, it is not quite clear whether UPA is expected to trigger
>>     BGP best path calculation at the ingress PE (in addition to
>>     triggering BGP PIC) in spite of the BGP NH (or SRv6 locator as
>>     the case may be) being reachable through the summary route in
>>     RIB. Or should BGP wait for the service route to be withdrawn
>>     (say, by an RR having reachability to the egress PE) before
>>     triggering BGP best path?
>
>     UPA draft specifies the IGP signalling for unreachable prefix.
>
>     It does not specify how the UPA signal is used on the receiver.
>     The handling of the UPA is optional and implementation specific.
>
>>
>>     It looks either case would be problematic in case of a short flap
>>     in reachability for the BGP NH as detected by the egress ABR:
>>
>>       * If the ingress PE were to run the BGP best path on receiving
>>         UPA for the BGP NH, what would be the trigger to run another
>>         best path when the BGP NH becomes reachable again soon
>>         after, for reverting the traffic to the original NH? This is
>>         unlike using MH-BFD to detect the BGP NH reachability which
>>         can indicate both down/up. UPA on the other hand indicates
>>         only a down.
>>       * If the ingress PE were to rely on the service routes to be
>>         withdrawn/re-advertised, then what about scenarios where the
>>         BGP session is directly b/w the ingress and egress PEs? Is
>>         UPA not expected to be deployed in such scenarios?
>>
>
>>     There was a discussion earlier about the UP flag in the UPA
>>     advertisement triggering BGP best path:
>>     https://mailarchive.ietf.org/arch/msg/lsr/_qhlHBjQ8H-bLXtA6Nn4J7musjc/
>>
>>     Is this applicable also to the U flag?
>>
>>     I think it is difficult to realize the use case for UPA in an
>>     interoperable way without this clarity..
>
>
>     there is no interoperability needed for the handling of the UPA on
>     the receiver. Its a local behavior on the receiver.
>
>     thanks,
>     Peter
>
>>
>>     Regards,
>>     Muthu
>>
>>
>>
>>     _______________________________________________
>>     Lsr mailing list
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/lsr
>
>