Re: [Lsr]

Tony Li <> Tue, 09 March 2021 04:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB3B83A0FB0; Mon, 8 Mar 2021 20:39:37 -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 uPPoO6sBmCj3; Mon, 8 Mar 2021 20:39:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C80053A0F5E; Mon, 8 Mar 2021 20:39:33 -0800 (PST)
Received: by with SMTP id w18so8548425pfu.9; Mon, 08 Mar 2021 20:39:33 -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=3QJNFYkK1YyX7sQX5ekfk7wodKRatMCydUOsXDGMvNQ=; b=Eeh1tmPk8Hw98g2b7DWxefz8qKhhs3kefhUbplXTkuiqIfp6RbOA5p9JowxK1gIPMH sFi/wtxul4/osDE9hq+hld2sH6LJrtGkCrHlLlxKaq1k9M/1JB1+SU9F5ci6gG0Jh5aJ K15oxRLR6nkyRyyXy+yTQfi+a7OKP95YdvuuCvbzpwndRF/7NErfPyMob0qylcqg+yqC b7QnBb/rQm/yH8kEmh8VZ2CWIqdfOI1057fyjHIVQ2SRKAMZATKQGEr0W75riAYzMKDD W1ej1En0vbDNOnGhNiIPxDgC+pCtTCgYmbyyzsDv1FrsZutnL5ve7qxrdtvLDrYUCrqv QXRA==
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=3QJNFYkK1YyX7sQX5ekfk7wodKRatMCydUOsXDGMvNQ=; b=S8NFXV+6aTCZjwQwJGPXW6ucPAzgE7MN2yjyXz5d1UDtNtcZP8ft7uby2jgMFjeDzE j5d7NU6M5b9Jh7/OexVoqADB4Y6YgYoQyXONpFVIARxPN/N/2seUUHm00K83xRfRNhwB 8qL+ik0ebI4c0R/GOTHemTPe2EQH7+4t8ijugRD+wZhnYulQsg/WTS+x2Dg+Np6XsjGO MSVrbwAhVuyJN6eoDZbZoeKAs3IuW4jSKCu0l4Y7sX2CvHnvwTAvqNozuV4Y6pRHs9FL zu+1TRROCqRDjgGbZeLu9UHQ7FpegfvDH8tCILAk83uiKP+IuKQqruX5Q0VArfXUhwQh E+rw==
X-Gm-Message-State: AOAM530itF8es76q48cQ3wv/Q9C5MfHhy1Ok5F8MqyP0tDs0D5sfqqPt qwsWBTO2FLiyuyRHNtVsTiQ=
X-Google-Smtp-Source: ABdhPJx9/ro5YooLWiSt0M++ERNMSAmgYtYzYsyjWtRj21vWsyRqedirk2pn9sdz8huDMjRJTLBlmQ==
X-Received: by 2002:a63:f350:: with SMTP id t16mr24164820pgj.441.1615264773249; Mon, 08 Mar 2021 20:39:33 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c24sm8423141pfi.193.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 20:39:32 -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 20:39:31 -0800
Cc: Aijun Wang <>, "Acee Lindem (acee)" <>, Aijun Wang <>, draft-wang-lsr-prefix-unreachable-annoucement <>, lsr <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <018801d71499$9890feb0$c9b2fc10$> <>
To: Gyan Mishra <>
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 04:39:38 -0000

Hi Gyan,

>     Gyan> In previous threads BFD multi hop has been mentioned to track IGP liveliness but that gets way overly complicated especially with large domains and not viable.

This is not tracking IGP liveness, this is to track BGP endpoint liveness.

Here in 2021, we seem to have (finally) discovered that we can automate our management plane. This ameliorates a great deal of complexity.

>     Gyan> As we are trying to signal the IGP to trigger the control plane convergence, the flooding machinery in the IGP already exists well as the prefix originator sub TLV from the link or node failure.  IGP seems to be the perfect mechanism for the control plane signaling switchover.

You’re trying to fix a problem in the overlay by morphing the underlay.  How can that seem like a good idea?

>       Gyan>As I mentioned advertising flooding of the longer prefix defeats the purpose of summarization.

PUA also defeats summarization.  If you really insist on faster convergence and not building a sufficiently redundant topology, then yes, your area will partition and you will have to pay the price of additional state for your longer prefixes.

> In order to do what you are stating you have to remove the summarization and go back to domain wide flooding

No, I’m suggesting you maintain the summary and ALSO advertise the longer prefix that you feel is essential to reroute immediately.

> which completely defeats the goal of the draft which is to make host route summarization viable for operators.  We know the prefix that went down and that is why with the PUA negative advertisement we can easily flood a null0 to block the control plane from installing the route. 

So you can also advertise the more specific from the connected ABR…

> We don’t have any prior knowledge of the alternate for the egress PE bgp next hop attribute for the customer VPN overlay.  So the only way to accomplish what you are asking is not do any summarization and flood al host routes.  Of course  as I stated defeats the purpose of the draft.

Please read again.