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

Ahmed Bashandy <abashandy.ietf@gmail.com> Mon, 09 July 2018 19:53 UTC

Return-Path: <abashandy.ietf@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D26130E95; Mon, 9 Jul 2018 12:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level:
X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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 P-NftW3V3w_d; Mon, 9 Jul 2018 12:53:52 -0700 (PDT)
Received: from mail-pl0-x244.google.com (mail-pl0-x244.google.com [IPv6:2607:f8b0:400e:c01::244]) (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 8AAC312785F; Mon, 9 Jul 2018 12:53:52 -0700 (PDT)
Received: by mail-pl0-x244.google.com with SMTP id t6-v6so6504068plo.7; Mon, 09 Jul 2018 12:53:52 -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; bh=AK29GSusgRIOvKTQlqU8k4qxfaWJ++65doJC/eMZLLQ=; b=UlYAN5ZyBLWxJHTiPkdR6Is+x+j5N3VaCvonV94xCxK+paL+A9MxaPledqlzRTcTi/ uqdtuW/EB8/eVqlywNXfonJWlKZgqOJD5sx//KM38NPMzMBVdb8ROpSws/fPeXyldTH/ hBATs/VjSyUBmi9xVYtdCeADTud236GO0MoYo83vYz6RmWBy2IWTLPc6H8lM3txqNI+2 7h/wTXLKJ+y/ZJH818cxNVh+JaKqY/kM8yR8RTgXMtj/ze7icTglywbFeD/P3154TQam y9jJgHf9ir967bTH+ATZJOHNSWP5ASwiPZuFYLVwwbYD7+QMgq6+coz3rVoP29UFN27e 59ww==
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; bh=AK29GSusgRIOvKTQlqU8k4qxfaWJ++65doJC/eMZLLQ=; b=qm4IKmhg8H2BTZlQiVy5pK2UqqPbxmsEWcOqv9LeKpfu61gT3uxLkXPJNu/buR9pBO Um8AY1qgYEcFjN3YvDlbxduMeoUS1U2CAdDG8zdyD7qdx2zjGk6TjcaOBSZaBs9rGwl3 FC6jW6SGh0TDXw29wxdyTHisy8cdv73belQo+W7NpTZt0aTnxL8FON2yoC4N44jx9CVA 2Mp7DtzPC/y7lLuwe5V0jC1mC7y52nSiPSDquKmtXAj1Qry2yWohN2rkm5PTkzbV5uw/ vX20aF5Np7H32NJVOqto4RiXwKbyZll7JHTcuj1aVxt0LSQP0FX7SKYYXoOPjzOUIaT3 amiA==
X-Gm-Message-State: APt69E1l1B77fK13YRyf8JjkTKfwdxC/EL0tK6AobNIb2h314bLX3o0d i0dQyS+dH9QJCrFdeIWBmMdjl0aJ
X-Google-Smtp-Source: AAOMgpfa4QqJYCjNikzRmsJ0QfUkRef7mnvycC8P/xmR+HpCJZHuLFILynBiq7LUCNfGcI/RIIPkKQ==
X-Received: by 2002:a17:902:7891:: with SMTP id q17-v6mr22213191pll.186.1531166031961; Mon, 09 Jul 2018 12:53:51 -0700 (PDT)
Received: from Arrcus-Ahmeds-MacBook-Pro.local ([75.8.210.205]) by smtp.gmail.com with ESMTPSA id e82-v6sm50390313pfk.87.2018.07.09.12.53.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 12:53:51 -0700 (PDT)
Subject: Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Robert Raszuk <robert@raszuk.net>, Chris Bowers <cbowers@juniper.net>
Cc: "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "pfrpfr@gmail.com" <pfrpfr@gmail.com>, "draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org" <draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org>, "daniel.voyer@bell.ca" <daniel.voyer@bell.ca>, "rtgwg@ietf.org" <rtgwg@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>
References: <1e42030f-3d68-fca3-500c-95ab7303e7cd@gmail.com> <F0098308-4F1E-4596-B3F9-B6740BA88F9A@gmail.com> <bfbe9775-ee81-b1fe-bb1f-a02392bc6fb5@gmail.com> <43389eec-6d63-ee35-54ed-19562b24562b@gmail.com> <12E9EB99-2970-49B6-9407-FE6AEAB3A0BB@gmail.com> <SN6PR05MB44305802FF3330DC2AE27F9CA96E0@SN6PR05MB4430.namprd05.prod.outlook.com> <CA+b+ERm=Jczivo0sJGuHWyP7UJbJFY=+N-vyQK7H_Es2anLGmQ@mail.gmail.com> <DB5PR0301MB1909BF5C925473CB3BC97BE79D6D0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <27db8d16-6120-17e9-55fa-30d35be97b32@gmail.com>
Date: Mon, 9 Jul 2018 12:53:50 -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: <DB5PR0301MB1909BF5C925473CB3BC97BE79D6D0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------5D0AC11482785E35231BD82F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/-8xxDfYKezEuz2YQhW-JNVi1VdM>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2018 19:54:00 -0000

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 
> <https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/> 
> 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.
>
> 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 :)

