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:[email protected]]
Sent: Tuesday, July 28, 2020 5:18 PM
To: Acee Lindem (acee) <[email protected]>
Cc: Aijun Wang <[email protected]>; [email protected]; Huzhibo
<[email protected]>; Xiaoyaqun <[email protected]>
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<http://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<http://1.1.1.1/32> fails. Well till BGP
reconverges all paths advertised by this PE with 1.1.1.1/32<http://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<http://1.1.1.0/24> - 1.1.1.1/32<http://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)
<[email protected]<mailto:[email protected]>> 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"
<[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> 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]>
[mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, July 27, 2020 9:16 AM
To: Zhibo Hu <[email protected]<mailto:[email protected]>>; Aijun Wang
<[email protected]<mailto:[email protected]>>; Yaqun Xiao
<[email protected]<mailto:[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<http://tools.ietf.org>.
The IETF Secretariat
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
