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

Stewart Bryant <> Tue, 10 July 2018 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 431D012D7F8; Tue, 10 Jul 2018 05:48:45 -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 MfllnLH9n92t; Tue, 10 Jul 2018 05:48:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2A1E126BED; Tue, 10 Jul 2018 05:48:40 -0700 (PDT)
Received: by with SMTP id s11-v6so14473652wra.13; Tue, 10 Jul 2018 05:48:40 -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=D4e8s2iILFQPjhJvECU23E+J3woy7hcdhkkCwugidVA=; b=KXBxJto4LJYiiXbIOZjzQwo51PID/OQPLFULSmAF4RvWHr5yTDES3a5HyGNK14UalS mvJiIpYInXDDMnDlT1u06ae5JTvhZJ198w1WwPy+o/Bh5yfo5pDGLsHSykqVnZmYmiqe nC35ZO0HifL7qt2UzEZ6ivQosNyYWcX05q/CTvnayVHxU4PKHSe7CdCe7HwzJS1/nObl ArCZl8ctZkLzzxGkK2ct97Y48IpFnnK5RxU6WsoQD06lI29BpMUHBFttYWHDwuBbRlEy oVrbfCo9eh7pE/68M0vI5J9pdFqPPpItm+VKBSkAct74/m8nTeI+j/ZOow822U9qPdTA bWPQ==
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=D4e8s2iILFQPjhJvECU23E+J3woy7hcdhkkCwugidVA=; b=WE2C6hErbYWoJ390ieru2tzUy3jeHCRVVET+ZaObZISeHTAwqrtopANRL3lVXY2mR3 neXmOsVNopaNlDaUx6wmAngSIW0dDCtPXn2e/F7sfTWuLtKIPAZXhLo/EwTbrCo/8ETc aFj0iwJ/h5K4EuRwD7pin0mL6G66bFpxGVsQjGI0B1OAIRW9jfz31JgdiaJJcWH/708C U1VdoLoV65VpRU+jGm8GBD9y7gBBnIVngirxGxnOaZguOpvdaxFMo2I3m7U7w7wWXml3 rhSzpWNCs9nbyhvwwUZZsyUBxZGzns0rRAx5EFX7bYHlbLtNV7GrCCOuna7RIe4oI7BF E4WQ==
X-Gm-Message-State: APt69E1TlN4v9uYtlV8FQ5SwVb8mT1MKpoI0RZDm9hK646o1ygAYX8w2 8UBwXwMU08ttxCtZiTTSc2U=
X-Google-Smtp-Source: AAOMgpc/DMTT7L76fZ9Jmu2fK+QFaAwTwk9/2LNfeG28XBrfCckUBQ/mvjmCbK2I/kLtR/yh1uDyQQ==
X-Received: by 2002:adf:f342:: with SMTP id e2-v6mr17136789wrp.161.1531226919142; Tue, 10 Jul 2018 05:48:39 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r17-v6sm13848467wrt.44.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 05:48:38 -0700 (PDT)
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
To: Alexander Vainshtein <>, Ahmed Bashandy <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, Robert Raszuk <>, Chris Bowers <>
References: <> <> <> <> <> <> <> <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Tue, 10 Jul 2018 13:48:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------98DE20E95BABED04DCAC5786"
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: Tue, 10 Jul 2018 12:48:46 -0000