> c.*Selecting the post-convergence path is detrimental to scalability 
> of the solution*. Please note that in RFC 7490 
> <https://tools.ietf.org/html/rfc7490> “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
>
> 2.*There is a serious overlap between the contents of Section 5.3 of 
> draft-bashandy and the*Node Protection for SR-TE Paths 
> <https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-02> 
> draft. I do not think that the WG really needs a replay of the recent 
> discussion between the authors of draft-farrel-mpls-sfc and 
> draft-xuclad-spring-sr-service-chaining. I, for one, would expect any 
> such issues being resolved (one way or another) */before adopting one 
> of these documents as a WG one/*.
>
#Ahmed:  Protecting explicit path was first documented in
https://www.ietf.org/archive/id/draft-francois-rtgwg-segment-routing-ti-lfa-00.txt
which is dated Aug/17/2015. That is at least 6 months prior to the first 
version of "draft-hegde-spring-node-protection-for-sr-te-paths-00", 
which is dated Mar/20/16

> There are some other comments I have on the draft, but I do not see 
> them as an obstacle for WG adoption.
>
Ahmed: Thanks a lot again
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> Email: Alexander.Vainshtein@ecitele.com
>
> *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, May 29, 2018 12:03 PM
> *To:* Chris Bowers <cbowers@juniper.net>
> *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com; 
> draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org; 
> daniel.voyer@bell.ca; rtgwg@ietf.org
> *Subject:* Re: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Hi Chris,
>
> I am afraid you have it completely backwards :)
>
> Current status of the document is individual submission and it is up 
> to the authors to decide what is and what is not in the scope of their 
> work. It can't be that anyone asking for scope extension can block the 
> work or even WG adoption call by throwing the stones at it. That would 
> be pretty insane.
>
> Now once the doc is accepted as working group document its ownership 
> transitions from given set of authors to WG and indeed WG could ask to 
> extend or narrow the scope. Again WG not an individual.
>
> For me (a WG member) the document looks good as is and should proceed 
> fast since it addresses very important technology gap. I do sincerely 
> hope that any attempt to derail it or stretch it so much that it will 
> break will be stopped by WG chairs and ADs.
>
> Best,
>
> Robert.
>
> On Tue, May 29, 2018 at 1:30 AM, Chris Bowers <cbowers@juniper..net 
> <mailto:cbowers@juniper.net>> wrote:
>
>     Ahmed,
>
>     Several participants in the WG (including Stewart) have provided
>     feedback requesting that the draft address particular issues.
>
>     The response you have provided to this feedback is that these
>     issues are out-of-scope for the draft, so they will not be addressed.
>
>     I have seen no change in the text of the draft to incorporate this
>     feedback.
>
>     It is up to the working group to decide what is the scope of a
>     document it works on.  I do not think that it would be productive
>
>     to conduct a poll for WG adoption until the scope of the draft is
>     broadened to address the feedback that has already been provided.
>
>     Chris
>
>     *From:* Jeff Tantsura <jefftant.ietf@gmail.com
>     <mailto:jefftant.ietf@gmail.com>>
>     *Sent:* Monday, May 28, 2018 4:27 PM
>     *To:* Ahmed Bashandy <abashandy.ietf@gmail.com
>     <mailto:abashandy.ietf@gmail.com>>; rtgwg-chairs@ietf.org
>     <mailto:rtgwg-chairs@ietf.org>; Stewart Bryant
>     <stewart..bryant@gmail.com <mailto:stewart.bryant@gmail.com>>
>     *Cc:* draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org
>     <mailto:draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org>;
>     martin.vigoureux@nokia.com <mailto:martin.vigoureux@nokia.com>;
>     pfrpfr@gmail.com <mailto:pfrpfr@gmail.com>; cfilsfil@cisco.com
>     <mailto:cfilsfil@cisco.com>; bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>; stephane.litkowski@orange.com
>     <mailto:stephane.litkowski@orange.com>; daniel.voyer@bell.ca
>     <mailto:daniel.voyer@bell.ca>; rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>
>
>     *Subject:* Re: Request for RTGWG Working Group adoption for
>     draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>     Hi Ahmed,
>
>     I’m awaiting Stewart’s response.
>
>     Thanks!
>
>     Cheers,
>
>     Jeff
>
>     *From: *Ahmed Bashandy <abashandy.ietf@gmail.com
>     <mailto:abashandy.ietf@gmail.com>>
>     *Date: *Monday, May 28, 2018 at 13:59
>     *To: *Jeff Tantsura <jefftant.ietf@gmail.com
>     <mailto:jefftant.ietf@gmail.com>>, rtgwg-chairs
>     <rtgwg-chairs@ietf.org <mailto:rtgwg-chairs@ietf.org>>
>     *Cc: *<draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org
>     <mailto:draft-bashandy-rtgwg-segment-routing-ti-lfa@ietf.org>>,
>     <martin.vigoureux@nokia.com <mailto:martin..vigoureux@nokia.com>>,
>     <pfrpfr@gmail.com <mailto:pfrpfr@gmail.com>>, <cfilsfil@cisco.com
>     <mailto:cfilsfil@cisco.com>>, <bruno.decraene@orange.com
>     <mailto:bruno.decraene@orange.com>>,
>     <stephane.litkowski@orange.com
>     <mailto:stephane.litkowski@orange.com>>, <daniel.voyer@bell.ca
>     <mailto:daniel.voyer@bell.ca>>, RTGWG <rtgwg@ietf.org
>     <mailto:rtgwg@ietf.org>>
>     *Subject: *Re: Request for RTGWG Working Group adoption for
>     draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>     Hi Jeff
>
>     All comments have been addressed as shown in the email below
>
>     Can we initiate the WG adoption
>
>     Ahmed
>
>     On 5/19/18 12:20 PM, Ahmed Bashandy wrote:
>
>         Hi Jeff
>
>         These comments are already addressed with the exception of the
>         minor comment about section 5.3.1 and 5.3.2. But for the
>         convenience of everyone, I will respond to each specific
>         comment here
>
>         See "#Ahmed" below
>
>
>         Thanks
>
>         Ahmed
>
>         > Reviewer: Stewart Bryant
>
>         > Review result: Has Issues
>
>         > 
>
>         > These review comments were incorrectly posted against the uloop draft,
>
>         > apologies for any confustion.
>
>         > 
>
>         > I have been asked to perform an early review of this document on
>
>         > behalf of the Routing Directorate.
>
>         > 
>
>         > Summary:
>
>         > 
>
>         > A document on this subject is something that the WG should publish,
>
>         > but I think that there are number of issues that the WG need to
>
>         > discuss and reach consensus on before deciding whether or not they
>
>         > should adopt this draft as a starting point for that work.
>
>         > 
>
>         > 
>
>         > Major Issues:
>
>         > 
>
>         > Before I get into the substance I am surprised that there are no IPR
>
>         > disclosures. In an earlier and related work
>
>         > (draft-francois-segment-routing-ti-lfa-00) there were three IPR
>
>         > disclosures.
>
>         #Ahmed
>
>         The IPR link is
>
>         https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bashandy-rtgwg-segment-routing-ti-lfa
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=i0BSrEO9trtQg-svJmisngedg7C2ALPRCMA49HKC8Jg&e=>
>
>         If there is anything else for us to do regarding IPR I will be more than happy to take care of
>
>           
>
>         > 
>
>         > The work has four basic components, the concept of resolving the
>
>         > problem of P and Q being non-adjacent, the use of SR to solve the
>
>         > non-adjacency, the use of the post convergence path following failure
>
>         > and the applicability of these techniques to an SR network. The first
>
>         > and second points seem of utility in non-SR networks, and so I am
>
>         > surprised that they are not called out as such, in the first case
>
>         > perhaps with consideration to strategically places RSVP tunnels, or
>
>         > binding segments.
>
>         The draft already mentions that the work builds on top of existing FRR work. For example
>
>         the second statement of the abstract already says
>
>            builds on proven IP-FRR concepts being
>
>            LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
>
>            (DLFA).
>
>         The statement about the possibility of using RSVP is clearly outside the scope of document as mentioned in first paragraph of the introduction.
>
>           
>
>         > 
>
>         > The issue of mapping repair path to the post convergence path to the
>
>         > something that has always concerned me in this concept. It is true
>
>         > that traffic that always passes through the PLR will experience the
>
>         > properties the authors describe, but not all traffic will pass through
>
>         > the PLR post convergence. The post failure path will be topology
>
>         > dependent, and may take a different path from the point of ingress.
>
>         #Ahmed
>
>         The fourth paragraph in the introduction clearly mentions that we are protecting the traffic passing through the PLR.
>
>           
>
>         > 
>
>         > I am also concerned that the authors do not discuss the need for loop
>
>         > free convergence, since although traffic going through the repair path
>
>         > will be loop-free, traffic arriving at the PLR might not be.. Consider
>
>         > for example a topology fragment that looks like a clock with a router
>
>         > at each minute. Traffic enters at 9 o'clock, leave at 3 o'clock and
>
>         > goes via 12 o'clock and 12 o'clock fails.  The routers 9..12 will
>
>         > re-converge at different times and this may give rise to the
>
>         > micro-looping of traffic trying to get to the PLR. A summary of the
>
>         > problem and a pointer to the companion draft may be sufficient.
>
>         #Ahmed
>
>         The last statement in the first paragraph in the introduction refers the reader to the uloop avoidance draft which handles non-local failures
>
>           
>
>         > 
>
>         > Finally on the basic concept it would be good to state up from whether
>
>         > the proposal is constrained solely to SR networks, or whether the
>
>         > authors believe that the concept is of wider applicability. It see no
>
>         > reason why it would be constrained to only work on SR networks.
>
>         #Ahmed
>
>         As it is quite clear from the title of the draft as well as many statements inside it, the scope of document is restricted to segment routing.
>
>           
>
>         > 
>
>         > There is no discussion of multiple failures, nor as far as I can see
>
>         > of failures that are worse than anticipated. This is an important
>
>         > point that needs to be established early. Some methods, (MRT)
>
>         > intrinsically address multiple failures, others (NV) intrinsically
>
>         > exclude them. Simple LFA needs a supervisor to quickly abandon all
>
>         > hope when they occur.
>
>         #Ahmed
>
>         As specified in the 3rd paragraph of the introduction the scope of the document is limited to single link, single node, and single local SRLG failure.
>
>           
>
>         > 
>
>         > In an SR network the paths used are not the shortest paths, they are a
>
>         > collection of shortest paths, so there needs to be some discussion on
>
>         > the interaction between the SR paths and repair paths to consider
>
>         > whether it is unconditionally safe against forwarding loops.. It would
>
>         > presumably be so if the authors borrowed the concept of repair
>
>         > addresses rather than normal forwarding addresses from not-via, but I
>
>         > don't think they have done this.
>
>         #Ahmed
>
>         Again the second statement of the 1st paragraph of the Introduction says
>
>           
>
>            By relying on segment routing this document provides
>
>                   a local repair mechanism for standard IGP shortest path
>
>           
>
>         So the scope of the document is quite clear
>
>           
>
>         > 
>
>         > There should also be some discussion on the original path constraints
>
>         > that are applicable to the repair. Presumably the ingress node
>
>         > constrained the traffic to go though failed node F for a reason. If
>
>         > the repair is unconstrained that reason could be violated, but this is
>
>         > not discussed in the text.
>
>         #Ahmed
>
>         Same response as the response to the previous comment. The scope is standard IGP shortest paths
>
>           
>
>           
>
>         > 
>
>         > 
>
>         > In the Security section you say:
>
>         > 
>
>         >     The behavior described in this document is internal functionality
>
>         >     to a router that result in the ability to guarantee an upper bound
>
>         >     on the time taken to restore traffic flow upon the failure of a
>
>         >     directly connected link or node. As such no additional security
>
>         >     risk is introduced by using the mechanisms proposed in this
>
>         >     document.
>
>         > 
>
>         > 
>
>         > SB> I am not sure that the above is correct. There may be a security
>
>         > reason
>
>         > SB> why a packet was steered along a path which breaks when you use
>
>         > this
>
>         > SB> technique.
>
>         #Ahmed
>
>         The security consideration section has been modified to to indicate that
>
>         the traffic is being steered over the post convergence path and hence there
>
>         is no security risk because this is the path that the operator intended to use
>
>         after the failure through the metrics configured on the links. In fact by expediting
>
>         rerouting the traffic over the intended post convergence path without waiting
>
>         for IGP reconvergence, we have introduced a minor security enhancement by reducing
>
>         misforwarding and/or traffic drop
>
>           
>
>           
>
>           
>
>         > 
>
>         > In the conclusion you say:
>
>         > 
>
>         >     The
>
>         >     mechanism is able to calculate the backup path irrespective of the
>
>         >     topology as long as the topology is sufficiently redundant.
>
>         > 
>
>         > 
>
>         > SB> That is certainly true in classic. I am not sure this is
>
>         > universally
>
>         > SB> true under SR which includes the use of non-shortest path and
>
>         > SB> binding segments.
>
>           
>
>         #Ahmed
>
>         Again the document is restricted to IGP shortest path as mentioned in the introduction
>
>           
>
>           
>
>         > Minor issues:
>
>         > 
>
>         >     For each destination in the network, TI-LFA prepares a data-plane
>
>         >     switch-over to be activated upon detection of the failure of a
>
>         >     link used to reach the destination.
>
>         > 
>
>         > SB> To make the scaling clearer to the reader, I think you need
>
>         > SB> to make it clear that for each protected link, you determine
>
>         > SB> the repair needed to reach every destination reachable over that
>
>         > SB> link. You sort of say that, but it's a bit hidden.
>
>         #Ahmed
>
>         I do not understand the difference between the text in the draft and the
>
>         text that you are proposing. We think that our text is quite clear
>
>           
>
>           
>
>         >     We provide the TI-LFA approach that achieves guaranteed coverage
>
>         >     against link, node, and local SRLG failure, in any IGP network,
>
>         >     relying on the flexibility of SR.
>
>         > 
>
>         > SB> Should that be any SINGLE link.... failure?
>
>         #Ahmed
>
>         As mentioned above few times above, the introduction clearly mentions *single*
>
>           
>
>           
>
>         > In the text (and the text that follows)
>
>         > 
>
>         >     To do so, S applies a "NEXT" operation on Adj(S-F) and then two
>
>         >     consecutive "PUSH" operations: first it pushes a node segment for
>
>         > F,
>
>         >     and then it pushes a protection list allowing to reach F while
>
>         >     bypassing S-F.
>
>         > 
>
>         > You need to reference the SR operations.
>
>         #Ahmed
>
>         This paragraph is in Section 5.2.1. The latest version refers to the SR draft
>
>           
>
>         > 
>
>         > Also you are considering Adj segments, and presumably they were there
>
>         > for a reason, but you do not discuss that.
>
>         #Ahmed
>
>         Section 5.2 discusses protecting adjacency segments
>
>           
>
>           
>
>         > 
>
>         > In 5.3.1 and 5.3.2 you have a list of conditions, but do not make it
>
>         > clear whether any or all must be true.
>
>         > 
>
>         #Ahmed
>
>         The intention is for all of the conditions to be true. I will make it clear in the next version
>
>           
>
>           
>
>         > Nits
>
>         > 
>
>         > 1. Introduction
>
>         > 
>
>         >     Segment Routing aims at supporting services with tight SLA
>
>         >     guarantees [1]. This document provides a local repair mechanism
>
>         >     relying on SR-capable of restoring end-to-end connectivity in the
>
>         >     case of a sudden failure of a network component.
>
>         > 
>
>         > SB> Grammar needs a little work in the last sentence.
>
>         #Ahmed
>
>         Addressed in the latest version of the document
>
>           
>
>           
>
>         > In Fig 1, I assume that the blobs are network fragments.
>
>         > 
>
>         > In the conclusion you say:
>
>         >     This document proposes a mechanism that is able to pre-calculate a
>
>         >     backup path for every primary path so as to be able to protect
>
>         >     against the failure of a directly connected link or node.
>
>         > SB> you need to add SRLG
>
>         #Ahmed
>
>         Addressed in the latest version of the draft
>
>           
>
>         On 5/10/18 9:40 AM, Jeff Tantsura wrote:
>
>             Hi Ahmed,
>
>               
>
>             We would like you to address the comments from Early Review and get OK from Stewart, before progressing the document
>
>               https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D00-2Drtgdir-2Dearly-2Dbryant-2D2017-2D05-2D31_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=xMxNv--9p-MRxL0OnPyOZs76OvnidWNl7oTWWXG7B3g&e=>
>
>               
>
>             Please let us know when this could be done.
>
>               
>
>             Cheers,
>
>             Jeff
>
>             On 4/25/18, 02:17, "Ahmed Bashandy"<abashandy.ietf@gmail.com> <mailto:abashandy.ietf@gmail.com>  wrote:
>
>               
>
>                  Hi
>
>                  
>
>                  We would like to request the WG adoption of
>
>                  draft-bashandy-rtgwg-segment-routing-ti-lfa-04.
>
>                  
>
>                  The draft has been stable for a long while and the IPR declaration has
>
>                  been recorded
>
>                  
>
>                  The latest version addresses all comments and the draft has been
>
>                  presented in IETF-96 and IETF-99
>
>                  
>
>                  Thanks
>
>                  
>
>                  Ahmed
>
>                  
>
>                  
>
>                  
>
>               
>
>               
>
>
>     _______________________________________________
>     rtgwg mailing list
>     rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtgwg
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________