Agree.

The possible scenario for UP flag is not the original intention of our 
discussion. 
We should abandon it and focus mainly on the other aspects of the solution.

Aijun Wang
China Telecom

> On Mar 27, 2023, at 17:06, Robert Raszuk <rob...@raszuk.net> 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. 
> 
> 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

Reply via email to