Hi Stewart,

Please find some feedback inline.

Thanks!
Xuesong

From: Stewart Bryant [mailto:[email protected]]
Sent: Tuesday, July 27, 2021 10:33 PM
To: Gengxuesong (Geng Xuesong) <[email protected]>
Cc: Stewart Bryant <[email protected]>; [email protected]; [email protected]
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) 
<[email protected]<mailto:[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/
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
--------------------------------------------------------------------

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to