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:basha...@cisco.com]
Sent: 05 August 2017 01:19
To: Sikhivahan Gundu <sikhivahan.gu...@ericsson.com>; rtgwg@ietf.org
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; Stewart Bryant 
<stew...@g3ysx.org.uk>
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:rtgwg-boun...@ietf.org] On Behalf Of Ahmed Bashandy 
(bashandy)
Sent: 17 July 2017 12:56
To: rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Cc: rtgwg-cha...@ietf.org<mailto:rtgwg-cha...@ietf.org>; 
pfr...@gmail.com<mailto:pfr...@gmail.com>; Stewart Bryant 
<stew...@g3ysx.org.uk><mailto:stew...@g3ysx.org.uk>
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:

internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>

Reply-To:

internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>

To:

<i-d-annou...@ietf.org><mailto:i-d-annou...@ietf.org>



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

i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to