Hi, Acee: Let me try to answer your concerns.
Please see the below inline. If I missed your comments, please correct me. Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Tuesday, July 28, 2020 1:51 AM To: Aijun Wang <wang...@chinatelecom.cn>; lsr@ietf.org Cc: 'Zhibo Hu' <huzh...@huawei.com>; 'Yaqun Xiao' <xiaoya...@huawei.com> Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt Speaking as an LSR Working Group member: Asking the WG precisely how to advertise prefix unreachability is the wrong question - it is analogous to asking whether to use a car or truck to drive off the edge of a cliff. [WAJ] Let’s confirm it is not cliff J, but traffic black hole that should be notified and repaired. Rather than messing up OSPF and IS-IS with these complex and unnecessary mechanisms, it would be better to address the requirement in your network design. [WAJ] section 3 of this draft <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-3> has demonstrated the problem/scenarios that needs to be addressed. We think this will be normal phenomena in the IPv6 era. Note that the unreachability of a given summarized prefix is only relevant if it is reachable through another ABR. [WAJ] it is not the unreachability of a given summarized prefix, but the more specific prefix that within the summary address. In this case, the network design should provide adequate intra-area redundancy to provide communications between the ABRs. [WAJ] Even there is adequate intra-area redundancy communication between the ABRs, the failure of one specific prefix within the summary address that advertised by the ABR will lead to traffic black hole. If this cannot be accomplished, an intra-area adjacency should be established over a tunnel between the ABRs in the backbone. [WAJ] Section 6.1 introduces the tunnel solution to redirect the traffic to another ABR, when such ABR router can reach the specified prefix. But this additional mechanism will be used only when the ABR all reach the PUA limit. If not, the PUA mechanism described in section 4 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-03#section-4> can be used to guide the traffic. Contrary to section 6.1, Looping is normally not a problem as ABRs should add back hole routes for their advertised summaries. [WAJ] Yes, you are right. Normally the ABR will drop the traffic that it can’t reach. But there is situation that when the tunnel that is pre-established among ABRs, and each tunnel claim it can reach the specified prefix, the traffic loop may arise if the received ABR send traffic via another tunnel. Acee On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" < <mailto:lsr-boun...@ietf.org%20on%20behalf%20of%20wang...@chinatelecom.cn> lsr-boun...@ietf.org on behalf of wang...@chinatelecom.cn> 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: <mailto:internet-dra...@ietf.org> internet-dra...@ietf.org [ <mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org] Sent: Monday, July 27, 2020 9:16 AM To: Zhibo Hu < <mailto:huzh...@huawei.com> huzh...@huawei.com>; Aijun Wang < <mailto:wang...@chinatelecom.cn> wang...@chinatelecom.cn>; Yaqun Xiao < <mailto:xiaoya...@huawei.com> xiaoya...@huawei.com> 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> 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/> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ Htmlized: <https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-03> 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> 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> 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 <mailto:Lsr@ietf.org> Lsr@ietf.org <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list <mailto:Lsr@ietf.org> Lsr@ietf.org <https://www.ietf.org/mailman/listinfo/lsr> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
