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

Ahmed Bashandy <> Fri, 13 July 2018 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D8F9130F43; Fri, 13 Jul 2018 12:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 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] 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 mvOPL5O0MIpy; Fri, 13 Jul 2018 12:29:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E2B6130F35; Fri, 13 Jul 2018 12:29:36 -0700 (PDT)
Received: by with SMTP id e9-v6so10286pgs.4; Fri, 13 Jul 2018 12:29:36 -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=4Yr8qyxKzqM2miOL+mzfmyx9FmtZ6exGXWJqVseMvhU=; b=ENOKjhEiE6KrqCCR2FgRsa5juLmZZXnx8XRnMORm3ilht6LSPsPXZPqHydVJ7YanNI M02r0AdH+vQ6ywn8wrc3Zv4YgF9zw0zX9dEqF1s6BFhbWAgIr8go4Tvtqf4v34F3xOYY Br0OQjvhRgYb22i8V8p5ZiEiBycW9m6jxHnuGZpkm0qUpbllBxSibFwwlj4/chVZFZTz QEiCM7x1lithObEnXg/aDBnP4Wahga0clmPcuF0ontKF+WOJjNCP+hcypzzsyCCwzPRc YpCHIkiw89cI+6oAWs64PW8JWKtpvxqkOGHWIFxKHvcO0Z4Jl0+K0Vth0hGkdOHKIKho +kTg==
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=4Yr8qyxKzqM2miOL+mzfmyx9FmtZ6exGXWJqVseMvhU=; b=hvMQHvgGnCp6OW/CfkPgTDFds+6kElXEW4FNipi6jLAzkS5q4nOO103kVt4uW8ntXR Pm8CGvzHGqLI2FVkXIFkETU4c1RMgLl3Ej/f2uG7iE90gWZPFpGXMwXixyksRiUEsrSa 6xfen8T1RrsiW66XBAwYUAld3bFdx2jTg/JidNqFDiNYvSx62rHKl8HenOOdGb7Agm1w MNC09Mt7h+wyQQPTLBGZAQWwN4E9vvMm7HAPv9e9DmONQO8UGItXAlp37BAioizsoW9I Dv07jwW/Z/tlBWvCOKXwQ3VpaHZZLNeGbZ+U2+TzeZUK1/dEk9iroMsOSXQZuq+oNKEi r+qA==
X-Gm-Message-State: AOUpUlH7YAOtJRig7SlmklT0W9uKpbF2+muiTH8aG2GE/26gHQWyXGOe T0vXFspoK8siTdVofBYAXHA=
X-Google-Smtp-Source: AAOMgpcFr5zbhE1m+UBV8NLtREFuvlJvU9jT1mt94YmMPKppS2lt1DXLdTEgkk1D95T9ASn8MTcgAQ==
X-Received: by 2002:a63:f45:: with SMTP id 5-v6mr7442226pgp.447.1531510175600; Fri, 13 Jul 2018 12:29:35 -0700 (PDT)
Received: from Arrcus-Ahmeds-MacBook-Pro.local ([]) by with ESMTPSA id y9-v6sm34716640pgv.31.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jul 2018 12:29:34 -0700 (PDT)
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
To: Stewart Bryant <>, Alexander Vainshtein <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, Robert Raszuk <>, Chris Bowers <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Ahmed Bashandy <>
Message-ID: <>
Date: Fri, 13 Jul 2018 12:29:33 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------F0890FAC5488566EFF89A116"
Content-Language: en-US
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: Fri, 13 Jul 2018 19:29:39 -0000

See inline #Ahmed


On 7/10/18 5:48 AM, Stewart Bryant wrote:
> 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.
#Ahmed: I replied to Sasha

>>     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