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

[Muthu Arul Mozhi Perumal <[e-mail]>]

Hi Peter,

Thanks for confirming my understanding. Please see inline..

On Tue, Apr 2, 2024 at 2:07 PM Peter Psenak <[e-mail]> wrote:

> 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.
>
yes, I meant BCP 14 (BGP was a typo), and changing it to uppercase sounds
good..

Regards,
Muthu

>
>
> 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 [e-mail]://www.ietf.org/mailman/listinfo/lsr
>>
>>
>>
>