Re: [Lsr]

Tony Li <> Tue, 09 March 2021 03:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 888063A0C0C; Mon, 8 Mar 2021 19:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U4IJFL7MGpLX; Mon, 8 Mar 2021 19:12:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA60A3A0C06; Mon, 8 Mar 2021 19:12:00 -0800 (PST)
Received: by with SMTP id ba1so5880354plb.1; Mon, 08 Mar 2021 19:12:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fDfr2E+fIwvv6lR/Y71on5urmWT0uS4oNOkyvrDbGDg=; b=BMWvdlkO0mBbc7f0qqBoKIi8KXdmNumUAtYYLHYSya42t/DePOjKH6FqRl0FCN50OS wItIApvPpZRaplnhfKH45IIKdfRbaEaC6rxI9iWolrf/wmHeuQfc8tYkM2/tdPUE30bf bjZuevgT7eVt0iyS30jdrdefUa8BmcpXdpDm5BsxFHs+i6yl9wSx5s46i0IX1/4A4CP3 FGFJ9+Yu3G8OIbkitQQtFHDP0ii8BIn3y/52mqr5MBHM4ozGDnH+nW3h0xctQk2gb4EC vxegvXKY+yk6OQ3JYKdoCHBDWdvGyu2KIk0CEQ5Y9SgC4M2dP2B+FhIaaeZmywZ7zVaU x0Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=fDfr2E+fIwvv6lR/Y71on5urmWT0uS4oNOkyvrDbGDg=; b=omTTrvkJwlCV6V3Ja/kbhaUvaKmALr5X1eLGxGa437CdannO+kCE9fr9RQb6pJZORl CKAkPxyOIBlu8px3T46m3U4WAvplTxm3vMPy3HRcHEhojEjfvpyEREUltyoOAHIwzkDz hFia+0Yi2t5F9gCGqVt0PYeXksKP+8sQrQokrNpxQxHdx3VJZ7xC/fe98s55xz0oQWMO wusJx80mUdFYWuajGtK7jWwLvVZYMeBsT/VdKXoDVDX5kA0QU4KK5eOehsgLyj2g/lOV HPtvUmcRF1z27KtxVnuuTjJXVvXpYshvlF1YsSJqmLXL0dreP70TpKCIZZCayVR+9N5G MaDg==
X-Gm-Message-State: AOAM530/BqKhc8SVxbQ8bLurDCUKq3swBcfPIQEo5hssCw31+jqPuqY2 YPH657ASqEf3uAmELRtxQ7U=
X-Google-Smtp-Source: ABdhPJxYQsSOSlwaegKxMBQ4BNnJQb68yeRIvXH3+S3puJ3RDmfLWc5qEFKmsRLKwd+mD3Mihk6L/w==
X-Received: by 2002:a17:902:aa0c:b029:e5:da5f:5f66 with SMTP id be12-20020a170902aa0cb02900e5da5f5f66mr1838212plb.81.1615259519272; Mon, 08 Mar 2021 19:11:59 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e10sm11747191pgd.63.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 19:11:58 -0800 (PST)
Sender: Tony Li <>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Tony Li <>
In-Reply-To: <>
Date: Mon, 08 Mar 2021 19:11:57 -0800
Cc: Aijun Wang <>, Gyan Mishra <>, "Acee Lindem (acee)" <>, draft-wang-lsr-prefix-unreachable-annoucement <>, lsr <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Aijun Wang <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Lsr]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Mar 2021 03:12:03 -0000

Hi Aijun,

> [WAJ] We just want to avoid such silent discard behavior, especially for the scenario that there is BGP session run on such failure prefix. 

Stuffing things in the IGP seems like a poor way of determining that there’s a BGP failure.  Wouldn’t BFD be a more appropriate way of determining the loss of connectivity?  Or aggressive BGP keepalive timers?

> The other side of BGP peer can quickly remove the BGP session when it receives such PUA message which tell it the other peer is down now. Other BGP peer protection procedures can then take effects on.
> The immediate notification of the failure prefix can certainly accelerate the switchover of BGP control plane and also the service traffic that such BGP session carries.

The IGP is a very poor way of delivering service liveness information.

>>> For scenarios 2, because the specified prefixes can be accessed via another ABR, then we can let this ABR to advertise the details prefixes information for the specified address, which behavior is similar with RIFT, as also mentioned in the presentation materials.
>> Agreed.
> [WAJ] Even for this scenario, the advertisement of the detail prefixes is trigger also via the PUA message from other ABR.

That seems 100% unnecessary as the longer prefix will attract the traffic in the way that you want.