Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

Robert Raszuk <robert@raszuk.net> Mon, 07 September 2020 09:35 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 8CAB93A08D8 for <lsr@ietfa.amsl.com>; Mon, 7 Sep 2020 02:35:58 -0700 (PDT)
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=ham 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 9nrpFLj5q82l for <lsr@ietfa.amsl.com>; Mon, 7 Sep 2020 02:35:56 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 840453A08CA for <lsr@ietf.org>; Mon, 7 Sep 2020 02:35:56 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id n13so12084401edo.10 for <lsr@ietf.org>; Mon, 07 Sep 2020 02:35:56 -0700 (PDT)
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=gYf35zcsTkwOD4QGArhsICGG8y2AN5ZFH35UkhaC30Y=; b=BH7PmTQsqUG8TxZrQ2FFfxt8SEmH4q880NajDxnF/UMX8E/YzYZ86HzkWuvMVaSj0R rQapVjFWAHikYug0YBozWXATngzq2QYVUTv2b2FFMCgJ3Vn14aAKRTRM9M2gedTjM0cc lfexNwcngDHs65jZJUn0BTjhy4BrrSMVIVUgZjsA3WgHYTjbtMTLrvvdeDChjvAH9U9z xpLq/NeUKqvB+fpxwDzjCCzqdWOEzMQNB7w4mChptKYh+ejHWAtbAE96uCOeCyNjjaq6 C5T7E4ZzVjwnEJzxk9YyldXvSpRDrFNZAOw6mnu0W//E0qwjus5ZKgFk1iBeCtMU8qj2 2xrA==
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=gYf35zcsTkwOD4QGArhsICGG8y2AN5ZFH35UkhaC30Y=; b=gHB7A5LCNt8aRcHZcynjVfiAw5qX79WBwgvu7taB2Zl2L1kJ6hdxSiUtr6R4mCsm1E HeOoj2TvHG+4dnLGDXnUoILCbYF+sKyhDOkHfs6r6Y2aQNl0Dbj8g2S7xROazHqZBEL1 qxk9IRpBDlK8PQ3bHYek61LDRsBrmAClbWIvSk/DwRX1i7rAnlWy2u/my5JmTPtgvTsq vHyfl4t13Kd6G/mZOHO+TXtPpKSxUcs0/z4NyU24hHkHwHh2wgkayCIlyOFEo1F8/lN1 yZEIIcJX3rS0EtI0bwAi4tIZHWLKlBaWDA82mnhmH1o/XjDhN/gTTJdpth+ABUyI9XAy hOJg==
X-Gm-Message-State: AOAM531XoLOE8ZhdvhOIwB07rLunVrN1CGUlHmjUUGub8SECv4pi/ovC IUu1SMOYTs6xj7RYtw6kIBrsApbU8zA3DjthV2OLjQ==
X-Google-Smtp-Source: ABdhPJwf2MacTVSAWaSJLJAC37Zh5/Ut45apx2LGK70C8ahUyKMyROTbQJMCAOcq5np3bMk1SqP7WvclndE9rZJXPVE=
X-Received: by 2002:a05:6402:3c8:: with SMTP id t8mr19694255edw.266.1599471354965; Mon, 07 Sep 2020 02:35:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMGgpcnRMnPxQqcZofgJNH67QYUQOxWsTU5Xp-Km0D2DDg@mail.gmail.com> <A202F6E1-AD83-46E8-A1D2-E156FB35DF57@chinatelecom.cn> <CAOj+MMHd1WZNCWr6KihxzDf=G53A8FBUBbqHpZGNwvF4hsuzMA@mail.gmail.com> <059e01d66ad7$ffda2e50$ff8e8af0$@tsinghua.org.cn> <CABNhwV2oXBBNKOdUA59sLF+b5srWHi3KF2Q6H1Tg-dK+gA9Lgw@mail.gmail.com> <013301d679f6$92da3ce0$b88eb6a0$@tsinghua.org.cn> <CA+wi2hM1H6Vr5U_1fTVkPi5aQLrFTeRhD5Q8Be2T+wf0e1h+QA@mail.gmail.com> <BY5PR11MB4337214640926A190A8D620FC12D0@BY5PR11MB4337.namprd11.prod.outlook.com> <8838525B-EB2D-4B40-956A-1F0D5EA56D32@cisco.com> <CABNhwV26_doVEPTexHUhgAJNjdAF1JwCAHxf4H1+QzKCGLyP9g@mail.gmail.com> <00dd01d684c9$2d1ff3d0$875fdb70$@tsinghua.org.cn> <CAOj+MMHVv2DS0=F0YKso7r=DQ=s2-mMhmrYTraXt51D-+5p9bQ@mail.gmail.com> <011301d684f9$b22dafb0$16890f10$@tsinghua.org.cn>
In-Reply-To: <011301d684f9$b22dafb0$16890f10$@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 07 Sep 2020 11:35:45 +0200
Message-ID: <CAOj+MMGn02kqGqdcsP4JhAqY5L3kr2C3xhAybsJuRvpAQeSkUg@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, Huzhibo <huzhibo@huawei.com>, Aijun Wang <wangaj3@chinatelecom.cn>, lsr <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Xiaoyaqun <xiaoyaqun@huawei.com>, Tony Przygienda <tonysietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f0fef805aeb5f14f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/skQTGi_ZcU379G89qSBusYg1gEY>
Subject: Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt
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: Mon, 07 Sep 2020 09:35:59 -0000

