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

[Stewart Bryant <[e-mail]>]

On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:
> I am not aware of such thing as "speculative, ambiguous, 
> probabilistic, stocastic,..., etc" SRLG.
>
> SRLG is one member fails, all members fail. I presumed that this is 
> understood from the many responses and discussions that we had. 
> However I will explicitly define the term "SRLG" in the draft

No. SRLG is where when one member fails you treat as if all members have 
failed. Routing then works out what actually happened.

- Stewart

>
> Thanks
>
> Ahmed
>
> On 8/6/2017 10:45 PM, Sikhivahan Gundu wrote:
>>
>> Hi,
>>
>> Thanks for your response.
>>
>> >> - Hence if the primary link fails, only "L1" will fail and L2 will not
>>
>> L1 _/may/_ fail, with high probability, but it may also not fail. If 
>> it does
>>
>> not fail, there is a second transitioning of the post-primary-failure
>>
>> link from FRR-backup (L2) to post-convergence link (L1), because L1
>>
>> has a smaller metric.
>>
>> 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?
>>
>> Thanks,
>>
>> Sikhi
>>
>> *From:*Ahmed Bashandy (bashandy) [mailto:[e-mail]]
>> *Sent:* 05 August 2017 01:19
>> *To:* Sikhivahan Gundu <[e-mail]>; [e-mail]
>> *Cc:* [e-mail]; [e-mail]; Stewart Bryant 
>> <[e-mail]>
>> *Subject:* Re: I-D Action: 
>> draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
>>
>> HI,
>>
>> All members of the same SRLG group are assumed to fail if one of them 
>> fails.
>>
>> Going back to you example
>> - L1 is in the same SRLG group as the primary link while L2 is 
>> belongs a different group
>> - Hence if the primary link fails, only "L1" will fail and L2 will not
>> - Hence only L2 is candidate to become a backup path while L1 is not
>> - Hence there is no ambiguity
>>
>> Thanks
>>
>> Ahmed
>>
>> On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote:
>>
>>     Hi,
>>
>>     The draft mandates using “post-convergence path” as the backup path.
>>
>>     It states one advantage, among others, of doing so as follows:
>>
>>     “This .. helps to reduce the amount of path changes and hence
>>     service
>>
>>     transients: one transition (pre-convergence to post-convergence)
>>     instead
>>
>>     of two (pre-convergence to FRR and then post-convergence)”.
>>
>>     This suggests to me that the assumption here is that the
>>     post-convergence
>>
>>     path can be uniquely determined in advance.
>>
>>     However, SRLG introduces ambiguity. To illustrate the point,  let
>>     us say a
>>
>>     loop-free alternative has two options: one  link (L1) is of the
>>     same metric
>>
>>     value as the primary link and is also in the same SRLG as the
>>     primary; the
>>
>>     second option (L2) is in a different SRLG and has higher metric.
>>
>>     The actual post-convergence path would depend on whether or not L1
>>
>>     also failed along with the primary, so is not uniquely computed
>>     in advance.
>>
>>     If TI-LFA picks L1, there might not be a guaranteed backup. If it
>>     picks L2,
>>
>>     there’d be two link transitions because L2 would not be in a
>>     (strict) SPF-
>>
>>     computed post-convergence path. A third option, of course, is to
>>     give up
>>
>>     declaring that there is no TI-LFA backup, but it’d be preferable
>>     to have
>>
>>     some backup than have none at all.
>>
>>     What do the authors suggest for this situation?
>>
>>     Thanks,
>>
>>     Sikhi
>>
>>     *From:*rtgwg [mailto:[e-mail]] *On Behalf Of *Ahmed
>>     Bashandy (bashandy)
>>     *Sent:* 17 July 2017 12:56
>>     *To:* [e-mail] <mailto:[e-mail]>
>>     *Cc:* [e-mail] <mailto:[e-mail]>;
>>     [e-mail] <mailto:[e-mail]>; Stewart Bryant
>>     <[e-mail]> <mailto:[e-mail]>
>>     *Subject:* Fwd: I-D Action:
>>     draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
>>
>>     Hi,
>>
>>     A new version of the ti-lfa draft has been posted to address
>>     Stewart Bryant's comments
>>
>>     Thanks
>>
>>     Ahmed
>>
>>
>>     -------- Original Message --------
>>
>>     *Subject: *
>>
>>     	
>>
>>     I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
>>
>>     *Date: *
>>
>>     	
>>
>>     Mon, 17 Jul 2017 00:19:37 -0700
>>
>>     *From: *
>>
>>     	
>>
>>     [e-mail] <mailto:[e-mail]>
>>
>>     *Reply-To: *
>>
>>     	
>>
>>     [e-mail] <mailto:[e-mail]>
>>
>>     *To: *
>>
>>     	
>>
>>     <[e-mail]> <mailto:[e-mail]>
>>
>>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>       
>>
>>       
>>
>>              Title           : Topology Independent Fast Reroute using Segment Routing
>>
>>              Authors         : Ahmed Bashandy
>>
>>                                Clarence Filsfils
>>
>>                                Bruno Decraene
>>
>>                                Stephane Litkowski
>>
>>                                Pierre Francois
>>
>>              Filename        : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
>>
>>              Pages           : 12
>>
>>              Date            : 2017-07-17
>>
>>       
>>
>>     Abstract:
>>
>>         This document presents Topology Independent Loop-free Alternate Fast
>>
>>         Re-route (TI-LFA), aimed at providing protection of node and
>>
>>         adjacency segments within the Segment Routing (SR) framework.  This
>>
>>         Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
>>
>>         LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
>>
>>         (DLFA).  It extends these concepts to provide guaranteed coverage in
>>
>>         any IGP network.  A key aspect of TI-LFA is the FRR path selection
>>
>>         approach establishing protection over post-convergence paths from
>>
>>         the point of local repair, dramatically reducing the operational
>>
>>         need to control the tie-breaks among various FRR options.
>>
>>       
>>
>>       
>>
>>     The IETF datatracker status page for this draft is:
>>
>>     https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/
>>
>>       
>>
>>     There are also htmlized versions available at:
>>
>>     https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
>>
>>     https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
>>
>>       
>>
>>     A diff from the previous version is available at:
>>
>>     https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01
>>
>>       
>>
>>       
>>
>>     Please note that it may take a couple of minutes from the time of submission
>>
>>     until the htmlized version and diff are available at tools.ietf.org.
>>
>>       
>>
>>     Internet-Drafts are also available by anonymous FTP at:
>>
>>     ftp://ftp.ietf.org/internet-drafts/
>>
>>       
>>
>>     _______________________________________________
>>
>>     I-D-Announce mailing list
>>
>>     [e-mail] <mailto:[e-mail]>
>>
>>     https://www.ietf.org/mailman/listinfo/i-d-announce
>>
>>     Internet-Draft directories:http://www.ietf.org/shadow.html
>>
>>     orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>
>
>
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg