Re: [spring] “SRV6+” complexity in forwarding

Robert Raszuk <robert@raszuk.net> Fri, 20 September 2019 14:19 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28EF1201DE for <ipv6@ietfa.amsl.com>; Fri, 20 Sep 2019 07:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 Hmn3ktP5v8Rn for <ipv6@ietfa.amsl.com>; Fri, 20 Sep 2019 07:19:13 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 4E29E1201AA for <6man@ietf.org>; Fri, 20 Sep 2019 07:19:13 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id u184so7485189qkd.4 for <6man@ietf.org>; Fri, 20 Sep 2019 07:19:13 -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=VAWq+71tZbdGjij4eoY/51YIyzHWQdTvMNaDMqpHGQQ=; b=M68zGHxGsOjK3ubwQIPiiZwjCGrBUbea54kor3Kr+2ns8KcJvzNzFI6FOQqBmNJxa6 zECmyae4EzyxcnbXRZEBL4O2x7YpOtUHgpDdn/ct20EUQ0l2SGlmTupPHXSHKJL5kmFt DS3PYXONBhHE5dOOhjoCIeWURlrwx23z5vLl9pwhE0zGmm2xtGLfUt6x7XppADscAqBG srjELOp19fOREfLQQfBW49KeRMNUSKN/dXZmrN38cHfXVejKdp28IovcjhrQHG4Gou4x HAhV4PjVFrZDyS1dCnFgWmC7tzTS70GUrtQ4f4qNVnnHUJJLkwVkP4VkN2jCKzmt8pTL 0S7A==
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=VAWq+71tZbdGjij4eoY/51YIyzHWQdTvMNaDMqpHGQQ=; b=lEQwh8sujSxbl+vwFQsw1UefmPeuRKtmnB3VRZ3adOAea7fT1LdOYhI0+tHF7PNuI5 kldz4wyCF14vw3JVxMzzPxkvEcfohxm4SmM5dcm9UahaGX0LUMmFiMhzHjd0TyZRFUW4 9yfEd0AkFQJJIyvfYl8abwmRqMMEt7CV2hQcniDrqZ7eXZohmGCm2eZ9KqNsuqsDNDuz MOKjMUcv6njKLBd8eY2epGY4ChnAWyfbPCRW+whOLF0VnF3IiM1RuaiOJkHty3o8BLi3 z4dAe0aqhX/7mIsrWTkKyAph9g5vIkGzDzUJIGFnxWgI1YCDJKNIafe7JAALcx1M3Aac Q09g==
X-Gm-Message-State: APjAAAXleK6/DRp0EYVQ7RSRMbM50ebPa3erwZcAtAvNpzzI0H2nOloV 3vbMUNgbX2qsqS95yLzMnJLdIqdzt/pdFIgWaP1J1A==
X-Google-Smtp-Source: APXvYqz+L0ms8Cd1SsYQO7yrvapLWL5IHc2l884TLaeGuH/c74pMdEFckniyehfLHPFLCSqpqOxnB3Vo/G8RsFVQk+k=
X-Received: by 2002:a37:6144:: with SMTP id v65mr3871635qkb.465.1568989152352; Fri, 20 Sep 2019 07:19:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAHd-QWtA21+2Sm616Fnw0D-eB7SNb_BeG8-A-MCLLFgTwSpOsg@mail.gmail.com> <634900D2-FBCE-47CF-8907-C8B9CB3A4102@cisco.com> <CALx6S34=Tw-u4Hz-07-Rs-GjsungkqnD_fMoQnGc17u3VJhY1g@mail.gmail.com> <CAFqxzqYr7g2jzwJrhvjL_DXYZsDzbzqx01cy0zB1aBweDde1XQ@mail.gmail.com> <CAO42Z2yrjwRMykWxmEo5=18fMvuZdMtuyz5g1p=8oSzp_ro9Vw@mail.gmail.com> <52FDA21F-E860-45E2-846A-43B969DEDC87@juniper.net> <CAOj+MMFjCcQt7FLf9NjfEKruEYktU0iJEs8Q+qFG8Pjkt7jDaA@mail.gmail.com> <9EA2D501-4382-4071-A89C-8C593B66E2F1@juniper.net> <CA+b+ERmnw412sboPtMow6=WUFK_FW2iO+rQxOu4dQ0yV2cuukQ@mail.gmail.com> <CAA8Zg7G-Aa+mVWxax3EqJOs9V7T8Bu=mfvng8Om9bEw59D7Orw@mail.gmail.com> <CAOj+MMFuQqMcGdjLT0piyuyUNpgLka7Pn5suA+LRi+rzFeKwow@mail.gmail.com> <CAA8Zg7HtdoMtzqg6o04TjAnyg8NUaoijVi40NoUPeERcycGssA@mail.gmail.com> <CAOj+MMF7X2nar9TkvWc2LunwdL2A6pfzpvROeZ3XfCGcv4zBZQ@mail.gmail.com> <02987E0C-3512-4BDD-A888-32CF4C8EB78E@gmail.com> <CAOj+MMHRevSPf+Ayv=4_zgnfA-rV_BvV+7OJwrTi2T9S95oCbw@mail.gmail.com> <22ffe893-046f-945e-7232-74352dd2c138@gmail.com>
In-Reply-To: <22ffe893-046f-945e-7232-74352dd2c138@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 20 Sep 2019 16:18:57 +0200
Message-ID: <CAOj+MMGPqCtZbUTogtS-Le7g9_9+CCxLmz+ZY8BxhUezHJWb9w@mail.gmail.com>
Subject: Re: [spring] “SRV6+” complexity in forwarding
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Rob Shakir <robjs@google.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, Dirk Steinberg <dirk@lapishills.com>, Reji Thomas <rejithomas.d@gmail.com>, "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, Tarek Saad <tsaad.net@gmail.com>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000154e7e0592fcc1fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_64SLt2BAfJpWHLVSeXowK4RNQg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 14:19:17 -0000

Hi Stewart,

Yes this is exactly what I was trying to say. Your definition of TI-LFA as
expressed below is spot on:

"I think a better description for the technology is that it is not
constrained by topology, i.e. that you can create the repair path
regardless of the topology, although the more perverse the topology the
more SIDs are required. "

Thx,
R.


On Fri, Sep 20, 2019 at 4:16 PM Stewart Bryant <stewart.bryant@gmail.com>
wrote:

>
>
> On 20/09/2019 09:44, Robert Raszuk wrote:
> > TI - stands for Topology Independent ... all other LFA modes rely on
> > topologies to be able to compute or not the backup path.
>
> Well so does TI-LFA.
>
> At some level you have to know the topology to calculate *any* path in
> SR, else how do you know what links and SIDs to use. When you use loose
> source routing that is even more the case.
>
> Moreover since TI-LFA specifies the need to align the repair path with
> the post convergence path you have to know the post convergence path to
> do that, and to do that someone must know the topology.
>
> I think a better description for the technology is that it is not
> constrained by topology, i.e. that you can create the repair path
> regardless of the topology, although the more perverse the topology the
> more SIDs are required.
>
> TI-LFA is only independent of the topology it that it can find a path
> regardless of the topology, not without knowledge of the topology.
>
> - Stewart
>
>
>