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

"Yangfan (IP Standard)" <shirley.yangfan@huawei.com> Fri, 04 June 2021 17:01 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 8795B3A193D for <spring@ietfa.amsl.com>; Fri, 4 Jun 2021 10:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 CHit34GjNhJR for <spring@ietfa.amsl.com>; Fri, 4 Jun 2021 10:01:25 -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 322923A193B for <spring@ietf.org>; Fri, 4 Jun 2021 10:01:25 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FxTMK6QB9z6S1Rr; Sat, 5 Jun 2021 00:52:13 +0800 (CST)
Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 4 Jun 2021 19:01:22 +0200
Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) 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; Sat, 5 Jun 2021 01:01:20 +0800
Received: from nkgeml702-chm.china.huawei.com ([10.98.57.155]) by nkgeml702-chm.china.huawei.com ([10.98.57.155]) with mapi id 15.01.2176.012; Sat, 5 Jun 2021 01:01:20 +0800
From: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, 'Rishabh Parekh' <rishabhp@gmail.com>
CC: "'Arvind Venkateswaran (arvvenka)'" <arvvenka@cisco.com>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "'spring@ietf.org'" <spring@ietf.org>, "'Rishabh Parekh (riparekh)'" <riparekh@cisco.com>
Thread-Topic: =?utf-8?B?W3NwcmluZ10g562U5aSNOiBDb21tZW50cyBvbiBkcmFmdC1nZW5nLXNwcmlu?= =?utf-8?Q?g-sr-redundancy-protection?=
Thread-Index: AdchqNboBkzcTc+pQz2/1sLPSorrgABEdhUgAIVha+AAAImLwAHmSsLgASzOUAAAAaZygAIiMz4AAJKP04AAM75J8AAIDMiAAB7YCQACO6iLAABeC7xQAS6yb4ABZ7XmgAHOMdnw
Date: Fri, 4 Jun 2021 17:01:20 +0000
Message-ID: <5db849d52f624318b6f81d77cd0b3ed3@huawei.com>
References: <MN2PR05MB59812099F115C3FF43CA9077D4629@MN2PR05MB5981.namprd05.prod.outlook.com> <59384be985ae4d3bb9563bed2642bff1@huawei.com> <BYAPR11MB300030B313D45266695FA702DE7E9@BYAPR11MB3000.namprd11.prod.outlook.com> <MN2PR05MB5981AA3B0A5E0D6DDB60F46FD47E9@MN2PR05MB5981.namprd05.prod.outlook.com> <1e2ad2d64da24714bc50f64b3d39361f@huawei.com> <CABjMoXbTqmqPg6n7No1u7g3KZPFDDb8RX6CQgxZc1oWQnykTng@mail.gmail.com> <MN2PR05MB598197148CCF3C8F3C679836D44E9@MN2PR05MB5981.namprd05.prod.outlook.com> <d135ba6e0fbd452391922a0f26db00b7@huawei.com> <MN2PR05MB598195F475E282394FCE2E6FD4409@MN2PR05MB5981.namprd05.prod.outlook.com> <1940cc0fea6647bdb3bf6743e1edc4f6@huawei.com> <MN2PR05MB598120A50B2AF4E0FE75A38DD45F9@MN2PR05MB5981.namprd05.prod.outlook.com> <45e6f85736f145d08c430df0e3d6cb28@huawei.com> <MN2PR05MB5981071A7142D1260AC75FB5D4539@MN2PR05MB5981.namprd05.prod.outlook.com> <f2e1983d56614907ba3d934ad1c073bd@huawei.com> <MN2PR05MB5981C130C3B3D31227A3D857D42B9@MN2PR05MB5981.namprd05.prod.outlook.com> <BL0PR05MB5652C53CBDB6BED7384AA452D4249@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5652C53CBDB6BED7384AA452D4249@BL0PR05MB5652.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.45.164.127]
Content-Type: multipart/alternative; boundary="_000_5db849d52f624318b6f81d77cd0b3ed3huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/pH72Y9GSSjuGIwb4OMlFcVdeB5A>
Subject: [spring] =?utf-8?b?562U5aSNOiAg562U5aSNOiBDb21tZW50cyBvbiBkcmFm?= =?utf-8?q?t-geng-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: Fri, 04 Jun 2021 17:01:31 -0000

Hi Jeff,

One single comment starts with Fan1>>.

Regards,
Fan

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

Hi Fan,

In this email I will focus on two points that I deferred earlier. I snipped unrelated text.


…
Fan 4>>: I re-thought the adding of FI/SN last week. Adding FI at the SR ingress node may also bring benefits. Ingress node usually identifies the service, for example L3VPN service, or L3VPN service with a specific DSCP value. Thus, for some services, it would be easier for ingress node to identify a flow needing redundancy protection. I don’t deny this possibility.  However, I believe FI can be added equally either at ingress node or at redundancy node.
With regards to SN, redundancy node is still the best choice. There is another thread in DetNet discussing about the sequence number state. https://mailarchive.ietf.org/arch/msg/detnet/zDBweFj3g4L2KtukueMBD_tclpM/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/detnet/zDBweFj3g4L2KtukueMBD_tclpM/__;!!NEt6yMaO-gk!SFu4iFEUSQn3gHkdUctEVeB8tdd5-Dxs7Sqok8oOp8q5taMhsLcfGOx87mub1BZP$>
People believe there is sequence number state maintenance in replication function, elimination function and reordering function. In this case, SN had better to be added at redundancy node.

…
Zzh6> I will not try to get away with keep deferring things. So far there are three things that I have deferred: 1. Why I think it’s better to do the SN at the ingress 2. The email thread you referred to above 3. This one. I will come back to them 😊


I don’t see how the email thread you referred to leads to that the redundancy node should add the SN.
Moreover, in the relevant draft-varga-detnet-pof there is the following figure(the red numbers after the R/E nodes are added by me to indicate different PRF/PEF nodes):

                                          +------------+
                +---------------E1---+    |            |
   +----+       |               |    +----R3--+        |          +----+
   |src |-------R1          +---+             |        E3----O----+ dst|
   +----+       |           |                 E2-------+          +----+
                +-----------R2                |
                            +-----------------+

   R: replication point (PRF)
   E: elimination point (PEF)
   O: ordering function (POF)

Notice that POF node is after the last PEF, which means the flow itself must have its SN.
Also Notice that E1 is after staggered R1/R2 and E2 is after staggered R2/R3, which means E1/E2 must rely on the SN in the original flow, not on the SN added by R1/R2/R3.

Fan1>> I agree with you, in DetNet FI and SN are added and removed at the edge nodes. In terms of DetNet in MPLS, FI is identified by DetNet service label, and RFC8964 specifies DetNet S-label in many aspects.
Redundancy protection in SRv6 may go beyond the specification of S-Label in MPLS DetNet. Actually I was thinking we’d better include all possibilities in the draft, adding FI,SN either at the headend or redundancy node, just put an extra check point at redundancy node.

Fan


Jeffrey


Juniper Business Use Only