Hi Peter, Thanks for confirming my understanding. Please see inline..
On Tue, Apr 2, 2024 at 2:07 PM Peter Psenak <[email protected]> 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 <[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
