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

Stewart Bryant <stewart.bryant@gmail.com> Tue, 10 July 2018 12:48 UTC

Return-Path: <stewart.bryant@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 431D012D7F8; Tue, 10 Jul 2018 05:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
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: 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 MfllnLH9n92t; Tue, 10 Jul 2018 05:48:41 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 A2A1E126BED; Tue, 10 Jul 2018 05:48:40 -0700 (PDT)
Received: by mail-wr1-x42e.google.com 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; d=gmail.com; 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; 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=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 [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id r17-v6sm13848467wrt.44.2018.07.10.05.48.37 (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 <Alexander.Vainshtein@ecitele.com>, Ahmed Bashandy <abashandy.ietf@gmail.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>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <2ff33bf0-cb23-9be2-99ac-25209876a5cf@gmail.com>
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: <DB5PR0301MB190910B15E3B74ED45B18CE19D5B0@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------98DE20E95BABED04DCAC5786"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/6yJOi0aT1RGB2Za5yL3nPmmvX5k>
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: 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: 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>om>; Robert 
> Raszuk <robert@raszuk.net>et>; 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.

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