Hi Aijun,

> the BGP next-hop is reachable

Nope you missed the crux of the message.

The next hop will be unreachable in the *source area/level. *That would be
where the BGP service route withdraw or aggregate withdraw would originate
at. Same as PUA.

Best,
Robert.


On Mon, Sep 7, 2020 at 11:31 AM Aijun Wang <wangaijun@tsinghua.org.cn>
wrote:

> Hi, Robert:
>
> For BGP next-hop tracking, it will help when the BGP next-hop is
> unreachable. But in our situation, the BGP next-hop is reachable, but
> should pass another ABR.
>
> Then, in such situation, the mechanism of BGP next-hop tracking will not
> take effect?
>
> And thanks for your draft information, maybe we can refer to it later J
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, September 7, 2020 4:54 PM
> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Gyan Mishra <
> hayabusagsm@gmail.com>; Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>;
> Huzhibo <huzhibo@huawei.com>; Aijun Wang <wangaj3@chinatelecom.cn>; lsr <
> lsr@ietf.org>; Acee Lindem (acee) <acee@cisco.com>; Xiaoyaqun <
> xiaoyaqun@huawei.com>; Tony Przygienda <tonysietf@gmail.com>
> *Subject:* Re: [Lsr] New Version Notification for
> draft-wang-lsr-prefix-unreachable-annoucement-03.txt
>
>
>
> Hi Aijun,
>
> *[WAJ] If necessary, we can advertise the MAX_T_PUA(configurable time for
> the hold of PUA information on the nodes) among the area.*
>
> *If one node connect to the network after the disappearance of the PUA
> destination,  there will be no services can be established/run on these
> failure node/link prefix. *
>
> *It**’s the same as the beginning, as not all of the prefixes can be
> reachable within the summary address.*
>
>
>
> From my pov the only advantage of negative routes in IGP would be to very
> quickly invalidate service routes (within the IGP domain) typically carried
> by BGP.
>
>
>
> When this is accomplished the PUA can indeed time out with no harm.
>
>
>
> Said this - now considering tools like next hop tracking which can trigger
> withdraw or aggregated withdraw(*) proposal in src area I am  really
> curious how much (if anything) we would be gaining here.
>
>
>
> (*) The original proposal for this was written over 15 years ago:
> https://tools.ietf.org/html/draft-raszuk-aggr-withdraw-00  We could
> extend it with next hop which would be the same as IGP PUA prefix.
>
>
>
> Kind regards,
> Robert
>
>
>