HI Peter： sure，we will cansider all the possible better solution.thanks for your suggestion.
zhibo -------------------------------------------------- 胡志波 Hu Zhibo Mobile: +86-18618192287<tel:+86-18618192287> Email: [email protected]<mailto:[email protected]> 发件人：Peter Psenak <[email protected]> 收件人：Huzhibo <[email protected]>;Aijun Wang <[email protected]> 抄 送：Aijun Wang <[email protected]>;lsr <[email protected]>;Xiaoyaqun <[email protected]> 时 间：2020-07-30 21:32:45 主 题：Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt Hi Zhibo, On 30/07/2020 15:18, Huzhibo wrote: > HI Peter： > > 1：No problem is a problem that never can be proved. > > 2：For bgp example，when the pe node down，the bgp peer must down within > 30 mintus，It will not get it up via cancle advertise pua. for the above it is sufficient to advertise the unreachability for few seconds from each ABR independently. That would be a much more solid proposal. thanks, Peter > > > ZHIBO > > -------------------------------------------------- > 胡志波 Hu Zhibo > Mobile: +86-18618192287 <tel:+86-18618192287> > Email: [email protected] <mailto:[email protected]> > > *发件人：*Peter Psenak <[email protected]> > *收件人：*Huzhibo <[email protected]>;Aijun Wang <[email protected]> > *抄 送：*Aijun Wang <[email protected]>;lsr > <[email protected]>;Xiaoyaqun <[email protected]> > *时 间：*2020-07-30 21:02:49 > *主 题：*Re: [Lsr] New Version Notification for > draft-wang-lsr-prefix-unreachable-annoucement-03.txt > > Huzhibo, > > On 30/07/2020 14:49, Huzhibo wrote: >> >> 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. > > you have not convinced me with the above statement. You are making a > dependency on the ABR behavior based on the other ABRs' behavior. That's > a call for a trouble. > > >>> >>>> >>>>> 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. > > once you stop the unreachable advertisement, the resource will be seen > as reachable outside of its area, even when it is down. That is a > problem that you are trying to solve in a first place. > > > thanks, > Peter > > 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
