Most maintenance operations I have seen use ISIS overload with max metric advertise mechanism to Switch the overlay services to another node. While this mechanism works fine for MPLS environments that Leak the loopbacks across domains and in BGP-LU based environments, this mechanism is not Available in deployments that use summarized prefixes for reachability.
Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Aijun Wang <[email protected]> Sent: Tuesday, March 28, 2023 4:32 PM To: Peter Psenak <[email protected]> Cc: Shraddha Hegde <[email protected]>; Robert Raszuk <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Interdomain UPA & UP Flag [External Email. Be cautious of content] 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 <[email protected]> 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 >>> <[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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>> sr__;!!NEt6yMaO-gk!FL0C5GIdGXqvoI4vgKh2djk4mgkPgInWxmoWOOpMb4mt7rBn >>>> QQ4e0rOGmZeNTkkGwpxGbwZ9jmR1cfW9YiEsw4uB$ >> _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
