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.
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.
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.
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) <[email protected]>
> 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/
> <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
> [email protected] <mailto:[email protected]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
