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

Peter Psenak <ppsenak@cisco.com> Thu, 30 July 2020 13:02 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434223A110B for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 06:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjUftqUdIQ70 for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 06:02:30 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9191C3A1105 for <lsr@ietf.org>; Thu, 30 Jul 2020 06:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7578; q=dns/txt; s=iport; t=1596114149; x=1597323749; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ws9VSxF5rQSLDjspLo5fhg+noZKYdjBGXRP8i3TgQ0U=; b=T05Y5DLcNTyOxiFZ/jRd0OSLqt7+iQOoFFHRSDEQn3cF7GwI07vRRtis AB6XKXfLlGkJVF4YPn769zREitEOHOcq5268tGeP/X6toWVvUGq957KLu vmMI4VohMiLTn1pqsluyVvVJlCxCSJI7qlzQuxUYFiEexCpvLFXQ2XIaX Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B1AAC4wyJf/xbLJq1gGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUqDGVQBIBIshDWJAYdyJZokgWkLAQEBDhgNCgQBAYRMAoIsJTgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBAEBGwYPAQUzAwkCDAQLEQQBAQECAiMDAgInHwkIBgEMBgIBAReDCwGCfA+uanaBMoQ/Ag5BQoM9gUCBDioBiQeEH4FBP4ERJwyBX34+glwBAQIBARWBHg6DMIJgBI8yBCWKFpsRgQWCaYMKhVGOQIJYBQcDHoJ7gSKIKYUFjimBKIwzhESKM5UUgWojgVczGggbFRohgmkJRxkNjisXFIhOhUQ/AzACNQIGAQcBAQMJjkcBAySCHgEB
X-IronPort-AV: E=Sophos;i="5.75,414,1589241600"; d="scan'208";a="28352711"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2020 13:02:25 +0000
Received: from [10.61.192.80] ([10.61.192.80]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 06UD2OGv001542; Thu, 30 Jul 2020 13:02:25 GMT
To: Huzhibo <huzhibo@huawei.com>, Aijun Wang <wangaj3@chinatelecom.cn>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "lsr@ietf.org" <lsr@ietf.org>, Xiaoyaqun <xiaoyaqun@huawei.com>
References: <b85c277f-07d2-f40d-071d-295512ea7c73@cisco.com> <B1061E81-F9B6-4647-B5D6-B97D67C4AD8E@chinatelecom.cn> <fc0369b2-6f76-48f1-2c0e-e218e6db5e7b@cisco.com> <06CF729DA0D6854E8C1E5121AC3330DFAF71770C@dggemm509-mbx.china.huawei.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <43f707e5-4409-670f-0983-0c672da53ecb@cisco.com>
Date: Thu, 30 Jul 2020 15:02:24 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <06CF729DA0D6854E8C1E5121AC3330DFAF71770C@dggemm509-mbx.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.61.192.80, [10.61.192.80]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ib48KkCZqJlGXXGd-rQ4A_USegc>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 13:02:35 -0000

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 <ppsenak@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.com@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-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
>>>>>
>>>>> _______________________________________________
>>>>> Lsr mailing list
>>>>> Lsr@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>
>>
>>
> 
> 
>