Re: [spring] Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Tue, 27 July 2021 19:46 UTC

Return-Path: <gengxuesong@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3663A0F13; Tue, 27 Jul 2021 12:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inXPfTBQIk8w; Tue, 27 Jul 2021 12:46:41 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E313A0F09; Tue, 27 Jul 2021 12:46:41 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GZ6WV5DxJz6J6MF; Wed, 28 Jul 2021 03:37:26 +0800 (CST)
Received: from dggpemm500006.china.huawei.com (7.185.36.236) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 27 Jul 2021 21:46:37 +0200
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 28 Jul 2021 03:46:36 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.2176.012; Wed, 28 Jul 2021 03:46:35 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200
Thread-Index: AdeC4xoDQIJ5RvpkTLO2J426H5eusP//nCUA//8lUzA=
Date: Tue, 27 Jul 2021 19:46:35 +0000
Message-ID: <aa6163a1dfbd4612959e7afb745a45c5@huawei.com>
References: <2144efbd2c2c4559bfbc1f6e670dbc45@huawei.com> <08028B48-6CDB-44B7-9C36-023B6F782193@gmail.com>
In-Reply-To: <08028B48-6CDB-44B7-9C36-023B6F782193@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.45.104]
Content-Type: multipart/alternative; boundary="_000_aa6163a1dfbd4612959e7afb745a45c5huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Jfgfs15V413UjHlKAVMYcGhZ60g>
Subject: Re: [spring] Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2021 19:46:46 -0000

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>om>; 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
--------------------------------------------------------------------