Aijun, Not sure what you mean by "UP" ... we are not talking about "up signalling".
Make-before-break is not philosophy but operational reality. And if the operator wants a solution to be contained in the IGP what I described will not hurt anyone. Sure operator may choose to deprefer service layer before planned maintenance and if so additional UPA signalling will do nothing - but will also not hurt anyone. Thx, R. On Thu, Apr 24, 2025 at 12:06 AM Aijun Wang <[email protected]> wrote: > Hi, Robert and all: > > “UP” is an unnecessary definition for one imaginary scenario——if > make-before-break is the philosophy, why the operator doesn’t switch over > in advance the planned maintenance egress PE to other available egress PE > on the ingress PE, instead to bother the IGP to accomplish such aim? > > Aijun Wang > China Telecom > > On Apr 23, 2025, at 22:51, Robert Raszuk <[email protected]> wrote: > > > > ok, I'm fine adding some text for your case. > > Thx Peter ! > > It is not "my use case" but ability to trigger UPA for make-before-break > which I think always is rather a good thing. > > Cheers, > R. > > > On Wed, Apr 23, 2025 at 4:40 PM Peter Psenak <[email protected]> wrote: > >> Hi Robert, >> >> On 23/04/2025 16:35, Robert Raszuk wrote: >> >> Hi Peter, >> >>> If the egress PE is the only BGP NH, then reacting to max-metric or >>> OL-bit set would make some BGP destinations unreachable. >>> >>> >> Well this entirely depends on how one reacts on UPA if UPA is signalling >> the only one left BGP path/NH as down irrespective of the trigger. Does it >> stop the service to the destination or not ... >> >> If there are alternate paths the best path can install new next hop. >> >> If there are no alternate paths I would rather keep one installed active >> - for example to address the case where one ABR can still reach egress PE >> and the other one generated UPA. >> >> So why not trigger UPA in such cases to hint him to switch to alternate >>> next hops if available ? >>> >>> I'm not saying it can not be done. The implementation can chose to >>> advertise the UPA for the summary component prefix if the such prefix >>> metric in the source area/domain crosses certain value or if the prefix >>> originator is overloaded. >>> >> But this would make it not compliant with current text in section 4 which >> was the main point of my question. So why not leave the door a bit open for >> it in the spec ? >> >> ok, I'm fine adding some text for your case. >> >> thanks, >> Peter >> >> >> >> Thx, >> R. >> >> >> _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
