Subject: Re: [spring] Reply: Draft for Node protection of intermediate nodes in SR Paths

From: Shraddha Hegde <[email-masked]>
Date: Mon, 2 Dec 2019 04:49:41 +0000

Hi Huzhibo,

Thanks for review and comments.

The FIB inconsistency and resulting micro-loops in IGP convergence are solved using micro-loop avoidance techniques.
The micro-loop avoidance techniques will be applied to all IGP prefixes when any change is detected.
When a node/prefix becomes unreachable, this draft recommends not to delete the state from FIB.
You bring up a good point whether micro-loop avoidance path should be applied to  this prefix or not.
I think it should. I’ll add text to clarify interaction with the micro-loop avoidance.

>And then,You say you can providing node-protection via anycast.I don`t how do you that, Any node of TE may be faulty. Do you want to
> configure the same Anycast address on the entire network?

Protection with anycast sids is explained in sec 2.2.
You do not need same anycast sid for all devices.
For ex: The nodes can be paired together and assigned one anycast SID for each pair.
Hope that clarifies.

Rgds
Shraddha

From: Huzhibo <[email-masked]>
Sent: Saturday, November 23, 2019 5:20 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]
Subject: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Shraddha:

   You say can keep forwarding plane longer. I don't know which stage of the forwarding state you are maintaining. The IGP determines the node fault by sensing multiple link faults. Because the nodes are aware of the link faults in different order, the state before the forwarding entry is deleted may be looped. Do you want to keep a loop state?

  And then,You say you can providing node-protection via anycast.I don`t how do you that, Any node of TE may be faulty. Do you want to configure the same Anycast address on the entire network?

Thank you
Zhibo

发件人: rtgwg [mailto:[email-masked]] 代表 Shraddha Hegde
发送时间: 2019年11月22日 11:38
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Draft for Node protection of intermediate nodes in SR Paths

WG,

This is the draft I pointed out that talks about solutions for providing node-protection.
It covers Anycast case as well as keeping forwarding plane longer.
https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-05__;!8WoA6RjC81c!Sb-7-2B3wu3-xnhl0t1lBXUS5SiG8RhD7hocKD88lSzJhxFE03vkai9wCaS_n0Ei$>

Review and comments solicited.

Rgds
Shraddha

---

From: Huzhibo <[email-masked]>
Date: Mon, 2 Dec 2019 08:00:45 +0000

Hi Shraddha:

     Thanks for your reply, But I ca n’t fully agree it. If micro-loop avoidance is used to solve the problem. Let us consider the following scenario.
Node B will send a packet with segmentlist<D,H>，When Node D is failure，Node B feel the link C->D failure first.
For Sid D, Node B converges to a new path using micro-loop avoidance.( In fact, since keep forwarding plane will not react to subsequent topology changes, you must use strict explicit paths, Otherwise, we have to solve another problem, such as calculating the Micro-microloop path for a node that has been deleted in the network).Packet will forwarding to Node E via micro-loop avoidance path，and Node E perform TE Node protection，Forward to Node H. If the topology of the micro-loop avoidance path changes again (have other redundant paths), the forwarding path will become even more unexpected. So there are at least three problems：
1：Traffic will be detoured until TE Path converges，However, in the controller calculation path scenario, TE Path convergence may take a long time.
2:    keep forwarding plane makes the network no longer have the ability to converge, unable to converge on new topological changes
3:   It need lots of label stack.

And for anycast solution,It has the Similar problem. Traffic will have long-time detours. Also deployment is too complicated.

Thank you
Zhibo

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Monday, December 02, 2019 12:50 PM
To: Huzhibo <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Huzhibo,

Rgds
Shraddha

From: Huzhibo <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, November 23, 2019 5:20 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Shraddha:

Thank you
Zhibo

WG,

Rgds
Shraddha

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 4 Dec 2019 14:05:58 +0000

Huzhibo,

This is an interesting problem and thanks for bringing it up on the list.

In your topology, if B is implementing micro-loop avoidance,
then when B detects the failure of a remote node (ie. D becomes unreachable in the topology),
B may already be in one of the states below.

  1.  B has programmed pre-failure SPF path to D
  2.  B had previously detected link failure C->D and had programmed a micro-loop avoidance path for the failure
  3.  B had previously detected link failure D->E and had programmed micro-loop avoidance path for this failure

After B learns that D is  unreachable,  B could take one of the below actions:

  1.  Remove the forwarding entry for D, causing traffic for D to black-hole
  2.  If B had already programmed a micro-loop avoidance path to D,

leave the forwarding plane with this path

  1.  If B had programmed a pre-failure SPF path leave the forwarding plane with this path
  2.  Program a micro-loop avoiding path to the nearest neighbor of D

The micro-loop avoidance path need not always be a stack of adjacency sids. It is possible to
apply label stack compression and reduce the size of the label stack, so it is very much implementation dependent.
Implementations can choose to apply any of the above options.

Rgds
Shraddha

From: Huzhibo <[email-masked]>
Sent: Monday, December 2, 2019 1:31 PM
To: Shraddha Hegde <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Shraddha:

Thank you
Zhibo

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Monday, December 02, 2019 12:50 PM
To: Huzhibo <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Reply: Draft for Node protection of intermediate nodes in SR Paths

Hi Huzhibo,

Rgds
Shraddha

Hi Shraddha:

Thank you
Zhibo

WG,

Rgds
Shraddha