Re: [Lsr] Prefix Unreachable Announcement Use Cases

Robert Raszuk <> Sun, 15 November 2020 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1A6B3A102F for <>; Sun, 15 Nov 2020 02:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V0NvFK-01jQo for <>; Sun, 15 Nov 2020 02:49:04 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09D0E3A102D for <>; Sun, 15 Nov 2020 02:49:03 -0800 (PST)
Received: by with SMTP id s9so16180400ljo.11 for <>; Sun, 15 Nov 2020 02:49:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6BbR4/ekjUkXy6n1C7d8xPOzspKCo1fc6oTae4tgZgY=; b=IcnYSBan78+D8POYmJibGzQ5jWegduuHXkgpdpPP4o06S8nWpgE7uDZPbzWvBVC4RV QFhm9bhGgJRnMtshN/4Tx+ydmAxktVDwmUAXx7a/UETqbd2ZnRD3pTlikPs4JZLCsLVq LtiTJjAHrE3QaSgCDugb4QOmWHNvfnur2vQuS3PVz8bmsY4eqrxaLjk0emQW5VjOot1f Ego2efH4XAchrLeZXrM1SdzcxbvjGz8hyQXmiaYXwxgB7nxs0nyN+kv5GvjOPpLtoJS/ /VThvfvH1Je2MbmA5uXij6djjbssDpB8AB/6ctlXPAHd9akMC40L9kdcL6ryQnX8GCQy iAjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6BbR4/ekjUkXy6n1C7d8xPOzspKCo1fc6oTae4tgZgY=; b=YHspVE7RsbGDltwZK06EjPFa2Uw2j8p/giODekAdP8TX32TYuOl5nWKQNaSVEW9G9y nnQP34CaD/2rj+S48LHF0feJuWnJqDjJtztKWFS32tuNyQOZ/Xxr4TeUhoAp+u91IgeS J4HRiIrnHkYT57o9CCndOmi9/4sMKbRWMD5iZuahROt2c6gvVAIRVzbnpKGZnX6MllkL TcxJZHXo9LxxHuR/hCkBu8o1YR+Z9W6Ll7fK34+7QdhnZojJQ9gpyn/bCP5JvQec4ceZ 2xvpQ7wXZazpFqcQQFePZ2jMCcLqQemXcR+1hJOp8n2F9qYU1E39Om4rRalZKm7CEWf8 Hihg==
X-Gm-Message-State: AOAM530X20A0ILf0FsBnjBx4C++D4jYPERZODXOPXWRAvvucvaU+FhW7 bVh5YSppCFDXhP0bM040VJiiBMy+CcIxvDNgNIkzBt3QpC8=
X-Google-Smtp-Source: ABdhPJzPmuNMZQ7kVkyOAQdiP7iosN74z5lwfqayi78YrKkni/J2iHQ9UJvTTh+5J7GayHOLRgkjCnKKPjA84a77Qho=
X-Received: by 2002:a2e:b8c7:: with SMTP id s7mr3950983ljp.374.1605437342022; Sun, 15 Nov 2020 02:49:02 -0800 (PST)
MIME-Version: 1.0
References: <> <AH*>
In-Reply-To: <AH*>
From: Robert Raszuk <>
Date: Sun, 15 Nov 2020 11:48:51 +0100
Message-ID: <>
To: =?UTF-8?B?546L54ix5L+K?= <>
Cc: "Acee Lindem (acee)" <>, lsr <>
Content-Type: multipart/alternative; boundary="0000000000007b149705b4230230"
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 10:49:06 -0000

Hi Aijun,

As I think what you are proposing overall is useful let me in turn comment
on some of your statements ...

[WAJ] It is common, for example, ISIS level1-2 router will announce the
>> default route to the level 1 area. And, also in the OSPF totally stubby
>> area.
Well let's just take OSPF and imagine:

 Area1 --- ABR1 --- Area0 ---ABR2 --- Area2

So you are saying that unreachable should be always flooded/leaked domain
wide. That's news - I was always thinking of this functionality only in the
case when a summary route covering such more specific is present. Default
should not count ... at least I am not sure if this is safe or makes sense
at this point.

[WAJ] The tunnel soultions described in section 6 is the last resort of the
>> path switch procedure. If we deploy the PUA mechanism, normally the routers
>> within another area will switch automatically to other ABR when it receives
>> the PUA from one ABR.  Only in the critical scenario that described in
>> beginning of section 6, the solution described in section 6.1 or 6.2 will
>> be used.
I think this is where you are starting to confuse people. In my option this
solution should have nothing to do with selecting which ABR to use to cross
area boundary.

The cases when one ABR has full remote reachability and the other one
partial one in my view are symptoms of a very poorly designed network and
to stretch protocol thin to cover for those mistakes with a patch is not a
good thing.

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.