Aijun, IGP typically distributes transport reachability. So both U flag and UP flags seems useful to signal that such reachability has gone down or is soon to go down.
In fact IGPs carry so much other opaque stuff that actually those two flags seem pretty useful. Of course we can argue if this is optimal (see my other messages on UPA draft), but this is just a tool in the tool box. One size may not fit all and if we are building this tool my last exchange with Peter aimed to make it as useful as it can be. Personally today I would prefer to have a pub/sub model to distribute such info or carry it at the service layer. But that does not mean that tomorrow there may not be a valid use case for this extension (in specific topology(ies)). Thx, R. On Thu, Apr 24, 2025 at 1:59 AM Aijun Wang <[email protected]> wrote: > Hi, Robert: > > The “UP” I mentioned is the “UP-flag” that introduced in the WGLC > document, which is trying to put some maintenance information into the IGP > protocol, and should be avoided as declared by several persons already. > > There maybe many no harm information can be advised by the IGP, but that > is not the responsibility of IGP protocol. > > Aijun Wang > China Telecom > > On Apr 24, 2025, at 06:14, Robert Raszuk <[email protected]> wrote: > > > 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] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
