Re: [Lsr] Interdomain UPA & UP Flag
Most maintenance operations I have seen use ISIS overload with max metric advertise mechanism to Switch the overlay services to another node. While this mechanism works fine for MPLS environments that Leak the loopbacks across domains and in BGP-LU based environments, this mechanism is not Available in deployments that use summarized prefixes for reachability. Rgds Shraddha Juniper Business Use Only -Original Message- From: Aijun Wang Sent: Tuesday, March 28, 2023 4:32 PM To: Peter Psenak Cc: Shraddha Hegde ; Robert Raszuk ; lsr Subject: Re: [Lsr] Interdomain UPA & UP Flag [External Email. Be cautious of content] The following sentence should be: > If it is planned, why the overlay service being switched over as scheduled? If it is planned, why doesn’t the overlay service be switched over as scheduled? Aijun Wang China Telecom > On Mar 28, 2023, at 19:53, Aijun Wang wrote: > > There is no significant benefits to use the prefix unreachable announcement > mechanism to transfer the planned maintenance information. > > If it is planned, why the overlay service being switched over as scheduled? > > The PUA/UPA mechanism is mainly for the fast switchover of overlay services > upon the accident network failures. > > Please pay more attentions to other aspects of such mechanism. > > Aijun Wang > China Telecom > >>> On Mar 28, 2023, at 18:51, Peter Psenak >>> wrote: >>> >>> On 28/03/2023 11:41, Aijun Wang wrote: >>> There is already overload bit to accomplish the maintenance >>> purposes, Why do you guys repeat such work again? >> >> OL-bit is only propagated inside the area. We are solving >> inter-area/inter-domain routing convergence here. >> >> Peter >> >>> Aijun Wang >>> China Telecom >>>>> On Mar 28, 2023, at 18:00, Shraddha Hegde >>>>> wrote: >>>> >>>> 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 *On Behalf Of *Robert Raszuk >>>> *Sent:* Monday, March 27, 2023 1:36 PM >>>> *To:* lsr >>>> *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 >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>> sr__;!!NEt6yMaO-gk!FL0C5GIdGXqvoI4vgKh2djk4mgkPgInWxmoWOOpMb4mt7rBn >>>> QQ4e0rOGmZeNTkkGwpxGbwZ9jmR1cfW9YiEsw4uB$ >> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
The following sentence should be: > If it is planned, why the overlay service being switched over as scheduled? If it is planned, why doesn’t the overlay service be switched over as scheduled? Aijun Wang China Telecom > On Mar 28, 2023, at 19:53, Aijun Wang wrote: > > There is no significant benefits to use the prefix unreachable announcement > mechanism to transfer the planned maintenance information. > > If it is planned, why the overlay service being switched over as scheduled? > > The PUA/UPA mechanism is mainly for the fast switchover of overlay services > upon the accident network failures. > > Please pay more attentions to other aspects of such mechanism. > > Aijun Wang > China Telecom > >>> On Mar 28, 2023, at 18:51, Peter Psenak >>> wrote: >>> >>> On 28/03/2023 11:41, Aijun Wang wrote: >>> There is already overload bit to accomplish the maintenance purposes, >>> Why do you guys repeat such work again? >> >> OL-bit is only propagated inside the area. We are solving >> inter-area/inter-domain routing convergence here. >> >> Peter >> >>> Aijun Wang >>> China Telecom >>>>> On Mar 28, 2023, at 18:00, Shraddha Hegde >>>>> wrote: >>>> >>>> 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 *On Behalf Of *Robert Raszuk >>>> *Sent:* Monday, March 27, 2023 1:36 PM >>>> *To:* lsr >>>> *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 >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
There is no significant benefits to use the prefix unreachable announcement mechanism to transfer the planned maintenance information. If it is planned, why the overlay service being switched over as scheduled? The PUA/UPA mechanism is mainly for the fast switchover of overlay services upon the accident network failures. Please pay more attentions to other aspects of such mechanism. Aijun Wang China Telecom > On Mar 28, 2023, at 18:51, Peter Psenak > wrote: > > On 28/03/2023 11:41, Aijun Wang wrote: >> There is already overload bit to accomplish the maintenance purposes, >> Why do you guys repeat such work again? > > OL-bit is only propagated inside the area. We are solving > inter-area/inter-domain routing convergence here. > > Peter > >> Aijun Wang >> China Telecom >>>> On Mar 28, 2023, at 18:00, Shraddha Hegde >>>> wrote: >>> >>> 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 *On Behalf Of *Robert Raszuk >>> *Sent:* Monday, March 27, 2023 1:36 PM >>> *To:* lsr >>> *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 >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
On 28/03/2023 11:41, Aijun Wang wrote: There is already overload bit to accomplish the maintenance purposes, Why do you guys repeat such work again? OL-bit is only propagated inside the area. We are solving inter-area/inter-domain routing convergence here. Peter Aijun Wang China Telecom On Mar 28, 2023, at 18:00, Shraddha Hegde wrote: 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 *On Behalf Of *Robert Raszuk *Sent:* Monday, March 27, 2023 1:36 PM *To:* lsr *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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
There is already overload bit to accomplish the maintenance purposes, Why do you guys repeat such work again? Aijun Wang China Telecom > On Mar 28, 2023, at 18:00, Shraddha Hegde > wrote: > > > 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 On Behalf Of Robert Raszuk > Sent: Monday, March 27, 2023 1:36 PM > To: lsr > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
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 On Behalf Of Robert Raszuk Sent: Monday, March 27, 2023 1:36 PM To: lsr 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
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 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Interdomain UPA & UP Flag
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 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
[Lsr] Interdomain UPA & UP Flag
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
