Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

Stewart Bryant <stewart.bryant@gmail.com> Tue, 15 August 2017 17:17 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 29383132143; Tue, 15 Aug 2017 10:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level:
X-Spam-Status: No, score=-1.688 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 AAj9XyZ-K1nT; Tue, 15 Aug 2017 10:17:36 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 48BE013228D; Tue, 15 Aug 2017 10:17:36 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id m85so13303341wma.0; Tue, 15 Aug 2017 10:17: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=btIwUdeimJKJtO9wITkQ7yw0ZvinnF8ny+h83PJWRWw=; b=Ei43Cs+dkMGVuJ295oJKLuHw/3awuBqmghbEvVlV83brsg4o1kdTG1Wyhx9cYWS3w8 3RHzj4dtJVeuMjoKKNMkOUO/Er6fkzuuKvm+mWSKEIw36FjKPPj4OWVYV0z312bPW2Gm CbhLal/KWGgdp5K32UbiXE/zXzU1ogQmwb2ls6SqvyJin3VPL/H3+3M68B7iRgEWJJNI uebchbdcq3QIfn+smaNvQxgu3+bhxxAcEb/zLcFNYEYaRa6CrJZlgvRO6owPW/vkRoC5 ejIu1UGD3jS/pJoE8WLS14wT/AGRFY7uPn3n53mNmzkmhU3AfzxpV73aBqdv1VLap7gR +ksQ==
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=btIwUdeimJKJtO9wITkQ7yw0ZvinnF8ny+h83PJWRWw=; b=pCSVUGRc5F82Fps3dX8z0Wfsgh1EDRUtIyw98IZtF+qCA57ztNJB3docOlbYdmp7fv BzrpgMhxqYglUx5ocQVdQzvV9RG4k2v9u3SHhMkaamcFzUHozUt+KpfvxbTBCPrteE+Z q8FYnWvDmTBGjGCCyTrhxDd5BD78P9/qmsdP0EXKIz1S/d06oWnWCyhe6eQgW+ta1bPG 96VYLUOkRmX+ibU1G9+DECDD4CAX5lo8UQRCeztQC+EXD3OjrWfrgBKXLBO+BV0CEsfI MQ5fvORXiHLtN9uSa8LmiCIOFaq8mXaNU2cfz69e+Mg+2YcuLUfwiXAkOfeEzeoIisPU KhHw==
X-Gm-Message-State: AHYfb5jxj8HK/kRkCWuOrjkfwpxQ1ZleaFvlEjtmVFz/VULSNC167+8L w6s3S5ymLvwgUA==
X-Received: by 10.28.174.7 with SMTP id x7mr2200601wme.43.1502817454648; Tue, 15 Aug 2017 10:17:34 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 140sm2097527wmx.1.2017.08.15.10.17.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 10:17:33 -0700 (PDT)
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
To: "Ahmed Bashandy (bashandy)" <bashandy@cisco.com>, Sikhivahan Gundu <sikhivahan.gundu@ericsson.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Cc: "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "pfrpfr@gmail.com" <pfrpfr@gmail.com>
References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <HE1PR07MB1708E945640F865CA32D85F7EAB30@HE1PR07MB1708.eurprd07.prod.outlook.com> <5984CFB0.3070908@cisco.com> <HE1PR07MB170870985873654D8C0BC340EAB50@HE1PR07MB1708.eurprd07.prod.outlook.com> <b991e0eb-97f0-cd5f-96c8-7ce77d880614@g3ysx.org.uk> <5988B030.8080001@cisco.com> <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> <849700d9f030475a852096bfa51766fb@XCH-RTP-020.cisco.com> <893ad668-9f62-51a1-0835-7841e919e63c@g3ysx.org.uk> <59932016.3020201@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <17afcbce-7ced-9a34-4c41-7c37edfaf107@gmail.com>
Date: Tue, 15 Aug 2017 18:17:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <59932016.3020201@cisco.com>
Content-Type: multipart/alternative; boundary="------------AE3155AC2DB10AC0BAA3F794"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/9LISlUDzXaeWdsiBpRWTvuySSBI>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
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, 15 Aug 2017 17:17:39 -0000

Ahmed,

Let us consider this "fiction".

RFC4202 section 2.3 defines a shared risk link group as:

"A set of links may constitute a 'shared risk link group' (SRLG) if they 
share a resource whose failure may affect all links in the set."

The key work is MAY.

This means that there is some probability that all members of the SRLG 
failed, and that there is some other probability that they did not all fail.

In your draft you calculate your repair action on the assumption that 
they all failed and assert that this will be congruent with the post 
convergence path.

However from the definition of SRLG we can see that they may not have 
all failed, in which case some of the not failed elements of the SRLG 
will normally remain in service, and may provide a better path than the 
path avoiding all elements of the SRLG.  If this is the case the 
calculated repair path may not be congruent with the post convergence path.

