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? 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? 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.. Regards, Muthu On Fri, Mar 22, 2024 at 6:44 PM Peter Psenak <[email protected]> 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 [email protected]https://www.ietf.org/mailman/listinfo/lsr > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
