RE: Reply: Draft for Node protection of intermediate nodes in SR Paths

[Huzhibo <[e-mail]>]

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.
[cid:image002.png@01D5A922.F577D0B0]
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.
[cid:image001.png@01D5A929.956141F0]

Thank you
Zhibo

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

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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, November 23, 2019 5:20 AM
To: Shraddha Hegde <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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:[e-mail]] 代表 Shraddha Hegde
发送时间: 2019年11月22日 11:38
收件人: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: 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