Hi Muthu,
On 01/04/2024 09:42, Muthu Arul Mozhi Perumal wrote:
Hi Peter,
Thanks for your response..
First, to confirm if I understood correctly:
<snip>
The intent of UPA is to provide an event driven signal of the
transition of a destination from reachable to unreachable. It is not
intended to advertise a persistent state. UPA advertisements should
therefore be withdrawn after a modest amount of time, that would
provides sufficient time for UPA to be flooded network-wide and acted
upon by receiving nodes, but limits the presence of UPA in the network
to a short time period. The time the UPA is kept in the network SHOULD
also reflect the intended use-case for which the UPA was advertised.
</snip>
The withdrawal of the UPA signal does not imply that the prefix is
reable again, instead only that the (unreachable) signal is not valid
anymore, correct?
correct
Any reason why "should therefore be withdrawn" is not using a BGP 14
keyword while "The time the UPA is kept in the network SHOULD also
reflect the intended use-case" is?
what is BGP 14? Do you mean BCP 14? If yes, we will change to uppercase.
While I agree that this draft is about IGP extension and the intended
use-case/behavior is local and outside the scope of this draft, there
are certain operational implications (both good and bad) of the choice
made by the receiver, especially whether or not to trigger BGP best
path based on UPA. I think this is better described in at least an
informational draft (just like how BGP PIC is) for both the
implementer and the operator to weigh the pros vs cons of the choices..
well, I tend to disagree here. But you are free to write such a draft of
course. Here I would like to keep the IGP UPA draft agnostic to the BGP
usage of the UPA signal.
thanks,
Peter
Regards,
Muthu
On Fri, Mar 22, 2024 at 6:44 PM Peter Psenak <ppse...@cisco.com> wrote:
Muthu,
On 18/03/2024 10:41, Muthu Arul Mozhi Perumal wrote:
Hi all,
draft-ietf-lsr-igp-ureach-prefix-announce mentions BGP PIC edge
as one the use cases for UPA in the presence of summarization.
However, it is not quite clear whether UPA is expected to trigger
BGP best path calculation at the ingress PE (in addition to
triggering BGP PIC) in spite of the BGP NH (or SRv6 locator as
the case may be) being reachable through the summary route in
RIB. Or should BGP wait for the service route to be withdrawn
(say, by an RR having reachability to the egress PE) before
triggering BGP best path?
UPA draft specifies the IGP signalling for unreachable prefix.
It does not specify how the UPA signal is used on the receiver.
The handling of the UPA is optional and implementation specific.
It looks either case would be problematic in case of a short flap
in reachability for the BGP NH as detected by the egress ABR:
* If the ingress PE were to run the BGP best path on receiving
UPA for the BGP NH, what would be the trigger to run another
best path when the BGP NH becomes reachable again soon
after, for reverting the traffic to the original NH? This is
unlike using MH-BFD to detect the BGP NH reachability which
can indicate both down/up. UPA on the other hand indicates
only a down.
* If the ingress PE were to rely on the service routes to be
withdrawn/re-advertised, then what about scenarios where the
BGP session is directly b/w the ingress and egress PEs? Is
UPA not expected to be deployed in such scenarios?
There was a discussion earlier about the UP flag in the UPA
advertisement triggering BGP best path:
https://mailarchive.ietf.org/arch/msg/lsr/_qhlHBjQ8H-bLXtA6Nn4J7musjc/
Is this applicable also to the U flag?
I think it is difficult to realize the use case for UPA in an
interoperable way without this clarity..
there is no interoperability needed for the handling of the UPA on
the receiver. Its a local behavior on the receiver.
thanks,
Peter
Regards,
Muthu
_______________________________________________
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
