RE: Protecting SR policy midpoints (draft-bashandy-rtgwg-segment-routing-ti-lfa)

[Sikhivahan Gundu]

Drafts allow a B-Flag to be attached to the Adj-SID, which says that the
adjacency is “eligible for protection”. Such an adjacency may perhaps
also be interpreted as ineligible for SR policies that are particular that
only the selected adjacency must be used to reach the protected node.
This prevents packets from going down the (TI-LFA) repair path,  but
of course does not offer a solution with regard to mapping Adj-SID/BSID
to a non-TI-LFA backup. Perhaps more flags and signaling would be needed
for the latter.

Thx
Sikhi


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Stewart Bryant
Sent: 29 November 2017 01:36
To: sa...@axerra.com; Ahmed Bashandy (bashandy) ; Muthu 
Arul Mozhi Perumal ; vinesa...@yahoo.com
Cc: rtgwg@ietf.org
Subject: Re: Protecting SR policy midpoints 
(draft-bashandy-rtgwg-segment-routing-ti-lfa)



2. looks to be similar to 1+1 backup from the headend, which would be the 
normal default, but you have to prevent the packet going down the repair.

What would be nice would be to install a tailored backup hence:

3. Install a purpose built backup and somehow map to it on failure.

Both of these are analogous to the RSVP solutions.

Maybe to do 3 you use an SPL followed by a policy identifier so that the FRR 
node knows to abandon the repair or to pick a particular path such as a 
particular binding SID.

- Stewart

On 28/11/2017 16:12, Alexander Vainshtein wrote:
Stewart,
I understand your concern. However, as I see it, the alternatives to local 
protection of a failed pinned node of a SR-TE LSP are somewhat limited:

1. You can wait (with no traffic) until failure of the pinned node is 
recognized (e.g., fillowing IGP cobversion) and a new policy(that does not 
inckude the failed node) is recomputed and installed.

2. You can pre-compute and pre-install a backup policy that does not have any 
common pinned nodes with the original ones and, once the origibal policy fails, 
switch ti the backup one end-to-end.

My 2c.


Sent from Yahoo Mail on 
Android

On Tue, Nov 28, 2017 at 9:15, Stewart Bryant
 wrote:


On 28/11/2017 12:04, Ahmed Bashandy (bashandy) wrote:
>
> - The top label of incoming packet to node "S" is either a prefix SID
> owned by node "F" or an adjacency SID for (S,F)

If it is an adjacency SID for (S,F) then you are violating the original
intent of the ingress PE which was to send the packet along the path
S->F. I really don't think you can blindly repair such a packet since to
do so violates the policy applied to the packet. You have to do a policy
check, and you have to make sure that the packet is not subject to ECMP
along the repair path since ECMP avoidance might have been the intent of
using the SR Adjacency in the first place.

- Stewart


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

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

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[Sikhivahan Gundu]

Hi Stephane,

>> If during the timer run, a new topology change occurs (metric change, link 
>> up or down whatever it is local or remote), we need to update the

I've been wrongly assuming that the delay is applied only to those
entries that are likely to cause microloops, but now realize the draft
is advocating delaying the entire IGP routing table. In that case, any
topology change that follows the original link failure will of course
have to abort the delay.

Thanks for the clarification.

Sikhi


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: 09 August 2017 17:07
To: Sikhivahan Gundu ; Chris Bowers 

Cc: draft-ietf-rtgwg-uloop-de...@tools.ietf.org; RTGWG 
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi,

Thanks for your feedback, please find some comments inline.

Brgds,

Stephane


From: Sikhivahan Gundu [mailto:sikhivahan.gu...@ericsson.com]
Sent: Wednesday, August 09, 2017 12:19
To: LITKOWSKI Stephane OBS/OINIS; Chris Bowers
Cc: 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org<mailto:draft-ietf-rtgwg-uloop-de...@tools.ietf.org>;
 RTGWG
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi,

Requesting a couple of clarifications.

>> If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
>> ULOOP_DELAY_DOWN_TIMER is stopped

Do we stop the timer if  "new convergence" is a result only of links coming
up, i.e, no links have failed?  My interpretation of the old text,  as well as 
the
revision, is that we don't, but in the light of the discussion that this passage
triggered, it seems better to have the interpretation validated, as below:

[SLI] Let's that you have a convergence triggered by a local link down, this 
convergence will apply the ULOOP_DELAY_DOWN_TIMER.
If during the timer run, a new topology change occurs (metric change, link up 
or down whatever it is local or remote), we need to update the FIB without 
anymore delaying with the latest topology.
If we do not do so, the local router will use an N-2 FIB version while the 
other routers will start to use the latest version N this could cause side 
effects.