Thus using the standard definition of SRLG this fundamental assertion in 
your proposal seems to me to fail.

You could introduce and alternative definition of SRLG:


"A set of links may constitute a 'shared risk link group' (SRLG) if  
they share a resource whose failure will effect all links in the set."

However in practice this definition can only be true if on seeing the 
failure of a single element of the SRLG you take all elements of the 
SRLG out of service. This seems wasteful of resources, but if that is 
what you mean your draft needs to specify this definition and action.

Alternatively your draft needs to state that full congruence may not 
occur and analyse the consequences of this.

Regards

Stewart


On 15/08/2017 17:23, Ahmed Bashandy (bashandy) wrote:
>
> Stewart
>
> If you think that there are other problems that needs to be addressed, 
> do not attempt to push it down the throat of our draft. Instead put 
> out your own proposal. But make sure that it has enough merit to 
> convince the WG that it is better or more comprehensive instead of 
> attempting to point out fictitious problems in others' proposals.
>
> Ahmed
>
>
>
> On 8/7/2017 1:34 PM, Stewart Bryant wrote:
>>
>> Ahmed,
>>
>> The WG decides what is in or out of scope for a WG draft, and it does 
>> this via the rough consensus of the WG, not the view of the authors.
>>
>> Of course if you wish to refocus this as an independent draft and 
>> submit via the ISE. If you do, you are welcome and I will leave you 
>> to it.
>>
>> Meanwhile the draft really has to discuss SRLGs are they are in real 
>> life, not as you would wish them to be.
>>
>> Another type of false SRLG btw is when you are doing node protection 
>> (you normally treat a node as an SRLG), but only a line interface has 
>> failed.
>>
>> - Stewart
>>
>>
>>
>>
>> On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote:
>>>
>>> Stewart
>>>
>>> I already replied to Sikhi explaining the concept of the SRLG used 
>>> in this draft and the intent to make it even clearer.
>>>
>>> IMO the scope of the draft is very clear from the draft itself as 
>>> well as the numerous responses during the previous IETF and the 
>>> mailing list.
>>>
>>> The issue below is **out of scope** of the draft and hence I have no 
>>> plans on addressing it.
>>>
>>> I hope you don’t insist on pushing out-of-scope topics down the 
>>> throat of this draft :)
>>>
>>> Ahmed
>>>
>>> *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com]
>>> *Sent:* Monday, August 07, 2017 12:48 PM
>>> *To:* Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; 
>>> rtgwg@ietf.org
>>> *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com
>>> *Subject:* Re: I-D Action: 
>>> draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
>>>
>>> Your answer did not address the issue below, which is one of a class 
>>> of issues related to SRLG.
>>>
>>> - Stewart
>>>
>>> On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:
>>>
>>>     See my reply to Sikhi
>>>
>>>     Thanks
>>>
>>>     Ahmed
>>>
>>>     On 8/7/2017 2:13 AM, Stewart Bryant wrote:
>>>
>>>         On 07/08/2017 06:45, Sikhivahan Gundu wrote:
>>>
>>>             By “ambiguity”, I meant that backup calculation taking
>>>             SRLG into
>>>
>>>             account is  based on speculated topology,  whereas
>>>             computation of
>>>
>>>             post-convergence path, ie, SPF, is based on actual
>>>             topology.  This
>>>
>>>             seems needs reconciling since in  TI-LFA the backup is
>>>             by definition
>>>
>>>             the post-convergence path, with a single path-transition
>>>             after
>>>
>>>             link-failure as the intended outcome. Do I understand
>>>             correctly that
>>>
>>>             the draft prefers to relax that expectation for SRLG?
>>>
>>>
>>>         Yes, that is a good point, in the event of an incomplete failure
>>>         of an SRLG, there may not be congruence between the
>>>         FRR path and the post convergence path. This certainly
>>>         needs further study.
>>>
>>>            *
>>>         A--------//---------B
>>>         |                   |
>>>         |  *                | cost 2
>>>         C-------------------D
>>>         |                   |
>>>         |                   | cost 100
>>>         E-------------------F
>>>
>>>
>>>         AB + CD in same SRLG
>>>
>>>         TiLFA path is ACEFDB
>>>
>>>         Post convergence path is ACDB
>>>
>>>         In this case I think that the impact is just more SR hops in the
>>>         repair path than might be needed without the SRLG, but we do
>>>         need to
>>>         be sure  that there are no pathological  cases in
>>>         topologies that lack the proposed congruence, and as
>>>         Sikhivahan notes this effect does need to be clarified in the
>>>         text.
>>>
>>>         - Stewart
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>
>>>     rtgwg mailing list
>>>
>>>     rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>>>
>>>     https://www.ietf.org/mailman/listinfo/rtgwg
>>>
>>
>