Not sure I follow your below comment or how it relates to my deployment scenario ... I specifically said that 1.1.1.1/32 will be a negative route (there is "-" minus there) advertised in BGP.
If you mean that reception of negative routes in the presence of summary requires changes to RIB route tracking (or local RIB twist) it sure does. Thx, R. On Wed, Jul 29, 2020 at 10:07 AM Huzhibo <huzh...@huawei.com> wrote: > Hi Robert: > > > > BGP next hop validation can solve some but not all problems. In your > example, if PE1 has learned only 1.1.1.0/24 but not 1.1.1.1/32, BGP > cannot detect the reachability of 1.1.1.1/32. > > > > Thanks > > > > Zhibo Hu > > *From:* Robert Raszuk [mailto:rob...@raszuk.net] > *Sent:* Tuesday, July 28, 2020 5:18 PM > *To:* Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org> > *Cc:* Aijun Wang <wang...@chinatelecom.cn>; lsr@ietf.org; Huzhibo < > huzh...@huawei.com>; Xiaoyaqun <xiaoya...@huawei.com> > *Subject:* Re: [Lsr] New Version Notification for > draft-wang-lsr-prefix-unreachable-annoucement-03.txt > > > > Hello Acee, > > > > I would like to question your assessment that signalling unreachable > routes is unnecessary. > > > > Imagine hierarchical network with areas. Under no failures area 1 > advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's > loopbacks which within the area are /32s. Those loopbacks are also BGP next > hops. > > > > Now imagine PE1 with 1.1.1.1/32 fails. Well till BGP reconverges all > paths advertised by this PE with 1.1.1.1/32 are still valid as this next > hop is still reachable entire network wide. That means that traffic is > being sent to this failed PE1 for relatively long period of time. > > > > It seems natural that without breaking benefits of summarization across > areas or domains in the above scenario we could continue to advertise > 1.1.1.0/24 - 1.1.1.1/32. That is when I see most benefits of advertising > unreachability aka negative routing. > > > > Of course said all of the above - if you search your employer's archives - > you will see a proposal where the above mechanism can be done within BGP > itself with no touch to the IGP - just using a bit of twisted next hop > validation steps and BGP native recursion. I am not going to make any > judgements here which method is better or easier - naturally I personally > like BGP one more :). > > > > But I hope this is clear why at least discussion on the subject is > important. It also illustrates why the below statement is not > necessarily correct: > > > > "Note that the unreachability of a given summarized prefix is only > relevant if it is reachable through another ABR. " > > > > Kind regards, > Robert. > > > > > > On Mon, Jul 27, 2020 at 7:51 PM Acee Lindem (acee) <acee= > 40cisco....@dmarc.ietf.org> wrote: > > 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. 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. Note that the unreachability of a given > summarized prefix is only relevant if it is reachable through another ABR.. > In this case, the network design should provide adequate intra-area > redundancy to provide communications between the ABRs. If this cannot be > accomplished, an intra-area adjacency should be established over a tunnel > between the ABRs in the backbone. Contrary to section 6.1, Looping is > normally not a problem as ABRs should add back hole routes for their > advertised summaries. > > Acee > > On 7/26/20, 9:34 PM, "Lsr on behalf of Aijun Wang" <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: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Monday, July 27, 2020 9:16 AM > To: Zhibo Hu <huzh...@huawei.com>; Aijun Wang <wang...@chinatelecom.cn>; > Yaqun Xiao <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 > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > 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
