Another data point about advertising more detailed reachability/unreachability: 
https://tools.ietf.org/html/draft-swallow-isis-detailed-reach-01

(for IPv6 some form of compression may be beneficial).

--Bruno

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, July 28, 2020 11:18 AM
To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>
Cc: Aijun Wang <wang...@chinatelecom.cn>; Zhibo Hu <huzh...@huawei.com>; Yaqun 
Xiao <xiaoya...@huawei.com>; lsr@ietf.org
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) 
<acee=40cisco....@dmarc.ietf.org<mailto: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<mailto:lsr-boun...@ietf.org> on behalf of 
wang...@chinatelecom.cn<mailto: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> 
[mailto:internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>]
    Sent: Monday, July 27, 2020 9:16 AM
    To: Zhibo Hu <huzh...@huawei.com<mailto:huzh...@huawei.com>>; Aijun Wang 
<wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>; Yaqun Xiao 
<xiaoya...@huawei.com<mailto: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<http://tools.ietf.org>.

    The IETF Secretariat



    _______________________________________________
    Lsr mailing list
    Lsr@ietf.org<mailto:Lsr@ietf.org>
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to