[spring] 答复: RE: Comments on draft-geng-spring-sr-redundancy-protection

"Yangfan (IP Standard)" <shirley.yangfan@huawei.com> Thu, 20 May 2021 12:59 UTC

Return-Path: <shirley.yangfan@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 E3BAC3A1618 for <spring@ietfa.amsl.com>; Thu, 20 May 2021 05:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 0VjSz-7ndApB for <spring@ietfa.amsl.com>; Thu, 20 May 2021 05:59:01 -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 DB83C3A1616 for <spring@ietf.org>; Thu, 20 May 2021 05:59:00 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Fm8j84xscz688ST; Thu, 20 May 2021 20:50:20 +0800 (CST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Thu, 20 May 2021 14:58:55 +0200
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 20 May 2021 20:58:53 +0800
Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.2176.012; Thu, 20 May 2021 20:58:53 +0800
From: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, 'Rishabh Parekh' <rishabhp@gmail.com>
CC: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "'Rishabh Parekh (riparekh)'" <riparekh@cisco.com>, "'Arvind Venkateswaran (arvvenka)'" <arvvenka@cisco.com>, "'spring@ietf.org'" <spring@ietf.org>
Thread-Topic: [spring] RE: Comments on draft-geng-spring-sr-redundancy-protection
Thread-Index: AddLHpkEAMIRIqXpQ2aOJ04/NHpAdQBrnU7wAB19rmA=
Date: Thu, 20 May 2021 12:58:53 +0000
Message-ID: <e3e42fa3f59f4721acfd9e52f384fce8@huawei.com>
References: <101996923664441492159b346eee7d98@huawei.com> <MN2PR05MB598134731E9630AA07A9242CD42B9@MN2PR05MB5981.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB598134731E9630AA07A9242CD42B9@MN2PR05MB5981.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.115]
Content-Type: multipart/alternative; boundary="_000_e3e42fa3f59f4721acfd9e52f384fce8huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/nMA0WxNSrPX9gurYzr4eZn37w84>
Subject: [spring] =?utf-8?b?562U5aSNOiAgUkU6IENvbW1lbnRzIG9uIGRyYWZ0LWdl?= =?utf-8?q?ng-spring-sr-redundancy-protection?=
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: Thu, 20 May 2021 12:59:06 -0000

Hi Jeff,
Thank you for your explanations about the SID list encapsulation and SID process on each node. It did help a lot to understand how Replication SID can be used in redundancy protection.
I move one of your comments from the other email here to focus on the packet forwarding discussion in this thread.
As for the 3 deferred “homework”, feel free to come back when you are available.
Much appreciated with these deep discussions. Some feedbacks please see inline.

Regards,
Fan

发件人: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
发送时间: 2021年5月20日 1:43
收件人: Yangfan (IP Standard) <shirley.yangfan@huawei.com>om>; 'Rishabh Parekh' <rishabhp@gmail.com>
抄送: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>om>; 'Rishabh Parekh (riparekh)' <riparekh@cisco.com>om>; 'Arvind Venkateswaran (arvvenka)' <arvvenka@cisco.com>om>; 'spring@ietf.org' <spring@ietf.org>
主题: RE: [spring] RE: Comments on draft-geng-spring-sr-redundancy-protection

Hi Fan,

Sorry for the late response. Please see zzh> below.

From: Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>
Sent: Monday, May 17, 2021 9:20 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; 'Rishabh Parekh' <rishabhp@gmail.com<mailto:rishabhp@gmail.com>>
Cc: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; 'Rishabh Parekh (riparekh)' <riparekh@cisco.com<mailto:riparekh@cisco.com>>; 'Arvind Venkateswaran (arvvenka)' <arvvenka@cisco.com<mailto:arvvenka@cisco.com>>; 'spring@ietf.org' <spring@ietf.org<mailto:spring@ietf.org>>
Subject: RE: [spring] RE: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Hi Jeffrey,

To summarize the discussions a bit, I have two questions and hope to hear your comments and clarifications.
Q1: Are there any questions for clarifications or open issues with the current solution of redundancy-SID+Merging-SID+redundancy policy? If so, we would like to clarify them first.

