Hi Peter, While perhaps one could argue on the benefits for UPA in single domain IMO the same benefits hardly apply in multi-domain case.
Reason being that this is just a pulse and whatever event (and local domain flooding) triggered UPA it should be able to also trigger withdrawal of service routes from BGP. Those can be aggregated or even atomic - no issue. Note that there were valid concerns in respect to flooding UPA domain wide where there is network failure triggering it. Now we are talking about triggering a much wider UPA storm as response to local failure. That is especially worrying as you do not even know if all domains even need such information. Clearly a lot of thinking needs to go into this in terms of policy for triggering UPAs or propagating it across domains. Last note that some large multi domain networks I know even if using option C for L3VPNs still go via BGP + Label between ASBRs to propagate all next hops with labels from IGP+LDP to BGP(3107) and back to IGP+LDP as natively IGPs do not carry LDP labels. SR-MPLS fixes that, but then you are running to domains with different IGPs issues and I do not see anything in the draft which would allow you to take UPA from OSPF domain and inject it into ISIS core domain then back to OSPF on the remote domain. Bottom line: sure you can burn a few more codepoints to fix the space for it. But I think interdomain UPA requires much more work to be of any practical value and if really needed deserves a standalone doc. Many thx, Robert On Mon, Mar 27, 2023 at 1:39 AM Peter Psenak <[email protected]> wrote: > Hi Robert, > > On 27/03/2023 10:05, Robert Raszuk wrote: > > 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. > > there are two cases we need to distinguish: > > 1. ASBR is redistributing routes and creating a summary out of that. In > such case the ASBR may create the UPA for a summarized prefix for which > it lost reachability in the source domain. > > 2. UPA as such is crossing multiple domains with redistribution. > The fact that UPA is not installed in forwarding does not mean it can > not be redistributed. How that is done is an implementation detail. The > whole redistribution is implementation specific. > > I let others co-authors to respond to the below, as I'm not entirely > convinced we need the UP-flag. > > thanks, > Peter > > > > > 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
