Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

Stewart Bryant <> Thu, 12 July 2018 13:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13594130F08; Thu, 12 Jul 2018 06:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZaBJyINvnUZ6; Thu, 12 Jul 2018 06:28:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB9C6130DE2; Thu, 12 Jul 2018 06:28:56 -0700 (PDT)
Received: by with SMTP id a3-v6so12496522wrt.2; Thu, 12 Jul 2018 06:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=lOh0fFGwo4TCXUcBkV6AGEKLNLBPgIoNqAcBh1Bdftg=; b=MaNQr1JiXvQzmB54kiRjTl6A9cRBNH1ZSeefnG+bXc6H2enacSKbaOt1bf9jZvdsUi 3Kf2iH8rw+5IMbButYHP9kiA/2DxpPV/VgrwpFC+FOJNGeP0lZdoonCl50rqqqIhbmKg bA8GTX1YwhQDDR71Y/v4py3iYQWax1xPjRjupTqvb5yzsZCPQGZXI5RWF5yxqQ2E4Gmg fA6L7Ilq9xnQOIizh1DxaqvBS/OCgBArjXouDSbWevh+XUAmx1rgVJLGcjvaA59a5r6Z 2YNBmhnk/atfMRve4OUrhV4KvKD5zaSiu92iNf293DYdEireTBKPx9355XRUhKUT6gXz DlxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lOh0fFGwo4TCXUcBkV6AGEKLNLBPgIoNqAcBh1Bdftg=; b=Xs8hdxODsJklv1jrW56RbuSvMY4E4OQnPAQuoQyeFCwwSZXwYmhqOFI2ns8rRokkyM DRYoujD/6LJhCmuuYfYKX+S9TriW77A4FSADQTGcyP++CpUozg04SPQDmz5YGrgwvKj/ rsg9m1TBvgPG21pioPGndCWrB1+awb13/W6QM2Zi2aXm7h2q2Lr+2i8lWZF+lhzPI2Xq qbJFsBhKq9dMfJyWkpWPHf4hCGqBTweMoGAtYYOcIZkioTM5WK7wNHaoJ93cqTtcFnU8 p1GlPiP3SjcgfHL8KDCanKxUR0/bKNmKlPInCyLkcyqFvG+128DR3Vt0kChUfd38u6rr UibQ==
X-Gm-Message-State: AOUpUlEx7ILgGirUBVVBCDJAyqCKEJELLTQsJUhKEcNmZFzLfFyVc56e KTmTLPi4lvW1Tv5zI0Qy4xU=
X-Google-Smtp-Source: AAOMgpeaLTKv2AVaSJpEj7tVaEspQ5g0GN8crVJE+RfkpZ2rjjB/bFIKla4LNYhc1csWzP4i2WuZ0g==
X-Received: by 2002:a5d:48cd:: with SMTP id p13-v6mr1962433wrs.0.1531402135184; Thu, 12 Jul 2018 06:28:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id b190-v6sm6990141wma.24.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 06:28:54 -0700 (PDT)
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, Ahmed Bashandy <>, Alexander Vainshtein <>, Robert Raszuk <>, Chris Bowers <>
References: <> <> <> <> <> <> <> <> <> <> <30046_1531388953_5B472419_30046_355_1_53C29892C857584299CBF5D05346208A47AEA48D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Stewart Bryant <>
Message-ID: <>
Date: Thu, 12 Jul 2018 14:28:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <30046_1531388953_5B472419_30046_355_1_53C29892C857584299CBF5D05346208A47AEA48D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------2D0BF83FD240713E656509CD"
Content-Language: en-GB
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jul 2018 13:29:00 -0000

On 12/07/2018 10:49, wrote:
> Stewart,
> Please see 1 comment inline [Bruno]
> Trimming the text to ease the focus on this point
> *From:*Stewart Bryant []
> *Sent:* Tuesday, July 10, 2018 2:40 PM
> On 09/07/2018 20:53, Ahmed Bashandy wrote:
> […]
>     b.*Selecting the post-convergence path *(inheritance from
>     draft-francois) does not provide for any benefits for traffic that
>     will not pass via the PLR */after convergence/*.
>     i.The authors claim to have addressed this issue by stating that
>     “Protection applies to traffic which traverses the Point of Local
>     Repair (PLR). Traffic which does NOT traverse the PLR remains
>     unaffected.”
> SB> It is not as simple as that, and I think that the draft needs to 
> provide greater clarity.
> I think there will be better examples, but consider
>               12
>       +--------------+
>       |              |
> A-----B-----C---//---D----E
>         10  |        |
>             F--------G
> Traffic injected at C will initially go C-D-E at cost 2, will be 
> repaired C-F-G-D-E at cost 4 and will remain on that path post 
> convergence. This congruence of path is what TI-LFA claims.
> However, a long standing concern about traffic starting further back 
> in the network needs to be more clearly addressed in the draft to 
> clearly demonstrate the scope of applicability.
> For traffic starting at A, before failure the path is A-B-C-D-E cost 13
> TI-LFA will repair to make the path A-B-C-F-G-D-E cost 15 because 
> TI-LFA optimises based on local repairs computed at C.
> After repair the path will be A-B-D-E cost 14.
> [Bruno] The draft is about IP Fast ReRoute (FRR).
> FRR is a local reaction to failure, so by hypothesis, all nodes but 
> the PLR are not aware about the failure. This includes all upstream 
> nodes which do keep forwarding traffic through the same path, i.e. via 
> the PLR.
> The argument that the path would have been shorter if upstream node 
> were aware of the failure to reroute before (or that the PLR should 
> send the packet back in time) is not relevant.
That is not the point I am making.
> The only question which matter is: from the PLR to the destination, 
> which is the best path to use?
> I, and the draft, argue that the best path in IP routing, is the IGP 
> shortest path. Whichever type of metric you choose (e.g. bandwidth, 
> latency, cost…). Do you disagree on this?
Correct, but you miss the point I am making.

The draft goes to considerable effort to constrain the FRR path to the 
path that the traffic arriving at the PLR will take post failure. 
However, the point illustrated by the network fragment is that not all 
that traffic benefits from that effort. In the draft you assert post 
convergence advantage to you approach, but do not seem to make it clear 
that this is a partial benefit and not a universal benefit.

Depending on the specific advantage of constraining the path, this might 
be worth the complexity, or it might be better to use RLFA, or MRT or 
any one of the other technologies.

Also you really need to make it much clearer that the uloop avoidance 
properties (a big selling point of this technology) only apply to the 
traffic that will continue to arrive at C and that if any traffic will 
take another path you MUST implement an avoidance strategy.

- Stewart

> Now, eventually we can narrow down the discussion to the choice of 
> terms. We can discuss about the term “post-convergence paths from the 
> point of local repair »,which you don’t think to like. Although, the 
> term seems technically true to me, I would also be fine with changing 
> from  “post-convergence path” to “optimal IGP shortest path”
> So the draft needs to make it clear to the reader that TI-LFA only 
> provides benefit to traffic which traverses the PLR before and after 
> failure.
> [Bruno] No, that is not true. cf above.
> --Bruno
> Traffic which does not pass through the PLR after the failure will 
> need to be traffic engineered separately from traffic that passes 
> though the PLR in both cases.
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.