Re: [Lsr] Prefix Unreachable Announcement Use Cases

Robert Raszuk <robert@raszuk.net> Sat, 14 November 2020 22:30 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 E2BDD3A0799 for <lsr@ietfa.amsl.com>; Sat, 14 Nov 2020 14:30:33 -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=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 kC2kkXRshA6f for <lsr@ietfa.amsl.com>; Sat, 14 Nov 2020 14:30:32 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 A0F313A0656 for <lsr@ietf.org>; Sat, 14 Nov 2020 14:30:31 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id s30so19408035lfc.4 for <lsr@ietf.org>; Sat, 14 Nov 2020 14:30:31 -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=22rQ52h83kxX6EH/BnC2JyIDJR/d9ouFzvf/NiOwDNg=; b=S/JjmSIH47pt/mJ1HsajkFyNGHPBfDW6xSFelvuM8A1IA1OnYElIWu71sn7QEAZ7zK wK681PQQjTM4VirsH8fymVNarMKWgHFNY2ah3pPVs08rxItzszYeVlIefCz9KL6TwtVe 1v/MKl1etsU25BZV8sVxxnIrs3D30lbEH/cRS83jzxWM2ikvTcYcjrywc2Kqm6iPvCnI kOBMq/R/ZcjxNZ/7FRBhlxWw235evo4280VMqUobrhlL8iaXtGN8m3DuhvIo4Ro8E0Z2 0FrnRhcqlfptHd3QlIezqHoIOgL/TIeJrPgZhvgBbPXFYRa49V5eNFOyY1pEafMEZ6vp 7XSQ==
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=22rQ52h83kxX6EH/BnC2JyIDJR/d9ouFzvf/NiOwDNg=; b=Udf4nSwd8U4vEsn5+ndR4pNe/1LRzOAtI4Je347gZxIkJo3JJMUae9ugSBDBApRZgk 1sn1U0ZUaUWxXMrq2w/D2nUJGPgTZ3saq1g7KXi1X6gburN74NYe2lKciKSttecJdyY/ DvbEIs7UAAQBPg2cxJ4ieLh/xZ8nbyab2KwMbfhS9khBOVQnklcE+Ex2cjaiSd0u5aC/ Z3rGlTmMRPqlU9d7eyD0bLgz2iJ9v/PWgK38/KP6fo7GABUiAgwdizIT42wVh0neCEGp /JsoUr61kO4FCOhOhL0lZ0xZd/Dwi41+mnim+gat2QsxWS1sAWpXvnd7kliGs99z2CY4 HuPQ==
X-Gm-Message-State: AOAM533MtdjtvFX/H31OW7hvCff9r+p/GTJt04vFkgdbRb9ffASLOumd T6bYVHB0Rwd2CUsaheR29iI2eN/Lch3XubNPX4j94aAZIxzZYA==
X-Google-Smtp-Source: ABdhPJxWjvFqoLKWt9ECNzu7i4QVTn3KznghgPbChOjtKUSAw5RdN30/ZtpqCNxPp+3Lt1vTwg5F1F2NE7wmP90Kiak=
X-Received: by 2002:a05:6512:3606:: with SMTP id f6mr3393994lfs.12.1605393029374; Sat, 14 Nov 2020 14:30:29 -0800 (PST)
MIME-Version: 1.0
References: <C3078A8F-4F86-4981-A2F8-60829CD44A4D@cisco.com>
In-Reply-To: <C3078A8F-4F86-4981-A2F8-60829CD44A4D@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 14 Nov 2020 23:30:20 +0100
Message-ID: <CAOj+MMGzU-OXTFPpuT=JtTZBqr6=wKXtkRNQd7W5GT2NvwiZNw@mail.gmail.com>
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003db40505b418b11c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/AVlg_KOM9AlEOh_pqSj32wBqx68>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases
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: Sat, 14 Nov 2020 22:30:34 -0000

Hi Acee,

> 3.1 *Inter-Area Node Failure Scenario – *With respect to this use case,
the node
> in question is actually unreachable. In this case, the ABRs will normally
install a
> reject route for the advertised summary and will send an ICMP unreachable
when
> the packets are received for the unreachable prefix.

And what will the network do with such ICMP unreachable ? Is there some
draft I missed where encapsulating PE will choose a path with different
tunnel endpoint upon reception of ICMP unreachable message ?

See the entire idea behind this draft is to trigger faster switchover to
other PEs in the case of a multihomed attached site.

Option 1 - withdraw a service route in BGP. Use aggregate withdraw to speed
this up (say withdraw just RDs)

Option 2 - signal next hop unreachability (aka negative route) of more
specific prefix then the aggregate itself.

While I think just option 1 is ok for the vast majority of services your
answer seems to be talking about ICMP unreachable which IMO would not help
much with the issue. The proposal is not about failing ... the proposal is
about faster connectivity restoration.

> If faster detection is required, BFD or other mechanisms are available.

Now running a full mesh of BFD multihop sessions from each PE to each other
PE may be ok in theory but rather no-op in practice. Just think 1000 PEs
with 100 ms BFD timers in a full mesh of BFD sessions. Then rethink the
same with  BFD packets maxed to 1500 or 4K bytes packets as per some
proposals floating around.

If we want to move that way I would rather suggest we define a local BFD
anchor explorers (one per area) which will probe all "interesting" next
hops in a given area. Upon failure it would signal to those remote PEs
which indicated interest in such tracking the event of failure.

Again using BFD for this in any form or shape needs to be weighed for
cost/benefit against option 1 and option 2 above.

Thx,
Robert.

PS . Now option 1 can easily be sub second if BFD is enabled on IBGP
sessions between RRs and PEs. However I think there was some concerns
expressed in the past by a vendor for this type of deployment of BFD
between loopbacks. Maybe it would be beneficial for this discussion to
better understand this concern. If valid I think the option 2 which IMO is
the objective of this draft does present a valid problem to be solved.
Today practically speaking networks flood in IGPs globally 1000s of /32
prefixes instead of summarizing them as this is the only way they can
signal liveness of the remote PEs.




On Sat, Nov 14, 2020 at 10:34 PM Acee Lindem (acee) <acee=
40cisco.com@dmarc.ietf.org> wrote:

> Speaking as WG member…
>
>
>
> With respect to the use cases in section 3:
>
>
>
>   3.1 *Inter-Area Node Failure Scenario – *With respect to this use case,
> the node in question is actually unreachable. In this case, the ABRs will
> normally install a reject route for the advertised summary and will send an
> ICMP unreachable when the packets are received for the unreachable prefix.
> This is the expected behavior and there really isn’t that much of advantage
> to move the point of unreachable detection a couple hops closer. If faster
> detection is required, BFD or other mechanisms are available.
>
>
>
>   3.3 *Intra-Area Node Failure Scenario *– In the first place, multiple
> areas with overlapping summaries is just a bad network design. If the
> prefix is unreachable, the case digresses to getting the ICMP unreachable
> from the ABR with the invalid overlapping summary.
>
>
>
> 3.2 *Inter-Area Links Failure Scenario – *This is the case where the
> prefix is reachable but only through a subset of the area ABRs. This is
> really the only valid use case. IMO, it is better to solve this case with
> intra-area tunnels through the backbone as described in section 6.1. I
> think this is preferable to the complexity proposed in this draft and
> especially section 6. It is “interesting” when non-implementors specify
> implementation details.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>