IETF Logo Mail Archive

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Robert Raszuk <robert@raszuk.net> Wed, 15 June 2022 13:41 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 A3CA8C157B56 for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 06:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N3xdEi3ZtJJ for <lsr@ietfa.amsl.com>; Wed, 15 Jun 2022 06:41:25 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD62CC157B4D for <lsr@ietf.org>; Wed, 15 Jun 2022 06:41:25 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id 25so16172129edw.8 for <lsr@ietf.org>; Wed, 15 Jun 2022 06:41:25 -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=7tEisFUeThUpol2b4alduiF74rMdPMZ6O0SBAZCvulo=; b=UMPKcUTEIIPxa5fyO6FgOdv+HtUiscJRCI4DtQPc7pLhhQ1j2NnNUMY5lRNhTgK11J Er1lcb7KmBmGFVn3efozjETJWWHAYRX+RFIYfhsYr8JpJlIcLLVqrCJjOQaABWFtZqIM Zk3puQF/2HEEqyxTfU+gijbL34oRjaEr+5q0p72zBhDeOz6h4z5nGCG6tDQ7SkBBdnSO 8Onv8eZPnrJtGMElZlRSbIs2wXrPRo3G5ONit5DwT+hS+TXXIc8yiymKnemzA1OgBcmF AQv3IcB0JD/hhEYYoJnlbebZ5Ta50frx7zbYcgOG2G2Szsrtd5wRPuWckga7XLhWxkgS 2j6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7tEisFUeThUpol2b4alduiF74rMdPMZ6O0SBAZCvulo=; b=YZlce1/44v3PmS9glFedQXoiAz7VLoysIJtHk8UZSE+v/h87SsXDYt2jfYQ/SSGnon d1V+zHJx1BY5A+uqGSccIpB8EbH6pwrZwYWe9VaNyFqNS4021ry6ThuC54VAhFgewuMT 0e6RnrFBT3aDg+KX08gNVCM66lgzS5hYSc3FCQlikAPDBIMaElLDBqmf2phfE2DPzSRj Y3rPTZFutQSCFrNrPrAYu1BeR/iygFyHv6gUrBOFqDQPMCuIVUV67MMHZvB6CZsUK8mJ qbBEIafCV322XFHnJwM2C14jR8CwEp8+hCDOmIaS/XGZWBXBG1Nm87YgEYsnMdkd23mG iMCg==
X-Gm-Message-State: AOAM531KzQeGPkFq3XqlhDXpigzzFJMh8YhdSmufz8r2IDfSi9mpdGm4 bMyanQVit4hsbVnXsl5UD3KoWYrxIMxO3mmhpwGAhg==
X-Google-Smtp-Source: ABdhPJzgxSsKLby9RSYpHmgDKUCESlWhDIC2T6DO8eUVd12T7QSnz2wTD0g7oNXQVRSOwr0aKHRggeR/qDwnkw/H1SM=
X-Received: by 2002:a05:6402:500b:b0:431:78d0:bf9d with SMTP id p11-20020a056402500b00b0043178d0bf9dmr12656635eda.184.1655300483578; Wed, 15 Jun 2022 06:41:23 -0700 (PDT)
MIME-Version: 1.0
References: <41ba8fd6-ab16-6278-ba22-91a6a632ed33@cisco.com> <B8F7E718-28A3-4F97-A171-72774F8F1ACF@tsinghua.org.cn> <a71b7df5-4f15-a3ca-6783-3304dacd945b@cisco.com> <CAOj+MMGcgP-hH6zi_7NAkfBbQoGw0Si=55XyK_uEuA76TuGJ7w@mail.gmail.com> <c713806d-6c30-c706-850b-91e3fbcd40ba@cisco.com> <CAOj+MMHZkTJ3kKdgRxFvOzZhdQYrnp1Hn2gANmu_SmntQV5-zg@mail.gmail.com> <9abe29de-d9a2-a65d-d979-c5955e00da93@cisco.com>
In-Reply-To: <9abe29de-d9a2-a65d-d979-c5955e00da93@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 15 Jun 2022 15:41:12 +0200
Message-ID: <CAOj+MMHoHiX+ZhTMRm9UtgupexvwfjiuCG+5EVO5+g4eJB7WGw@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, lsr <lsr@ietf.org>, draft-ppsenak-lsr-igp-ureach-prefix@ietf.org, draft-wang-lsr-prefix-unreachable@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005211c705e17cad4f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/vKmuIF40im__K4H-NMVYSsdu700>
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 15 Jun 2022 13:41:29 -0000

> Traffic will initially switch to alternate path, if any, an
> later the native mechanism (BGP signalling, tunnel keepalive, etc), will
> take over and bring it to its final state.
>

On one hand you are saying that UPA is useful where there is no BGP. So
let's talk about such a scenario.

Also not all tunnels have keepalives. I am talking about mGRE encapsulation
as an example where you simply encapsulate and have no idea other than
consulting RIB if the dst node is up or down.

In this discussed case it will keep sending packets to remote area only to
drop it there ... not good.

Thx,
R.

v2.23.0 | Report a Bug | By Email