Imagining the IGP router to be in one of two states:
-- NORMAL-UPDATE state (FIB updated "normally"), also the initial state,
-- and DELAYED-UPDATE state (FIB updated after ULOOP_DELAY_TIMER units of time),

the draft seems to suggest the following state transitions. I'd greatly 
appreciate
validation.



---+--+-+

 current state|  event  
   | next state  |

---+--+-+

NORMAL-UPDATE|  
  | DELAYED-UPDATE |

---+  one local link failure
  +-+

DELAYED-UPDATE| 
   | NORMAL-UPDATE |

---+--+-+

NORMAL-UPDATE|  one remote link failure |   
|

---+OR  
 | NORMAL-UPDATE |

DELAYED-UPDATE|  two or more (any kind of) link failures   |
  |

---+--+-+

NORMAL-UPDATE|  
  | NORMAL-UPDATE |

---+   no link failures (only link-up's)   
+--+

DELAYED-UPDATE| 
   | DELAYED-UPDATE |

---+--+-+



[SLI] The last line should be current state DELAYED-UPDATE , next state 
NORMAL-UPDATE.





Second: remote loops are illustrated as a non-applicable scenario for this

solution. How about local link failures that do not lead to (local) loops?

Applying the delay in such a case may result in packet loss if there is no

FRR backup.  OTOH, detecting that a local loop will form  involves more

computation.



[SLI] I agree with you, that's why the draft encourages to use the mechanism in 
combination with FRR. The draft does not prevent an implementation to detect if 
a loop exists or not before applying the mechanism.





Thanks,

Sikhi


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:ste

RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

[Sikhivahan Gundu]

Hi,

Requesting a couple of clarifications.

>> If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, 
>> ULOOP_DELAY_DOWN_TIMER is stopped

Do we stop the timer if  "new convergence" is a result only of links coming
up, i.e, no links have failed?  My interpretation of the old text,  as well as 
the
revision, is that we don't, but in the light of the discussion that this passage
triggered, it seems better to have the interpretation validated, as below:
Imagining the IGP router to be in one of two states:
-- NORMAL-UPDATE state (FIB updated "normally"), also the initial state,
-- and DELAYED-UPDATE state (FIB updated after ULOOP_DELAY_TIMER units of time),

the draft seems to suggest the following state transitions. I'd greatly 
appreciate
validation.



---+--+-+

 current state|  event  
   | next state  |

---+--+-+

NORMAL-UPDATE|  
  | DELAYED-UPDATE |

---+  one local link failure
  +-+

DELAYED-UPDATE| 
   | NORMAL-UPDATE |

---+--+-+

NORMAL-UPDATE|  one remote link failure |   
|

---+OR  
 | NORMAL-UPDATE |

DELAYED-UPDATE|  two or more (any kind of) link failures   |
  |

---+--+-+

NORMAL-UPDATE|  
  | NORMAL-UPDATE |

---+   no link failures (only link-up's)   
+--+

DELAYED-UPDATE| 
   | DELAYED-UPDATE |

---+--+-+



Second: remote loops are illustrated as a non-applicable scenario for this

solution. How about local link failures that do not lead to (local) loops?

Applying the delay in such a case may result in packet loss if there is no

FRR backup.  OTOH, detecting that a local loop will form  involves more

computation.



Thanks,

Sikhi


From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: 08 August 2017 20:50
To: Chris Bowers 
Cc: draft-ietf-rtgwg-uloop-de...@tools.ietf.org; RTGWG 
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Thanks Chris, I will post a new revision with those changes.


From: Chris Bowers [mailto:cbow...@juniper.net]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Stephane,

See responses inline with [CB].

Chris

From: stephane.litkow...@orange.com 
[mailto:stephane.litkow...@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers mailto:cbow...@juniper.net>>
Cc: RTGWG mailto:rtgwg@ietf.org>>; 
draft-ietf-rtgwg-uloop-de...@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt

Hi Chris,

Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:

-  s/"otherwise the standard IP convergence MUST be used."/ "otherwise 
the standard IP convergence MUST used". It does not sound good to me but may be 
because of an English grammar issue on my side. Could you confirm the change ?

[CB]  You are correct.  That proposed change is a mistake on my part.



-  Regarding your main comment on section 1 and 2.1, I do not agree 
about your statement on RSVP-FRR. First there are multiple deployment styles of 
RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S 
and D exists with its path computed by S => no uloop in that case for sure. But 
as soon as you rely on distributed convergence, you will fall into a loop even 
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario 
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. A

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

[Sikhivahan Gundu]

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 ; rtgwg@ietf.org
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; Stewart Bryant 

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

<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

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

[Sikhivahan Gundu]

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
Cc: rtgwg-cha...@ietf.org; pfr...@gmail.com; Stewart Bryant 

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

Reply-To:

internet-dra...@ietf.org

To:





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

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