HI Peter:

sure,we will cansider all the possible better solution.thanks for your 
suggestion.


zhibo

--------------------------------------------------
胡志波 Hu Zhibo
Mobile: +86-18618192287<tel:+86-18618192287>
Email: huzh...@huawei.com<mailto:huzh...@huawei.com>

发件人:Peter Psenak <ppse...@cisco.com>
收件人:Huzhibo <huzh...@huawei.com>;Aijun Wang <wang...@chinatelecom.cn>
抄 送:Aijun Wang <wangai...@tsinghua.org.cn>;lsr <lsr@ietf.org>;Xiaoyaqun 
<xiaoya...@huawei.com>
时 间:2020-07-30 21:32:45
主 题:Re: [Lsr] New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Hi Zhibo,

On 30/07/2020 15:18, Huzhibo wrote:
> HI Peter:
>
> 1:No problem is a problem that never can be proved.
>
> 2:For bgp example,when the pe node down,the bgp peer must down within
> 30 mintus,It will not get it up via cancle advertise pua.

for the above it is sufficient to advertise the unreachability for few
seconds from each ABR independently. That would be a much more solid
proposal.

thanks,
Peter


>
>
> ZHIBO
>
> --------------------------------------------------
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287 <tel:+86-18618192287>
> Email: huzh...@huawei.com <mailto:huzh...@huawei.com>
>
> *发件人:*Peter Psenak <ppse...@cisco.com>
> *收件人:*Huzhibo <huzh...@huawei.com>;Aijun Wang <wang...@chinatelecom.cn>
> *抄 送:*Aijun Wang <wangai...@tsinghua.org.cn>;lsr
> <lsr@ietf.org>;Xiaoyaqun <xiaoya...@huawei.com>
> *时 间:*2020-07-30 21:02:49
> *主 题:*Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
> Huzhibo,
>
> On 30/07/2020 14:49, Huzhibo wrote:
>>
>> Hi peter:
>>
>> 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.
>>> [HZB] The cyclic dependency does not occur. The PUA advertisement behavior 
>>> of an ABR is not affected by the transient status of other ABRs. The 
>>> condition for canceling PUA advertisement is that all ABRs advertise the 
>>> PUA information with a certain prefix for 30 minutes.
>
> you have not convinced me with the above statement. You are making a
> dependency on the ABR behavior based on the other ABRs' behavior. That's
> a call for a trouble.
>
>
>>>
>>>>
>>>>> 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.
>>> [HZB] There are two scenarios: First: The node is actually Down. In this 
>>> case, upper-layer services will be converged 30 minutes earlier.
>
> once you stop the unreachable advertisement, the resource will be seen
> as reachable outside of its area, even when it is down. That is a
> problem that you are trying to solve in a first place.
>
>
> thanks,
> Peter
>
> Even if the PUA is canceled, the problem will not occur. Second: If the
> node is not Down and only an ABR is unreachable, the ABR will
> continuously advertises PUA.
>>
>> 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