Hi Les, Pls see inline for replies.
Juniper Business Use Only -----Original Message----- From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Sent: Tuesday, March 28, 2023 9:10 AM To: Shraddha Hegde <shrad...@juniper.net>; lsr@ietf.org Subject: UPA and planned/unplanned signalling [External Email. Be cautious of content] Shraddha - To follow up on our discussion over chat at the LSR meeting yesterday... At a remote ABR, if BGP had already been told about a planned node maintenance event (by means that is outside the scope of the UPA draft), then BGP would have moved traffic away from the node on which the maintenance event is scheduled in advance of the arrival of the UPA advertisement. In such a case the arrival of the UPA advertisement would be of no significance. Since traffic has already moved away it does not matter whether BGP processes the UPA or does not. If, however, BGP had NOT been told about planned maintenance in advance, the arrival of the UPA should be treated in the same way regardless of whether the trigger was a planned maintenance event or not. The node associated with the address advertised in the UPA has become unreachable and BGP needs to act accordingly. <SH> This is the case when BGP is not aware of the planned maintenance and is learning that info from IGP. You are right that the final outcome of the planned maintenance vs unreachability is same that the traffic needs to be moved away >From the remote PE. The difference is in how that is achieved. In case of >unreachability, the action need to be immediate and mechanisms such as BGP-PIC >needed. In case of planned maintenance, it would just be costing out Igp metric for the PE and hence the control plane convergence. There may be implementations which just choose to trigger one mechanisms for both scenarios and draft does not Mandate/suggest any of this and is left to implementations. I therefore see no value add in differentiating between planned/unplanned in the UPA advertisement. I hope this is clear. Please point out what I might have missed. Thanx. Les _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
