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

Stewart Bryant <stewart.bryant@gmail.com> Fri, 20 September 2019 14:16 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03951201DC; Fri, 20 Sep 2019 07:16:48 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 JNsXIRse0NLi; Fri, 20 Sep 2019 07:16:47 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 18797120025; Fri, 20 Sep 2019 07:16:47 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id y19so6969178wrd.3; Fri, 20 Sep 2019 07:16:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wVunh6ysu4CBQsv6pP4OAmSsvsRywkToAjymCY69iJs=; b=EzA7MMoKDIQUsJBL6OOOWjmjZz00y2LC38Iwy1hJab/ue6OeoMb7Ku6rWF0h8/3wmw 47WbZLjo4qSryQrklBHwe2DUBBS68UUj1QWzEHeIFu6D9bLreACvbJG3MCSJtqlaJc6X y/eaJIebbRX/E16ZYDqbebc3edfRbmWURwyN/TOk0BiHltIy9MSu6eClqjO52BpCm2q7 A6X9aybhuLCwlr6Perlf8M8Aa5jlgr3vKEpwW2qNuSyCe/fFQvb28QBqWPVJtllxPwvp fgwT3ikGb8vb4qci0Sa4s0/cmKoYh+yPe1opXBMDHEZYJOcS8UBiXbd02OvKs73Ch/r6 PYxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wVunh6ysu4CBQsv6pP4OAmSsvsRywkToAjymCY69iJs=; b=jFJ/i2saqb4ZVpMwiIw/MbZNsPe1BtuZZn8PsQHFnTGS2cJHOw9Q0Fr5K0zo4s4Gkz ct4Lqu8cmYBSMqE6eYYREzjmKf37PsFt2gBzU9KlzA35QlxjJnK4EuwqtAvgJHI7Kpp4 Y5rbGzdJcTPmc00RH2mVdfE5d+RoRTSGWN+RssG4MaQcpswPtQp8CFBRGVj45YaF/Qk5 AwZex5W3wjs6Vd09dCGBCh7F6QD2YJ3YxjvaR7vUMiZ2Jnfj0lU1UtiAX1SI/+3EXW92 KnzK+uZ4JibpJ5rL5f4cLlDR1fpBPWZwbZM8ZBhi0hE3WnYOslkBX75kQhF6WerGQsxa Y/Wg==
X-Gm-Message-State: APjAAAU1fWc3l3W+QonhU5Nb3eqnvk6gacCf23rf9uTTxQTqQ51Us8XQ 99SqDX9VGCIb0zIQJrX9MnA=
X-Google-Smtp-Source: APXvYqwQ8qjAAQe6gVkbA2PyxkNGoQxwdb5pjwtaMg0UnshC2gs5Ji6bcNiLL7XTXpB1ElIgrHZTtQ==
X-Received: by 2002:adf:de03:: with SMTP id b3mr11461053wrm.14.1568989005589; Fri, 20 Sep 2019 07:16:45 -0700 (PDT)
Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id s9sm2442278wme.36.2019.09.20.07.16.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Sep 2019 07:16:43 -0700 (PDT)
To: Robert Raszuk <robert@raszuk.net>, Gyan Mishra <hayabusagsm@gmail.com>
Cc: 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>
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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <22ffe893-046f-945e-7232-74352dd2c138@gmail.com>
Date: Fri, 20 Sep 2019 15:16:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAOj+MMHRevSPf+Ayv=4_zgnfA-rV_BvV+7OJwrTi2T9S95oCbw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/q4m8fB0nBHgjfqvCnjOtRGeCTA8>
Subject: Re: [spring] “SRV6+” complexity in forwarding
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 14:16:49 -0000


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