Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Monday, July 27, 2020 9:16 AM
> To: Zhibo Hu <huzhibo@huawei.com>; Aijun Wang <wangaj3@chinatelecom.cn>; Yaqun Xiao <xiaoyaqun@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
> 
> 