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

Gyan Mishra <hayabusagsm@gmail.com> Tue, 09 March 2021 05:18 UTC

Return-Path: <hayabusagsm@gmail.com>
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 2D5633A10E5; Mon, 8 Mar 2021 21:18:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 A7cT48ohkToh; Mon, 8 Mar 2021 21:17:58 -0800 (PST)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 13C893A10E4; Mon, 8 Mar 2021 21:17:58 -0800 (PST)
Received: by mail-pj1-x102f.google.com with SMTP id ga23-20020a17090b0397b02900c0b81bbcd4so4347070pjb.0; Mon, 08 Mar 2021 21:17:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4pIvtbfzEEx5wU0xT3jke2+yYl4q4DMd/dehXvM1GZ4=; b=J/X7BuHdia2I/fEAoXsmCnLnsTdWRWuH3k7kyWJyxusfS3Xw0knS1ScP4XrhdiD+3o ub7obvCIGKkweAmci3shyR1ISOKvzUS9rZarn8NhdEzjUaIAgwtatAX8thT6NkunO25P 6mR664iC8yMHH/wKDfAE73/iWXLYxrz4OEZKoWl8nZO06JJmfOA1jpQ6cwwXpV81ZNJG ZfeY0q0dIkNFosctcWJG523QnCrZTPB1bDqhnc7XQqeaaj++WWyDpZ5/YFuf316l18rC s248ecHOJXsc9c1268qE5V3wwCKLTvNgfGypaJp0EyX5P7HXAvoiGQo4ItnOpS4f7EqZ V0dg==
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=4pIvtbfzEEx5wU0xT3jke2+yYl4q4DMd/dehXvM1GZ4=; b=TMNzuylxHF4G0ph2AG+jOC+3EZNpov3gENN8ECY3lnSzEXidAHLJjVxJHxuMt/wzJT O39Ar0PGEvuhAw2dKMpmJttedwcEqdzf0NfMbMaD19zwu4YyrsY1Beq4QYhgfm0xUWDQ s4SEZrZAMs2M+Lb3wScXhGSYZXIvKgf/8d7Gn8SSGimzGhT0bzm0lNMnYcLvAK/sKmFH UAvsV8TyfbM8EClrnonb0wpMIWbjuLgt13yQjnBKdKCyD+qFon7gzvfSirujcwwzz4dq gv3mKd5cN4UFi/McItpBdb2Q1MatJs2BrFSjCubeCGdMzBoWPQbMZyklEnHtoV4/eqvr moZA==
X-Gm-Message-State: AOAM531tEl1a30kbL7AIOe+CZDUS1WCyL4mV6hesZhoDAtd+s6nRFj0P xT1ZqJCoMQiDfMKF5Wvkv5/9zIEpArP4F+xiJnE=
X-Google-Smtp-Source: ABdhPJywOnO0+u9PzG9CHN2pPKl3H+rWJUwi0KHo2JIcJWRxWH88Bs5ufmDmsGkAEx9Ga/v0wYoFCssFfVkPUH31xNI=
X-Received: by 2002:a17:90a:7a8b:: with SMTP id q11mr2815758pjf.215.1615267076286; Mon, 08 Mar 2021 21:17:56 -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: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 9 Mar 2021 00:17:45 -0500
Message-ID: <CABNhwV3N+Um1OM8zVGdfD54OX5OAJD_EH-NXm71MN3v4FxyPWw@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, Aijun Wang <wangaj3@chinatelecom.cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucement@ietf.org>, lsr <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004caca105bd13ac1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YbK8DRh4gxUPz665dUDg7dGMeik>
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 05:18:00 -0000

Hi Tony,

On Mon, Mar 8, 2021 at 11:39 PM 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.
>

   Gyan> Agreed BGP endpoint liveliness recursive next hop - BGP callback
to IGP - Next hop tracking ..

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

   Gyan> Ok.  How do you propose to automate?

>
>
> >     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> I mention overlay but it’s really the underlay as the BGP next
hop is in the global table recursive route to IGP.

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

    Gyan> We are talking a typical Metro Edge use case with a pair of PEs
which is redundant.  The issue is not redundancy.  The issue is when
summarization is used  as the component prefixes BGP next hop recursive to
the IGP are now hidden and with MPLS RFC 5283 inter area LSP use case the
failover is broken.  It’s not just faster convergence it’s any convergence
as the traffic black hole dead ends on the ABR cannot build the LSP to the
egress PE.  Please see the diagram in the slide deck it details this
special use case.

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


    Gyan> ok understood.  How would you know or figure out the logic on the
ABR to find what the backup egress PE next hop to advertise the LSP.  This
is a unique data plane failure condition with RFC 5283 inter area LSP
extension where this problem statement occurs.

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


   Gyan> As this is MPLS exact match FEC host route you would have to flood
the single next hop          loopback let’s say if it’s one backup PE for
simplicity

> throughout the domain so that LDP downstream unsolicited can allocate the
> labels downstream from destination downstream to source upstream, and then
> in reverse forward direction of the LSP unidirectional path is established
> and the traffic is now forwarded to FEC binding label switched to egress PE
> to now domain wide flooded exact match host route.  You cannot use the
> summary route on the ABR as that LPM FEC binding is only supported if using
> RFC 5283.  You cannot go half way you either have to use domain wide
> flooding or use the RFC 5283 inter area LSP LPM match.
>
>
> > 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
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD