Aijun,

On 30/07/2020 14:28, Aijun Wang wrote:
Hi, Peter:

Aijun Wang
China Telecom

On Jul 30, 2020, at 20:00, Peter Psenak <ppse...@cisco.com> wrote:

Hi Aijun,

On 30/07/2020 13:44, Aijun Wang wrote:
Hi, Peter:
Currently, we have the following consideration:
1. If not all of the ABRs announce the unreachability of the specified 
prefix(the specified prefix is still up), such PUA information will continue 
advertising by the unreachable ABRs.

so the behavior of ABR is going to be dependent on the behavior of the the 
other ABR(s)? That is a very thin ice you are dancing on.

[WAJ] it is easy for ABR to get these information and make the judgment. All 
ABRs locate within the same area.

having that info is not the issue. The cyclic dependency is the one.



2. If all of the ABRs announce the PUA of the specified prefix, such 
information will be announced for a configurable duration, to make sure other 
protocol(for example BGP) that based on the specified prefix has converged.

well, the problem is that no mater what is your configured time to advertise 
the un-reachability, you have no way of knowing whether the resource that 
became unreachable have done so intentionally and whether it will ever come 
back. And guessing based on the timer is not going to make it much better I'm 
afraid.


[WAJ] We need not care bout the reason for the unreachability. When ABR get the 
PUA information from also all other ABRs, it will start one timer to count the 
duration of following PUA message. After the duration, all ABRs will stop the 
advertisement.

once you stop advertising the un-reachability, you are back to square one as you were with the summary only.

thanks,
peter



thanks,
Peter


How about the above consideration and
Do you have other thoughts ?
Aijun Wang
China Telecom
On Jul 30, 2020, at 17:21, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> 
wrote:

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-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

Reply via email to