Hi peter： On 30/07/2020 14:28, Aijun Wang wrote: > Hi, Peter: > > Aijun Wang > China Telecom > >> On Jul 30, 2020, at 20:00, Peter Psenak <[email protected]> wrote: >> >> Hi Aijun, >> >>> On 30/07/2020 13:44, Aijun Wang wrote: >>> Hi, Peter: >>> Currently, we have the following consideration: >>> 1. If not all of the ABRs announce the unreachability of the specified >>> prefix(the specified prefix is still up), such PUA information will >>> continue advertising by the unreachable ABRs. >> >> so the behavior of ABR is going to be dependent on the behavior of the the >> other ABR(s)? That is a very thin ice you are dancing on. > > [WAJ] it is easy for ABR to get these information and make the judgment. All > ABRs locate within the same area.
having that info is not the issue. The cyclic dependency is the one. > [HZB] The cyclic dependency does not occur. The PUA advertisement behavior of > an ABR is not affected by the transient status of other ABRs. The condition > for canceling PUA advertisement is that all ABRs advertise the PUA > information with a certain prefix for 30 minutes. > >> >>> 2. If all of the ABRs announce the PUA of the specified prefix, such >>> information will be announced for a configurable duration, to make sure >>> other protocol(for example BGP) that based on the specified prefix has >>> converged. >> >> well, the problem is that no mater what is your configured time to advertise >> the un-reachability, you have no way of knowing whether the resource that >> became unreachable have done so intentionally and whether it will ever come >> back. And guessing based on the timer is not going to make it much better >> I'm afraid. >> > > [WAJ] We need not care bout the reason for the unreachability. When ABR get > the PUA information from also all other ABRs, it will start one timer to > count the duration of following PUA message. After the duration, all ABRs > will stop the advertisement. once you stop advertising the un-reachability, you are back to square one as you were with the summary only. > [HZB] There are two scenarios: First: The node is actually Down. In this > case, upper-layer services will be converged 30 minutes earlier. Even if the > PUA is canceled, the problem will not occur. Second: If the node is not Down > and only an ABR is unreachable, the ABR will continuously advertises PUA. thanks, peter > > >> thanks, >> Peter >> >> >>> How about the above consideration and Do you have other thoughts ? >>> Aijun Wang >>> China Telecom >>>>> On Jul 30, 2020, at 17:21, Peter Psenak >>>>> <[email protected]> wrote: >>>> >>>> Hi Ajun, >>>> >>>> one additional problem on top of others that have been mentioned is >>>> how are you going to get rid of "old" un-reachability >>>> announcements/ >>>> >>>> Let's imagine you have the following prefixes in your area 1: >>>> >>>> - 10.10.0.1/32 - 10.0.0.255/32 - used for loopback adresses >>>> - 10.10.1.0/30 - 10.10.10.252/32 - used for transit links >>>> >>>> For simplicity your summary for area 1 is 10.0.0.0/16 >>>> >>>> 1. Everything is up, you generate 10.0.0.0/16 on the ABR that >>>> connects to area 1 to all remaining connected areas >>>> >>>> 2. A router in area 1 with loopback 10.10.0.25/32 goes down. >>>> >>>> 3. ABR in area 1 generates un-reachable announcement for >>>> 10.0.0.25/32 to all other connected areas >>>> >>>> 4. When does ABR stop generating the un-reachable announcement for >>>> 10.0.0.25/32? In section 6 you mention that "The receiver router should >>>> keep the black hole routes for PUA as one configurable time(MAX_T_PUA)", >>>> but the draft does not say anything about when the un-reachability >>>> announcements should be removed by ABR. We can not rely on 10.10.0.25/32 >>>> ever coming back, as the user may have simply removed it for good. Keeping >>>> the "stale" un-reachability announcements may result in the LSDB growth >>>> over the period of time. >>>> >>>> >>>> thanks, >>>> Peter >>>> >>>> >>>> >>>> >>>>> On 27/07/2020 03:32, Aijun Wang wrote: >>>>> Hi, LSR experts: >>>>> We have uploaded the new version of this PUA(Prefix Unreachable >>>>> Announcement) draft. The main updates are the followings: >>>>> 1) Describes the solution that using tunnel to redirect traffic among >>>>> ABRs, when all ABRs reaches the PUA limit. >>>>> 2) Describe fast rerouting to avoid routing black hole. >>>>> 3) Defining PUA capabilities announcements for OSPFv2/OSPFv3 and ISIS. >>>>> There are also some arguments about the current solution for PUA, for >>>>> example: >>>>> 1) Is it suitable to set the "Prefix Originator" sub-TLV to NULL to >>>>> indicate the prefix is unreachable? >>>>> 2) if not, what's the consideration? What's the other convincible >>>>> solution? >>>>> Wish to hear comments and suggestions on the above issues. We will also >>>>> have the presentation on the coming IETF LSR meeting. >>>>> Best Regards >>>>> Aijun Wang >>>>> China Telecom >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] >>>>> Sent: Monday, July 27, 2020 9:16 AM >>>>> To: Zhibo Hu <[email protected]>; Aijun Wang >>>>> <[email protected]>; Yaqun Xiao <[email protected]> >>>>> Subject: New Version Notification for >>>>> draft-wang-lsr-prefix-unreachable-annoucement-03.txt >>>>> A new version of I-D, >>>>> draft-wang-lsr-prefix-unreachable-annoucement-03.txt >>>>> has been successfully submitted by Aijun Wang and posted to the IETF >>>>> repository. >>>>> Name: draft-wang-lsr-prefix-unreachable-annoucement >>>>> Revision: 03 >>>>> Title: Prefix Unreachable Announcement >>>>> Document date: 2020-07-27 >>>>> Group: Individual Submission >>>>> Pages: 11 >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-wang-lsr-prefix-unreachable-annoucement-03.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03 >>>>> Htmlized: >>>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement >>>>> Diff: >>>>> https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-03 >>>>> Abstract: >>>>> This document describes the mechanism that can be used to announce >>>>> the unreachable prefixes for service fast convergence. >>>>> >>>>> Please note that it may take a couple of minutes from the time >>>>> of submission until the htmlized version and diff are available at >>>>> tools.ietf.org. >>>>> The IETF Secretariat >>>>> _______________________________________________ >>>>> Lsr mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lsr >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lsr >> > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