Zzh> No.
Fan1>> It is very good and important if the current redundancy protection mechanism can be understood clearly in WG.

Q2:
Figure 1 in draft-geng-spring-sr-redundnacy-protection is the typical topology for Redundancy Protection in SR domain, as shown below.

ingress------A (R)-------B-------D(M)-------egress
        +------C------------+
                    +----E-------+
Could you please explain how exactly Tree-SID solution is used in data plane for redundancy protection? For example, how the SR SID List is assigned, how the packet is encapsulated and forwarded from R1 to R2 in data plane, how Tree-SID and Replication SID are configured on network nodes, etc.

Zzh> I sort of replied in my late response to the other email, but let me reply here as well because that thread was indeed getting very deep.
Zzh> I changed the letters so that we can distinguish between node representation and function representation. A is the redundancy node and D is merging node. I also added another node E.

Zzh6> Unlike unicast where you use a segment list to encode the path that a packet flows through, with multicast it is impractical to encode a (sub-)tree as a segment list. Therefore, for SR-P2MP, an replication tree is not represented by a segment list. Rather, each root/replication/leaf node on a tree installs a replication segment to represent how replication is done on that node for that tree, and only one SID is needed in the packet for it to flow from the root to all the leaves through the intermediate replication points. This is exactly like today’s P2MP tunnel in the forwarding plane. We can put aside the argument “oh this requires per-flow state” here, as it is not relevant to our topic here.

Fan1>> To differentiate the node representation and function representation actually reveals a significant difference between Replication SID and Redundancy SID.  In terms of SRv6, Replication Segment is a local and non-routed segment, and Redundancy Segment is a routed segment. And the merging segment in redundancy protection is also a routed (topological) SID with merging function.
As you mentioned, it is impractical to use a segment list to encode a tree for multicast traffic. So Replication SID only represents the replication function, moreover is designed to separate with the routed Node SID, however the benefit is Replication SID can be identical on one tree.
Meanwhile, Redundancy Segment is usually used for unicast traffic, it is straightforward to design it as a routed and functional segment. It is not necessary to separate the route and function apart into different SIDs, at least it saves one 128bit SID space.

Zzh> Let’s say that we’ll only make two copies for D to receive. A and D have replication segment R installed. R on A simply says “make two copies, one through B and one through C”. B/C do not need any state because A is simply going to tunnel through B/C respectively. R on D simply says “I am a leaf so I just pop R”.
Zzh> The ingress will send packets with SL <A, R, M>. SID A gets the packet to A, who sees R and do the replication (R is not popped by A). D sees R in the SL and pops R (this is the replication segment behavior on a leaf). It then sees M and do the merging. Alternatively, A could pop R so D will see M directly and do the merging.
Zzh> Now let’s say we want to make three copies. The ingress will still send the same SL. R on A now says “tunnel one copy to D through B and send one copy to C” and C now also has R installed, saying “send one copy to D directly and another copy to D via E”. Now three copies will arrive on D (with A/C each replicating once). D sees R SID and pops the R SID (as the behavior of replication segment on leaf). It then sees M and do the merging.
Zzh> The replication is pure SR-P2MP behavior (assuming A does not need to add FI/SN). M is pure non-topological merging behavior (relying on the FI/SN added by the ingress node).
Fan1>> Thanks for your detailed explanations in this and other email, now I think I understand how data plane works.  There are still details needs further discussion,  e.g. in terms of SRv6, if B/C is downstream nodes, in this sentence “D sees R SID and pops the R SID” pop means remove the IPv6 header, in this case M SID will not be processed. But that’s all right, there are surely a lot details if you want to design one unified Segment can work for P2MP multicast and redundancy protection, also unified in SR-MPLS and SRv6. We can surely continue the discussions.

Zzh> Thanks.
Zzh> Jeffrey

I don’t think I understand the entire forwarding flow correctly. In fact we are very interested in Tree-SID solution as it has been adopted as a WG work. It would be very helpful if you or anyone can provide a detailed illustration or comparison, for instance like the way of the Appendix in replication SID/Tree SID drafts.

Looking forward to your reply!
Best,
Fan




Juniper Business Use Only