Re: [Lsr]

Tony Li <> Tue, 09 March 2021 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CF573A1AB6; Mon, 8 Mar 2021 16:22:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cbLi_yVOqRUQ; Mon, 8 Mar 2021 16:22:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33D323A1AB4; Mon, 8 Mar 2021 16:22:19 -0800 (PST)
Received: by with SMTP id kr3-20020a17090b4903b02900c096fc01deso4138801pjb.4; Mon, 08 Mar 2021 16:22:19 -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=pRNorW8st98TU5pxkicWgmATBIIgQBPPTwqXcaKYYHA=; b=Edfq2S5NBlyAjq5PrgAeU5M5sm6dOmVOEspAajcKJeXfKEYvwwezbrI+8D4vdWVv76 llTguxC0fKi2KM2U3q5UiOcfKwTi+s+EG2FWY7lEsvqZwlP+041v7LcN7AtsjbL3Qpbh BFpHR+/CeVfc9YA+fNV5wS67RHgbUWf3/3j1T0zm0smTUaxJS2Vf7v2Rl+uMwUoeSeZr d8m8yiykVK+fmVlz/hJSYRZD1oUcoD+09OSs//sxF+Bfr2jDyj01AF/rpPdWXCkjnYjV oita30ecEl1dGFf/ESWpZ091ZphqtcasCMhMkMOORerhBk6Uq51gJAPx7YaJdDupZILa AsVw==
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=pRNorW8st98TU5pxkicWgmATBIIgQBPPTwqXcaKYYHA=; b=YAo5MpHMoOq74kiVFJ2dI/J0zrG1XMrZa342GQHj3xIgiXbvfEbep5pwjlLt9KP+PP YAhH7Olyld7uYRTxPmtj34SJA7i8SYG5fzK/yrpbHvd54JXWfAAQ9s/p3CkQvBxl2ok2 dg3yLq9LX6w68dCIEh1lI4utMVcptPyl0qNAsPL0fft2DHmCUnsxKjTR4vJL5hHVcZmZ LtdealFxk2YaKUxylNB8vijl/4noBVVFlxwWKB4LxL8Tdun33Co0sc18Xf3Gv4cMk04j mk4yQtI/c6QI+7zZ0pN0q6rEoaVniW+Tr6VMWf/FENLCTf3AdutoMBgFdqFdxnapvQGL iV/g==
X-Gm-Message-State: AOAM533xZgWTKK7WMsyyuaHJx+lEQdX+orfDL/fsEImwUc+LyVIjOFCw zo4MiElGyyd/2P2EP9kFqsQ=
X-Google-Smtp-Source: ABdhPJyM+h1kIxSTl3f0FqhDDVHXxgwXZ5IMn+53YwSmjApZFMDQNm8tksRDArE1TOeIeGAAAOi3Gg==
X-Received: by 2002:a17:902:da91:b029:e5:cd82:b4c3 with SMTP id j17-20020a170902da91b02900e5cd82b4c3mr23020475plx.73.1615249337591; Mon, 08 Mar 2021 16:22:17 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id e20sm5771767pgm.1.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 16:22:17 -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 16:22:14 -0800
Cc: Gyan Mishra <>, "Acee Lindem (acee)" <>, Aijun Wang <>, 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 00:22:21 -0000

Hi Aijun,
> There are two scenarios as introduced by Gyan: one is the node failure(Scenario 1), and another is the link failure(Scenario 2).
> For scenario 1, also when all ABRs can’t reach the specified address, it is not efficient to advertise all of other detail prefixes when only one prefix or some prefixes are missing. The ABRs  tell exactly the specified failure prefixes via PUA message is reasonable.

If no ABR can reach the address, then there is no point in advertising anything.  The traffic is going to black hole.

> 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.


So, why do we need to punch a hole?