Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff Tantsura <> Sun, 15 November 2020 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F15ED3A0656 for <>; Sun, 15 Nov 2020 11:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f0YCdLNBqHop for <>; Sun, 15 Nov 2020 11:29:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E8453A0659 for <>; Sun, 15 Nov 2020 11:29:21 -0800 (PST)
Received: by with SMTP id h16so6697601pgb.7 for <>; Sun, 15 Nov 2020 11:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=726YgiRuTVOaPyqtm5IUZv7NbYUYrDGAl12PGLaPe8o=; b=HqOq2X+FXeQz7Aaz5bh5MOEKQq/xpShvgPfpSa8vVvIpJ+FcSm8i9r/mV1JDyDF+Fs QGmQtMK8gClfARCVEEEK0fa++zC2BGNEL+M/JMpjc5bv9BcwCxDISeHGTiiuJxOxbkBJ Whj8O/XJ+snz+njEJXBxCrgFogEh9G+kFIyBQ4TpqmoSmW3OE+FufctECtJ3NPsjk8+U YX4Ta6h57MZm+BRCWI8of2NL2X/deOLQ4KJV7vmHZRACiWdkLPJPsX8FbtAE1B03UPFU 7fL6jKfRW9DzpdkYHHyBhFU6+w2aWjjmtc2ABwn41udOMp3ujbWHJ7/FgnxwKY9iuLl7 cUmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=726YgiRuTVOaPyqtm5IUZv7NbYUYrDGAl12PGLaPe8o=; b=iUpqMuZ2miGIpJh7vq1fOmJHfw3iitD6ILhCDZodRhjbQ1tvfeaZRzooRqKCh5ocoV +kBx9voHK0tkTuksF2gXfiWB3mpyyrBW4p2oeA5VExE0nTApD9r7vb3w0/3dAVdJ+wGC nWC620RdZBarkLF+eUv4/o2C4hApDYDasVHtP9vivvf5p7Ib4cY2om7wbGOuAonquGrX NxIx0LbtYDhgb8RQjblQ/cSLcxiH+FH6bEfHdFc5iT/JW37doq/pgOjj+hRrNQcrGGxD fbdHVYZLNuJpvFFCFdq5LrhLV2viKsPe73QdAMJPnfwamVHkbCByrtro13q2J/5Xlstg 5tSA==
X-Gm-Message-State: AOAM531ToyftscCYdTHHCRnl25fp3oNlI7DOIUHfaX6UQqGns8zemgcX d3kqBlyR9z50DLLWp5jXhlDQ5KzPEOg=
X-Google-Smtp-Source: ABdhPJzc4NDHenkczXgnEpXTYNk+IOCu8e5VXXE8KGhxveD6hIsy6bGVEgy/BOkAbjD59mnL+TAISQ==
X-Received: by 2002:a17:90a:7301:: with SMTP id m1mr12002123pjk.128.1605468560835; Sun, 15 Nov 2020 11:29:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id a81sm16012425pfd.178.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Nov 2020 11:29:19 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-59B547B2-349F-4CDC-B74C-38AFD32F6A0C
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <>
Mime-Version: 1.0 (1.0)
Date: Sun, 15 Nov 2020 11:29:18 -0800
Message-Id: <>
References: <>
Cc: Aijun Wang <>, lsr <>, "Acee Lindem (acee)" <>
In-Reply-To: <>
To: Robert Raszuk <>
X-Mailer: iPhone Mail (18B92)
Archived-At: <>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
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: Sun, 15 Nov 2020 19:29:23 -0000

As RIFT chair - I’d like to respond to Robert’ comment -  the example is rather  unfortunate, in RIFT disaggregation is conditional and well contained within its context, it doesn’t  affect overall scalability.


> On Nov 15, 2020, at 08:44, Robert Raszuk <> wrote:
> Hi Aijun,
> I would in fact only propose that the presented mechanism is narrowed down to invalidate BGP (service) routes - in fact their next hops. 
> The reason being that the moment you make the solution generic, moreover the moment you want it to be used in RIB and data plane I am afraid you are running into similar (even if local) deaggregation mechanism like recently described in RIFT. That would kill all the scalability of advertising summary routes in the first place and I bet would face lots of opposition. 
> Thx,
> R.
>>> I would actually trim most use cases leaving just one - to signal remote service node (ex: PE) going down in the presence of summary route being advertised from remote area or pop. 
>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism can also apply to other scenarios. We want to make it one general solution.
> _______________________________________________
> Lsr mailing list