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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
