IETF Logo Mail Archive

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

Aijun Wang <wangaj3@chinatelecom.cn> Fri, 31 July 2020 00:37 UTC

Return-Path: <wangaj3@chinatelecom.cn>
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 0D04A3A12B9 for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 17:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 QAt3R8FwwJqi for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 17:37:35 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id ED72B3A12B7 for <lsr@ietf.org>; Thu, 30 Jul 2020 17:37:34 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.218:30250.2024328591
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-106.121.165.28?logid-b3a20e58f8d840a6a8d56778dc0e08e4 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id A0F8A280094; Fri, 31 Jul 2020 08:36:59 +0800 (CST)
X-189-SAVE-TO-SEND: 66040164@chinatelecom.cn
Received: from ([172.18.0.218]) by App0025 with ESMTP id b3a20e58f8d840a6a8d56778dc0e08e4 for lsr@ietf.org; Fri Jul 31 08:37:04 2020
X-Transaction-ID: b3a20e58f8d840a6a8d56778dc0e08e4
X-filter-score: filter<0>
X-Real-From: wangaj3@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: wangaj3@chinatelecom.cn
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaj3@chinatelecom.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 31 Jul 2020 08:37:18 +0800
Message-Id: <E214151D-333F-4F77-9B7B-B16420A5A64B@chinatelecom.cn>
References: <01982402-26D7-4B32-9EE1-593EDB2EE3FA@cisco.com>
Cc: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, Robert Raszuk <robert@raszuk.net>, lsr <lsr@ietf.org>, Huzhibo <huzhibo@huawei.com>, Xiaoyaqun <xiaoyaqun@huawei.com>, Aijun Wang <wangaijun@tsinghua.org.cn>
In-Reply-To: <01982402-26D7-4B32-9EE1-593EDB2EE3FA@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3IrnJkJ4P-kIHNbCNrDkhcXpejA>
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: Fri, 31 Jul 2020 00:37:38 -0000

Hi, Acee:

Aijun Wang
China Telecom

> On Jul 31, 2020, at 01:45, Acee Lindem (acee) <acee@cisco.com> wrote:
> 
> 
> On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)" <lsr-bounces@ietf.org on behalf of acee=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> 
>    On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org> wrote:
> 
>>        On 30/07/2020 18:03, Acee Lindem (acee) wrote:
>> So, how do we define a reachable route - is it any route subsumed by the summary LSA that we knew about in the past that becomes unreachable? When the PUA is withdrawn, how do we know whether it is because of expiration of the interval or the route becoming reachable again? This is a slippery slope.
> 
>        I'm not suggesting the unreachable stuff to affect forwarding in any way.

[WAJ] The ultimate aim of PUA is to notify the router to bypass the advertising ABR. If not affecting the forwarding, how to avoid the traffic black hole?

> 
>    That would be better. Also, as I stated offline, it would also be better to use encodings that would be ignored by routers that don't support the extension. I tried to dissuade the authors of PUA not to overload the prefix-originator LSA but was unsuccessful. 
> 
[WAJ] We can discuss this later.

> Of course, I meant prefix-originator Sub-TLV and the existing LSAs indicating reachability - https://www.ietf.org/id/draft-ietf-lsr-ospf-prefix-originator-06.txt
> 
> Thanks,
> Acee
> 
>    Thanks,
>    Acee
> 
>        thanks,
>        Peter
> 
> 
>> Thanks,
>> Acee
>> 
>> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak" <lsr-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org> wrote:
>> 
>>     On 30/07/2020 16:30, Robert Raszuk wrote:
>>> Hey Peter,
>>> 
>>> Not sure how smart you really want to be here but keep in mind that BGP
>>> say option C may never hear about it all the way to the egress PE in
>>> other domain or area ... It is almost always incongruent with IGP.
>>> 
>>> So if the BGP path is installed it will indeed be at risk to resolve via
>>> less specific when it is still active BGP path and you too quickly
>>> remove info about unreachability.
>> 
>>     again, if you are smart you can use this info to your advantage, even
>>     without putting it in the forwarding and leaving the less specific stuff
>>     intact.

v2.23.0 | Report a Bug | By Email