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
