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

Peter Psenak <ppsenak@cisco.com> Thu, 30 July 2020 16:17 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 1EFC73A0BB6 for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 09:17:54 -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 HMGbLHODR6l4 for <lsr@ietfa.amsl.com>; Thu, 30 Jul 2020 09:17:52 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA8B3A0B98 for <lsr@ietf.org>; Thu, 30 Jul 2020 09:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2781; q=dns/txt; s=iport; t=1596125871; x=1597335471; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=eKPApEpkUvB0sr4DGexhWr1aCsi95XPPCAbUPsLlgUk=; b=bnllq9Zg33BryMqBiJ4vfIbhUmiiXBG5XIqU4ELSvp7ZugyZRHJkeuG/ 9m8QpfZmUNz8IlD6UxRxMCjZ40exCnuC+E/meuWTi5VEc5rRZWrxJ1VWA o4wwUW+yoPE0D2cELxOeKaqgCiPriS3sYuHkpjWnvThHc2UOHdtocA6JP 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AfAAA38SJf/xbLJq1gGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgTkBAQEBAQELAYF6gR5UASASLIQ1iQGHcSWcDQsBAQEOGAsMBAEBhEwCgi8lNwYOAgMBAQsBAQUBAQECAQYEbYUvByYMhXEBAQEDAQEBIQ8BBTYJAgULCxgCAiMDAgInHxEGAQwGAgEBgyIBglwgD69rdoEyhVKDQ4E6BoEOKgGNJoFBP4ERJwyCXT6CXAEBAoRzgmAEkjKjVYJpgwqWaQUHAx6RS44pgSiMM4REn0eBaSSBVzMaCBsVO4JpUBkNiBOGQ24BCYdWhUQ/AzACNQIGAQcBAQMJkFgBAQ
X-IronPort-AV: E=Sophos;i="5.75,415,1589241600"; d="scan'208";a="28354834"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2020 16:17:47 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 06UGHkEH032615; Thu, 30 Jul 2020 16:17:47 GMT
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, Robert Raszuk <robert@raszuk.net>
Cc: Aijun Wang <wangaj3@chinatelecom.cn>, Xiaoyaqun <xiaoyaqun@huawei.com>, Huzhibo <huzhibo@huawei.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, lsr <lsr@ietf.org>
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> <43f707e5-4409-670f-0983-0c672da53ecb@cisco.com> <96779843-a40d-e83b-8d24-baeb6c8648ea@cisco.com> <CAOj+MME7ADcnxe-m0JJ-EpWCzczhC6O8QY5xrxDQRA0w3aRGjQ@mail.gmail.com> <2a6844df-59ed-ca91-c306-d2288c44a1dc@cisco.com> <CAOj+MMFGJeNXsGgeram4uVaO5aDvQUTRbWL9N91NbQHvgP7M+A@mail.gmail.com> <9fa84c34-e3f5-42bd-2b6b-20a114acf3b3@cisco.com> <BFB12E8C-8B18-4658-BC2F-4065CCB5C492@cisco.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <90eec7d2-301a-0762-6a5c-606c142548cd@cisco.com>
Date: Thu, 30 Jul 2020 18:17:46 +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: <BFB12E8C-8B18-4658-BC2F-4065CCB5C492@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_SRCH-HOarQDiM_9eRBOsc0Qfc4>
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 16:17:54 -0000

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.

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.
> 
>      Peter
> 
> 
>      >
>      > Thx
>      > R.
>      >
>      > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak <ppsenak@cisco.com
>      > <mailto:ppsenak@cisco.com>> wrote:
>      >
>      >     On 30/07/2020 16:14, Robert Raszuk wrote:
>      >      >      > 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.
>      >      >
>      >      >
>      >      > Not sure about "few seconds" ... IBGP def hold time in number of
>      >      > implementations is 180 sec :) .. but few minutes will work for sure.
>      >
>      >     depends how you use it.
>      >
>      >     If you can use the unreachable info in a smart way, it's sufficient if
>      >     it is present for a very short time interval.
>      >
>      >     thanks,
>      >     Peter
>      >
>      >      >
>      >      > Thx,
>      >      > R.
>      >      >
>      >
> 
>      _______________________________________________
>      Lsr mailing list
>      Lsr@ietf.org
>      https://www.ietf.org/mailman/listinfo/lsr
> 
> 
>