RE: Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200

Hi Stewart,

Please find some feedback inline.

Thanks!
Xuesong

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Tuesday, July 27, 2021 10:33 PM
To: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>; 6man@ietf.org; spring@ietf.org
Subject: Re: Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200

Presumably the path is N1->N2->N3->N4 with N3 being node protected

3.  SRv6 Midpoint Protection Example

   The topology in Figure 1 illustrates an example of network topology

   with SRv6 enabled on each node.

Chen, et al.            Expires January 13, 2022                [Page 3]

Internet-Draft          SRv6 Midpoint Protection               July 2021

                         +-----+           +-----+

                         |  N5 |-----------|  N6 |--------------+

                         +-----+           +-----+              |

                            |                 |                 |

                            |                 |                 |

                            |                 |                 |

       +-----+           +-----+           +-----+           +-----+

       |  N1 |-----------|  N2 |-----------|  N3 |-----------|  N4 |

       +-----+           +-----+           +-----+           +-----+

          Figure 1: An example of network for midpoint protection

I do not understand why the problem is not simply solved by having N6 host the N3 SID but advertise it at very high cost.
[Xuesong]"having N6 host the N3 SID" -> I'm not sure I understand the meaning of it, could you give some further explanation?
"advertise it at very high cost" -> There is  no advertisement mechanism defined here. What has been defined is just the behavior of the repair node which could be found in section 4.

The packet will never transit N6 pre-failure because N6 is not a SID in the SID list and it will be to expensive to go to N3 SID via N6.
[Xuesong] Yep, when there is no failure in N3, the packet won't go through N6;

When N2 detects that N3 has failed it will look for an alternate path and TI-LFA will send the packet to N6 which will see the N3 SID and process it sending the packet to N4.
[Xuesong] When N2 detects that N3 has failed, it could not find the path to N4 through Ti-LFA, because the destination address of the packet is still N3, which can't be reached now. Only when midpoint protection defined in this document is abled in N2, it could do the proxy forwarding and update the DA with N4 SID and then it is possible to find an alternate path to N4 through N6.

I must be missing something here, because this looks like a simple fix with no protocol change.

What am I missing?

- Stewart

On 27 Jul 2021, at 13:34, Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>> wrote:

Hi 6man,

We have proposed an SRv6 local repair mechanism to provide endpoint protection. The document could be found in:
https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/
The basic idea is quite straight forward: when the node finds that the neighbor, which the packet is supposed to be forwarded to, is an endpoint and it has failed, the node will do the proxy forwarding, including: SL--, replace the DA with the segment of the next endpoint, and forward the packet based on the DA.
Considering that the repair node which does the proxy forwarding could be a transit node, it is discussed in SPRING WG whether it violates RFC 8200; if it does, whether this behavior is allowed to provide local protection for endpoint.
We would like to hear the voice from 6man about this topic. Looking forward to your comments.

Best
Xuesong

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------