There is no significant benefits to use the prefix unreachable announcement mechanism to transfer the planned maintenance information.
If it is planned, why the overlay service being switched over as scheduled? The PUA/UPA mechanism is mainly for the fast switchover of overlay services upon the accident network failures. Please pay more attentions to other aspects of such mechanism. Aijun Wang China Telecom > On Mar 28, 2023, at 18:51, Peter Psenak <[email protected]> > wrote: > > On 28/03/2023 11:41, Aijun Wang wrote: >> There is already overload bit to accomplish the maintenance purposes, >> Why do you guys repeat such work again? > > OL-bit is only propagated inside the area. We are solving > inter-area/inter-domain routing convergence here. > > Peter > >> Aijun Wang >> China Telecom >>>> On Mar 28, 2023, at 18:00, Shraddha Hegde >>>> <[email protected]> wrote: >>> >>> Hi Robert, >>> >>> > Second, if you say this is needed for BGP free deployments then I >>> > question the merit on the basis that UPA is >ephemeral and expires say in >>> > 120 sec which will not be enough for most planned maintenance work. So if >>> > someone >insists to add UP Flag it should be not just a bit but also a >>> > time or time delta from set UTC where it is expected that >provided >>> > prefix will be down, >>> >>> That is a good point that there should be a max-time associated with >>> maintenance. >>> >>> I do not think that this needs to be signaled in IGP. It can be a local >>> configuration. >>> >>> Rgds >>> >>> Shraddha >>> >>> Juniper Business Use Only >>> >>> *From:* Lsr <[email protected]> *On Behalf Of *Robert Raszuk >>> *Sent:* Monday, March 27, 2023 1:36 PM >>> *To:* lsr <[email protected]> >>> *Subject:* [Lsr] Interdomain UPA & UP Flag >>> >>> *[External Email. Be cautious of content]* >>> >>> Hi, >>> >>> I would like to get more clarification in respect to extending External >>> LSAs for UPA. Area summary use case is pretty clear - but in case of >>> redistribution (typical src of external LSAs) IMO we are going way too far >>> with this. Let's all keep in mind that this is a pulse designed to trigger >>> upper protocol switchover. >>> >>> Needless to say that would work only via one hop by design as >>> redistribution happens via RIB and by definition of UPA unreachable routes >>> are not being installed in RIB in the first place. >>> >>> On the apparently relative terms I do not see a need for the UP Flag. First >>> planned maintenance should be solved by BGP protocol and there are already >>> a number of tools in BGP allowing one to do it. >>> >>> Second, if you say this is needed for BGP free deployments then I question >>> the merit on the basis that UPA is ephemeral and expires say in 120 sec >>> which will not be enough for most planned maintenance work. So if someone >>> insists to add UP Flag it should be not just a bit but also a time or time >>> delta from set UTC where it is expected that provided prefix will be down, >>> >>> Kind regards, >>> >>> R. >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
