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

Gyan Mishra <hayabusagsm@gmail.com> Tue, 09 March 2021 00:52 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 B3D7F3A1B28; Mon, 8 Mar 2021 16:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, RCVD_IN_DNSWL_BLOCKED=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 7DeCug3tylAf; Mon, 8 Mar 2021 16:52:03 -0800 (PST)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 C0B563A1B24; Mon, 8 Mar 2021 16:52:03 -0800 (PST)
Received: by mail-pl1-x62d.google.com with SMTP id d23so2503486plq.2; Mon, 08 Mar 2021 16:52:03 -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=LD17i8BzefTOXyqTv9/OmK+JU1tjqZuv95E7hhCTe+w=; b=VBWZkBdzGJeItEAiMYiZ4q8kBacOUwuCR7ErOnZ/CkMvmcBmjrFzxZ8xfwOt6hkT0r CmQBb478VRgCk2B1oMSg/ySjcxs6UCs4IrfcEZaRddJ/AzsD50Ge3i15S3EJ6rATch0g Lj3ff3oG2djF1n4g6plz3VGMBUHcZgbW3jD4oKwFmk3PcbaMZkZOHQQS9rJxBi1Snvb5 5eQCqTV5taER1cUmMVlc5EQSB/EarhGv36ELCPpa70z7Zw5kEj7YqU0Ox3JLK8/GRx0Y l9nybxmWO8pcdykP/YObbvNGo306rbqcHLwI1l/axK7uGZUFJS5Y6DzyCpG2kC6T8lBv fvUw==
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=LD17i8BzefTOXyqTv9/OmK+JU1tjqZuv95E7hhCTe+w=; b=p0y4g/yI9Y6djqMDY5SEF+avO/7AtvG1KTkEU/zPSU7AA7qrqE/jtnFGe7pBrWSsvG z/XaM7itBNc7xPolm4i6ODyBWSSDoywgrn3Jrs18SRc+FnXPf+LxJ7DnbaT3yee6hq/a 88BhkekrxOoH+nZGcP/5J8V/B14unP5wzSqzSoenu2fQboKyX3f0wzqPkcdU6jNC+MZP dywGlKZtuX2Js+5sJD+XVStRqPKKvDQ9+F1/fTuZ3V9ZWYfGRzDzso5/QByFznhESTz2 X6gx/lYRLWIPUPfoEibZvWnxSX5e2sqjN8yUnkFc/PpsouNnO6QuVUsehnX3DPNEr6SQ +xcA==
X-Gm-Message-State: AOAM533zMtKKoA7ZOYbx6IJwoqEWxG51k8ONeYUxSAu07vD7z7pkj8Ja pnrYIhf2toMXejRE+3Cua3zy2ZxFlFdijws0U83+SIQFpYg=
X-Google-Smtp-Source: ABdhPJyuekc1XRH2w8aIvRypZeE4UWbOi9aLDjZTWrfMpE07UF3x6KF1L9ubWCkdGz1FJZwOMqoLGFzFgp9fibegqOs=
X-Received: by 2002:a17:90a:7a8b:: with SMTP id q11mr1725650pjf.215.1615251122615; Mon, 08 Mar 2021 16:52:02 -0800 (PST)
MIME-Version: 1.0
References: <AB1FD8DF-93B8-4342-AB4E-F2E7A59BF4F2@tony.li> <DF653179-2DFA-4271-B863-3411BBBA21BA@tsinghua.org.cn> <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li>
In-Reply-To: <22FDE3EA-B5D1-4E4D-B698-1D79173E8637@tony.li>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 8 Mar 2021 19:51:52 -0500
Message-ID: <CABNhwV3JjynSfDbYNXn44g2d+o16gAiOyTN1_2Neyw_+xXJuYA@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="00000000000062f85505bd0ff552"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/2CfqCz17t8BDRpM7-_8bwKr7qhc>
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 00:52:08 -0000

Hi Tony

On Mon, Mar 8, 2021 at 7:22 PM Tony Li <tony.li@tony.li> wrote:

>
> Hi Aijun,
> >
> > There are two scenarios as introduced by Gyan: one is the node
> failure(Scenario 1), and another is the link failure(Scenario 2).
> >
> > For scenario 1, also when all ABRs can’t reach the specified address, it
> is not efficient to advertise all of other detail prefixes when only one
> prefix or some prefixes are missing. The ABRs  tell exactly the specified
> failure prefixes via PUA message is reasonable.
>
>
> If no ABR can reach the address, then there is no point in advertising
> anything.  The traffic is going to black hole.




>
>
>
> > For scenarios 2, because the specified prefixes can be accessed via
> another ABR, then we can let this ABR to advertise the details prefixes
> information for the specified address, which behavior is similar with RIFT,
> as also mentioned in the presentation materials.
>
>
> Agreed.
>
> So, why do we need to punch a hole?



   Gyan> The goal of the solution is to be able to take advantage of
summarizing LPM match using MPLS LDP inter-area LSP extension of VPN
overlay next hop attribute /32 host route so that in larger domains with
1000s of PEs that domain wide flooding of host routes can be eliminated per
RFC 5302 impacts of domain wide flooding. The prefix is the egress PE next
hop attribute for VPN overlay component prefix that becomes unreachable due
to a link or node failure.  All BGP next hop attributes for VPN overlay are
being summarized so LPM summary FEC binding must be used to route the
traffic.  As all the BGP next hop attribute for vpn overlay are summarized
as is the goal to mitigate domain wide host route flooding, the next hop
attribute host routes component prefixes cannot be advertised.  That is the
problem we are trying to solve with PUA signaling of the component prefix
being down using the prefix originator Sub TLV RFC 7794 setting to null0
and flooding using Normal procedures  to force control plane convergence to
alternate egress PE next hop for the LSP to properly re-route.

>
>
> Tony
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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