On 10/07/2018 12:42, Alexander Vainshtein wrote:
> Ahmad and all,
> Lots of thanks for your response to my comments.
> Unfortunately I cannot say that it addresses all of them – please see 
> */inline below/*for the details.
> Regards,
> Sasha
> Office: +972-39266302
> Cell: +972-549266302
> Email:
> *From:*Ahmed Bashandy []
> *Sent:* Monday, July 9, 2018 10:54 PM
> *To:* Alexander Vainshtein <>om>; Robert 
> Raszuk <>et>; Chris Bowers <>
> *Cc:*;; 
>;; Stewart Bryant 
> <>
> *Subject:* Re: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
> Thanks for the comments
> See the reply inline at #Ahmed
> Ahmed
> On 5/29/18 3:35 AM, Alexander Vainshtein wrote:
>     Robert, Chris and all,
>     I agree with Robert that it is up to the authors of an individual
>     submission what they consider in or out of scope of the draft.
>     However, I agree with Chris that the authors of an individual
>     draft asking for its adoption by a specific WG should do their
>     best to address the comments they have received from the WG members.
> #Ahmed: Thanks a lot
>     From my POV this did not happen in the case of the draft in
>     question – for the following reasons:
>     1.In his early RTG-DIR review
>     <>
>     of the draft Stewart  has pointed to the following issues with the
>     -00 version of the draft (needless to say, I defer to Stewart
>     regarding resolution of these issues):
>     a.*No IPR disclosures for draft-bashandy*in spite of 3 IPR
>     disclosures for its predecessor draft-francois.  I have not seen
>     any attempts to address this issue – at least, search of IPR
>     disclosures for draft-bashandy did not yield any results today
> #Ahmed: Since draft-bashandy inherits draft-francois, then the IPR of 
> the latter applies to the former. But if there is a spec that requires 
> re-attaching the IPR of an inherited draft to the inheriting draft, it 
> would be great to point it out or point out some other draft where 
> that occurred so that I can follow the exact procedure.
> */[[Sasha]] Well, it looks like we have been both in error here: there 
> is a Cisco IPR Disclosure <> for 
> draft-bashandy dated 18-Sep17./**//**/This disclosure has been posted 
> after Stewart’s early review, and I have been wrong not checking for 
> it before sending this comment. But there is no “inheritance” from IPR 
> Disclosures for draft-francois either. So I think this issue is now 
> closed./**//*
>     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.”
>     ii.From my POV this is at best a misleading statement because it
>     does not really address Stewart’s comment which was about traffic
>     that */traversed the PLR before convergence/* but */would not
>     traverse it after convergence/*.
>     iii.This is not a fine distinction: actually it indicates that
>     selecting post-convergence path for repair is more or less
>      useless (unless the traffic originates at the PLR).
> #Ahmed: Thanks for pointing out this *additional benefit* of providing 
> a post-convergence back path. If a flow starts to use the PLR after a 
> failure, then the presence of a post convergence backup path on the 
> PLR extends the benefits of using the post-convergence path to flows 
> that did not use the PLR prior the topology change. I will modify the 
> statement in the introduction to indicate that :)
> */[[Sasha]] Sorry, but this looks quite off the target to me. The 
> repair path provided by TI-LFA is only relevant for the period between 
> the actual failure (that triggers usage of this path) and 
> re-convergence of IGP. I.e. traffic that did cross the PLR before 
> failure but crosses it after failure AND IGP re-convergence cannot 
> benefit in any way from selection of the repair path. At the same 
> time, it is pretty easy to give an example of a setup in which:/*
> -*/Traffic between two nodes crosses the PLR before failure/*
> -*/The destination of this traffic is protected (say by a local LFA) 
> and so will use the repair path in the interval between failure 
> detection and IGP re-convergence/*
> -*/After IGP re-convergence traffic does not pass thru the original 
> PLR anymore and thus does not experience any benefits from any 
> possible selection of the repair path by the PLR./*
> */If you wish, I can send you a simple example topology. /*
> *//*
> */So, from my POV, this issue remains as open as before./*
SB> This concern has been a day one issue by pretty much everyone that 
has seen this work.

The draft really needs text to address it.

>     c.*Selecting the post-convergence path is detrimental to
>     scalability of the solution*. Please note that in RFC 7490
>     <> “the Q-space of E with
>     respect to link S-E is used as a proxy for the Q-space of each
>     destination”  in order to provide a scalable solution – but this
>     clearly is not the case of draft-bashandy if post-convergence
>     paths are used. To the best of my understanding, the authors did
>     not, so far, do anything to address this comment.
> #Ahmed: I fail to see why there is a scalability problem. 
> draft-bashandy-rtgwg-segment-routing-ti-lfa just prefers particular 
> node(s) in the Q space if that node(s) is (are) along the post 
> convergence path.
> But if I am missing something, it would be great to point out exactly 
> what aspect of scalability you are concerned about so that we can 
> address it
> */[[Sasha]] Please take a look at the text from Section 5.2.1 of RFC 
> 7490 <> (the relevant text is 
> highlighted):/*
> Note that the Q-space calculation could be conducted for each
> individual destination and a per-destination repair tunnel end point
> determined. However, this would, in the worst case, require an SPF
> computation per destination that is not currently considered to be
> scalable.  Therefore, the Q-space of E with respect to link S-E is
>    used as a proxy for the Q-space of each destination.

> */[[Sasha]] The proxy approach described above works well enough with 
> RLFA. But it is hardly compatible with the proposal to use prefer the 
> repair paths that match post-convergence paths, because 
> post-convergence paths are per affected destination. I do not see how 
> this can be combined with selecting a single Q-space (and hence a 
> single PQ node) for all destinations./*

SB> That is a good point.

- Stewart