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

Ahmed Bashandy <abashandy.ietf@gmail.com> Fri, 13 July 2018 19:29 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 7D8F9130F43; Fri, 13 Jul 2018 12:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
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: 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 mvOPL5O0MIpy; Fri, 13 Jul 2018 12:29:36 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 0E2B6130F35; Fri, 13 Jul 2018 12:29:36 -0700 (PDT)
Received: by mail-pg1-x52a.google.com 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; d=gmail.com; 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; 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=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 ([75.8.210.205]) by smtp.gmail.com with ESMTPSA id y9-v6sm34716640pgv.31.2018.07.13.12.29.34 (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 <stewart.bryant@gmail.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
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>, Robert Raszuk <robert@raszuk.net>, Chris Bowers <cbowers@juniper.net>
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> <27db8d16-6120-17e9-55fa-30d35be97b32@gmail.com> <DB5PR0301MB190910B15E3B74ED45B18CE19D5B0@DB5PR0301MB1909.eurprd03.prod.outlook.com> <2ff33bf0-cb23-9be2-99ac-25209876a5cf@gmail.com>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <932429c1-8b06-126e-7db4-c7fa642e6882@gmail.com>
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: <2ff33bf0-cb23-9be2-99ac-25209876a5cf@gmail.com>
Content-Type: multipart/alternative; boundary="------------F0890FAC5488566EFF89A116"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/ygolDFdvGacgYAFxfnwjDEKzUj4>
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: Fri, 13 Jul 2018 19:29:39 -0000

See inline #Ahmed

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: Alexander.Vainshtein@ecitele.com
>>
>> *From:*Ahmed Bashandy [mailto:abashandy.ietf@gmail.com]
>> *Sent:* Monday, July 9, 2018 10:54 PM
>> *To:* Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;; Robert 
>> Raszuk <robert@raszuk.net>;; 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; Stewart Bryant 
>> <stewart.bryant@gmail.com>;
>> *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
>>     <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.
>>
>> */[[Sasha]] Well, it looks like we have been both in error here: 
>> there is a Cisco IPR Disclosure 
>> <https://datatracker.ietf.org/ipr/3068/> 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
>>     <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
>>
>> */[[Sasha]] Please take a look at the text from Section 5.2.1 of RFC 
>> 7490 <https://tools.ietf.org/html/rfc7490> (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