The following sentence should be: > If it is planned, why the overlay service being switched over as scheduled?
If it is planned, why doesn’t the overlay service be switched over as scheduled? Aijun Wang China Telecom > On Mar 28, 2023, at 19:53, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > 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 >>> <ppsenak=40cisco....@dmarc.ietf.org> 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 >>>>> <shraddha=40juniper....@dmarc.ietf.org> 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 <lsr-boun...@ietf.org> *On Behalf Of *Robert Raszuk >>>> *Sent:* Monday, March 27, 2023 1:36 PM >>>> *To:* lsr <lsr@ietf.org> >>>> *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 >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
