Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
Hi, Gunter: Thanks for your deep considerations for the partition scenarios although it is one rarely event I the network. Regarding to your statements, one point I want to correct is that in the mentioned scenario, R2 is also detached from R4 in area 2. This is the reason that only R2 sends out the PUA message, or else, if R2 can reach Pt2 via R4, it shouldn’t send out the PUA for Pt2. So, in this scenario, R4 and R2 can only exchange the LSA in area 0. When R2 receive the specific detail prefix for Pt2 from R4, it just install this specific route into its routing table as usual behavior——The PUA messages that it advertised has already stopped—-as noted in the draft, the PUA message only last one short time to assist the service convergence. Regarding to your churn concerns, as discussed before on the list, not every link failure will cause the PUA advertisement, this can be configured on the ABR. Currently, we interest mainly the node’s reachability(that is, the loopback addresses of the routers). Aijun Wang China Telecom > On Jun 21, 2022, at 20:40, Van De Velde, Gunter (Nokia - BE/Antwerp) > wrote: > > > wrt partitioned area’s and UPA’s. The wang PUA draft has an interesting > proposal for assuring that even with UPAs and partitioned area’s > non-conflicting information exist. > The solution proposal does come at cost of increased ISIS churn. This could > be an acceptable cost, especially considering that UPAs will only appear by > exception and even more rare in combination with area partitioning. > > Lets consider the following (based upon section “3.2 from > draft-wang-lsr-prefix-unreachable”): > > For ISIS, R2 L1/L2 would advertise the PUA for Pt2. > R4 L1/L2 router receives the L2 PUA route for Pt2 and because it is also > summarizing Pt2 from L1, it now decides to advertise a specific route to Pt2. > R2 now sees that R4 advertises a specific route for Pt2 and programs Pt2 next > hop to R4. This will stop the PUA advertisement on R2 immediately. > > Although this enhancement as described is in the > draft-wang-lsr-prefix-unreachable draft it should work with > draft-ppsenak-lsr-igp-ureach-prefix. A side effect is more churn. > This setup where R2 and R4 only see each other in L2 causes a lot of churn as > a PUA needs to be advertised for Pt2 and all downstream routes of T2. > On top , R4 now advertises specific route for each of the PUA’s and a bit > later R2 floods the same LSPs again but without the PUA’s. > > > *** > +-+--++-+--+ > | +--++--+ ++-+ ++-++-++ + -++--+| > | |S1++S2+---+R1+---|R0++R2+---+T1++T2|| > | +-++Ps1 +-++ ++-+ +--++-++ Pt2 +-++| > | | | | | || | | > | | | | | || | | > | | | | L2 || | | > | | | | | || | | > | +-++Ps4 +-++ ++-+ +-++ Pt4+-++| > | |S4++S3+---+R3+---+R4+---+T3++T4|| > | +--++--+ ++-+ +-++ ++-++--+| > | | || > | | || > | | ISIS L2 | ISIS L1 | > +-+---++ > > Inter-Area Prefix Unreachable Announcement Scenario > > > 3.2. Inter-Area Links Failure Scenario > >In a link failure scenario, if the link between T1/T2 and T1/T3 are >down, R2 will not be able to reach node T2. But as R2 and R4 do the >summary announcement, and the summary address covers the bgp next hop >prefix of Pt2, other nodes in area 0 area 1 will still send traffic >to T2 bgp next hop prefix Pt2 via the border router R2, thus black >hole sink routing the traffic. > >In such a situation, the border router R2 should notify other routers >that it can't reach the prefix Pt2, and lets the other ABRs(R4) that >can reach prefix Pt2 advertise one specific route to Pt2, then the >internal routers will select R4 as the bypass router to reach prefix >Pt2. > *** > > G/ > > > -Original Message- > From: Peter Psenak > Sent: Thursday, June 16, 2022 12:04 PM > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > ; Gyan Mishra ; Voyer, > Daniel > Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; > draft-wang-lsr-prefix-unreachable-annoucement > ; lsr@ietf.org > Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering? > > Hi Gunter, > > please see inline (##PP): > > On 16/06/2022 10:09, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > > Hi Gyan, Daniel, Peter, All, > > > > Thanks for sharing your insights and I agree mostly with your feedback
Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
wrt partitioned area’s and UPA’s. The wang PUA draft has an interesting proposal for assuring that even with UPAs and partitioned area’s non-conflicting information exist. The solution proposal does come at cost of increased ISIS churn. This could be an acceptable cost, especially considering that UPAs will only appear by exception and even more rare in combination with area partitioning. Lets consider the following (based upon section “3.2 from draft-wang-lsr-prefix-unreachable”): For ISIS, R2 L1/L2 would advertise the PUA for Pt2. R4 L1/L2 router receives the L2 PUA route for Pt2 and because it is also summarizing Pt2 from L1, it now decides to advertise a specific route to Pt2. R2 now sees that R4 advertises a specific route for Pt2 and programs Pt2 next hop to R4. This will stop the PUA advertisement on R2 immediately. Although this enhancement as described is in the draft-wang-lsr-prefix-unreachable draft it should work with draft-ppsenak-lsr-igp-ureach-prefix. A side effect is more churn. This setup where R2 and R4 only see each other in L2 causes a lot of churn as a PUA needs to be advertised for Pt2 and all downstream routes of T2. On top , R4 now advertises specific route for each of the PUA’s and a bit later R2 floods the same LSPs again but without the PUA’s. *** +-+--++-+--+ | +--++--+ ++-+ ++-++-++ + -++--+| | |S1++S2+---+R1+---|R0++R2+---+T1++T2|| | +-++Ps1 +-++ ++-+ +--++-++ Pt2 +-++| | | | | | || | | | | | | | || | | | | | | L2 || | | | | | | | || | | | +-++Ps4 +-++ ++-+ +-++ Pt4+-++| | |S4++S3+---+R3+---+R4+---+T3++T4|| | +--++--+ ++-+ +-++ ++-++--+| | | || | | || | | ISIS L2 | ISIS L1 | +-+---++ Inter-Area Prefix Unreachable Announcement Scenario 3.2. Inter-Area Links Failure Scenario In a link failure scenario, if the link between T1/T2 and T1/T3 are down, R2 will not be able to reach node T2. But as R2 and R4 do the summary announcement, and the summary address covers the bgp next hop prefix of Pt2, other nodes in area 0 area 1 will still send traffic to T2 bgp next hop prefix Pt2 via the border router R2, thus black hole sink routing the traffic. In such a situation, the border router R2 should notify other routers that it can't reach the prefix Pt2, and lets the other ABRs(R4) that can reach prefix Pt2 advertise one specific route to Pt2, then the internal routers will select R4 as the bypass router to reach prefix Pt2. *** G/ -Original Message- From: Peter Psenak Sent: Thursday, June 16, 2022 12:04 PM To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; Gyan Mishra ; Voyer, Daniel Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; draft-wang-lsr-prefix-unreachable-annoucement ; lsr@ietf.org Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering? Hi Gunter, please see inline (##PP): On 16/06/2022 10:09, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Gyan, Daniel, Peter, All, > > Thanks for sharing your insights and I agree mostly with your feedback > > I agree and understand that summarization is needed to reduce the size > of the LSDB. I also agree summarization good design practice, > especially with IPv6 and SRv6 in mind. There never has been doubt about that. > > I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is > the best we can do, however I have a healthy worry we could be > suffering tunnel vision and that proposed solution may not be good enough. > > We should not be blind and believe that advertising UPA/PUA does not > come without a cost. The architectural PUA/UPA usage complexity cost > may not be worth the effort (none of the integration of using a > PUA/UPA event triggers come for free). Do we really believe that > PUA/UPA solve all the SID reachability problems for all IGP network > design and SR use-cases elegantly? Maybe some use-case design > constraints and assumptions should be documented to clarify > architecturally where PUA/UPA is most beneficial for operators? Just > stating “outside scope of the draft” seems unfair to operators > interested in PUA/UPAs ##PP we are trying to solve a particular problem of remote PE going down in network where summarization is used. I believe that is stated clearly in the UPA draft. > > Let me give two examples where PUA/UPA benefit is unclear: > > (1) Multiple-ABRs > > I
