Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

Robert Raszuk <robert@raszuk.net> Tue, 09 March 2021 10:47 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6F83A19B8 for <lsr@ietfa.amsl.com>; Tue, 9 Mar 2021 02:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGAk2_2_rLv8 for <lsr@ietfa.amsl.com>; Tue, 9 Mar 2021 02:47:49 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31273A19B5 for <lsr@ietf.org>; Tue, 9 Mar 2021 02:47:48 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id d3so26216786lfg.10 for <lsr@ietf.org>; Tue, 09 Mar 2021 02:47:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z38tmLqgJ+sHD9iARypjn9gh5DudDsk6ocmIT93X3T0=; b=Cryjrc4gn8jMVcqreEhYn4gQGLx2aJ1hl3v8r9HvYHQQLEv1Ect5KV3/7LIS90OmlE ieFXgMnehPB0Fhft4PHd0C+SFSeXYUJXRTy8rmRwOF7baAO4QGtEOB3piVH/Tlt80Fnc SQ90TR5vL7wbHYQ017RAroeZavo1obijYkwJHFD5zlZLVXMPVIdpY/4gNljFf/9VOYv7 Mo0SBwsvJONqER+tVDJPeXamH7QjsnP5wsApQCct9Ci3ywx6j5i+732UGeG1jCKM6KbS KVK+szs+OpftrtsL/IJZ7L3ZyTBuK89DDPJXcop+50drINU4k9TVZJewDKb219lueU2z +mgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z38tmLqgJ+sHD9iARypjn9gh5DudDsk6ocmIT93X3T0=; b=nRlC9ycOH3v8bJkeRc2b71HWxmi30rTLXmpJYG38fcyZgY2mZsfYbtGPai1RMUhD9Z wiwPp8/hEdZ2culD1eKqmo4KX14dk9P7oGNs2FKeCx8zyewhvpMjrH1+8TeJ+oub4Ei9 JMDYfQRdHe3G1L2RkqBT5AW/sBmCLA3mZsD9xzu9dtMU+g7F9SZL65i4VVmamwAu40KC DEncwZNAtk03dxXgozX3hKf30lW6uWNo+w7O/2Mbxk6XhsVZSw5lC838QO48KziPjAs+ zeNeTj8wApea3EDn1da2gdLwbAuxKTfXu7eXvfMmpidc/TeQRJxpv5xbbJF8tDCU6cX9 /vEw==
X-Gm-Message-State: AOAM533U5X6jWu72daanNYmKmWZHVzhBYc29RFhcazJ6V3+mwOGJUBl2 noSFtx89MLitQ3kaV5XDTy92i7Hw3i/7f/l5iBm/jw==
X-Google-Smtp-Source: ABdhPJxNrd5icilaDDiZfv6u6FRNvQNpq5qvPMqzZaYPK0yramYmZKuvYaesFRZXZpeaeH4OsaPSlRHKOZkTYHCfyUE=
X-Received: by 2002:a19:c14c:: with SMTP id r73mr17990814lff.581.1615286866451; Tue, 09 Mar 2021 02:47:46 -0800 (PST)
MIME-Version: 1.0
References: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li> <6E0281D2-7755-499A-B084-CA8472949683@chinatelecom.cn> <D6B0D95F-68AD-4A18-B98C-69835E8B149B@tony.li> <018801d71499$9890feb0$c9b2fc10$@tsinghua.org.cn> <CABNhwV2SpcDcm-s-WkWPpnVLpYB2nZGz2Yv0SfZah+-k=bGx4A@mail.gmail.com> <BFB3CE24-446A-4ADA-96ED-9CF876EA6A00@tony.li>
In-Reply-To: <BFB3CE24-446A-4ADA-96ED-9CF876EA6A00@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 9 Mar 2021 11:47:37 +0100
Message-ID: <CAOj+MMGeR4bodbgpPqDCtLZD6XmX6fkjyxLWZAKa4LC2R1tBzg@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, lsr <lsr@ietf.org>, Aijun Wang <wangaj3@chinatelecom.cn>, "Acee Lindem (acee)" <acee@cisco.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2ac7205bd184755"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/cwFvGp5qYou83W9-2xpsgb427hc>
Subject: Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Mar 2021 10:47:53 -0000

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

I think this really nails this discussion.

We have discussed this before and while the concept of signalling
unreachability does seem useful such signalling should be done where it
belongs.

Here clearly we are talking about faster connectivity restoration for
overlay services so it naturally belongs in overlay.

It could be a bit misleading as this is today underlay which propagates
reachability of PEs and overlay relies on it. And to scale, summarization
is used hence in the underlay, failing remote PEs remain reachable. That
however in spite of many efforts in lots of networks are really not the
practical problem as those networks still relay on exact match of IGP to
LDP FEC when MPLS is used. So removal of /32 can and does happen.

In the same time BGP can pretty quickly (milliseconds) remove affected
service routes (or rather paths) hence connectivity can be restored to
redundantly connected endpoints in sub second. Such removal can be in a
form of atomic withdraw (or readvertisement), removal of recursive routes
(next hop going down) or withdraw of few RD/64 prefixes.

I am not convinced and I have not seen any evidence that if we put this
into IGP it will be any faster across areas or domains (case of
redistribution over ASBRs to and from IGP to BGP). One thing for sure - it
will be much more complex to troubleshoot.

Thx,
R.

On Tue, Mar 9, 2021 at 5:39 AM Tony Li <tony.li@tony.li> wrote:

>
> 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.
>
> Tony
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>