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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Wed, 19 May 2021 15:57 UTC

Return-Path: <zzhang@juniper.net>
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 A21BC3A15A6 for <spring@ietfa.amsl.com>; Wed, 19 May 2021 08:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.386
X-Spam-Level:
X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=rKMiAun1; dkim=pass (1024-bit key) header.d=juniper.net header.b=cFN/8q1G
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 Ure4J2_8JEhD for <spring@ietfa.amsl.com>; Wed, 19 May 2021 08:57:17 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4985E3A15A0 for <spring@ietf.org>; Wed, 19 May 2021 08:57:17 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14JFedQ0016286; Wed, 19 May 2021 08:57:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=1/mMS2yAdECUb+iVNbgdgrWEEjnrsLZpYTIH/BqMjJM=; b=rKMiAun1dkzB28AFgOzGUdiZaVpFUHaq82NujD01GaE5flUN7RRSSrzJYMby9TDXNi+d hbgRE9Hp1NfyxNai09Km//xgIB0jUNrl1WxlCZ+Bqh1Z0P9hCl97C6yEK6Yf39l65pRG ZQNiMH5i78Qvo6XuJVf4QYjGIAJ7ObRnpSYp5NOqVDL+QEtoN6jZhTQXcn++R5nbhg1n ktowfCZewxaDZJm8XGVsIGtNsrsvslU7nhQ/GG/u8O32AiOrbPtZzDxX4TdsAwgFJ15r B8JI1sB+nwKabBXLPEe7sVePQ0otJ1UmWflXV3JtW6XDbLCElrw0R+MCK7mS1uznSEaG Qg==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by mx0b-00273201.pphosted.com with ESMTP id 38mtr3h4mq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 May 2021 08:57:05 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vq2nXb5eIo75VoJ24JYLj4YCoZXHMFCfZJLYCmzNV+z10tvi5/3zpGB9x5wo9y8oionQnY58c6QVEhYSzcbMWrClBYNexn33rMDW+A9tLqj23WJ9uDW+SCKmYYpaSwOSarYtel+qImV18/9DfAXfJI8ZHCycKDAUH4pFQdJCsVHAzBKAaXMnCHRhl9ejjc+gvrbyhSIrdWkdrp1YB9KdFO7BBOI/4/JLTloBmsArff7qQIZpZDLC+PdjXIun49BgAG78YNe+My1ONmv7qon2DfzJbweVwdiL/1/KTtBm29qBddtWr8yKcNS7hors1EO5bbhWO3+IkotFRCNwXgZIoA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1/mMS2yAdECUb+iVNbgdgrWEEjnrsLZpYTIH/BqMjJM=; b=htCnV7NVnT8Pt1KHT7nVS6sHh9Yst4x9+oDnak50OYp94veVxrRsRi3jrmXOxe/qBiPYrNGUOq1lyy2PeOwlhpqfmfqQgZERrITWeyaY6XWGPYlsBMRqh32VpA7PugFYD/gM6XFCXg04HcMx117j9fg2NlS1I3Qdn8N7ZsdviJhtlNi4q/InzZuNf+xXBZVmz3789v1ClFThJofjV65wBB1pMArx4+C/a0kNbUugVh9oiCEhwDw5c3pfi50GhIVYTffKdsivoMar8T+QxWaStt2U9193UKlUpDCE7PyMENkh+ryiPyF+o3wR4qNOCayvh67QAO5PhaNX409Akn+Exg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1/mMS2yAdECUb+iVNbgdgrWEEjnrsLZpYTIH/BqMjJM=; b=cFN/8q1Gv4KHRqFY17Zq02zGawww0dqidmnRLrrNPMPbTrK0T28fMaddaAhoTl4bkCsUyVFuqJjczRkEa6BRfWGiST6W4CjWFcsuHR3cqT9V/msPhybgCugk8w408sQ9s0i3QmJ2mziDnvl9vuyOxQpzSf09CH4kpfcIXnSBcTk=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB5982.namprd05.prod.outlook.com (2603:10b6:208:cf::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.11; Wed, 19 May 2021 15:57:02 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::3d02:6545:33ae:275b]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::3d02:6545:33ae:275b%7]) with mapi id 15.20.4150.019; Wed, 19 May 2021 15:57:01 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>, '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: =?utf-8?B?W3NwcmluZ10g562U5aSNOiBDb21tZW50cyBvbiBkcmFmdC1nZW5nLXNwcmlu?= =?utf-8?Q?g-sr-redundancy-protection?=
Thread-Index: AdchqNboBkzcTc+pQz2/1sLPSorrgABEdhUgAIVha+AAAImLwAHmSsLgAT2R2AAAADaJAAJJi5SAAGfX99AALp6kgAAPIQGAABP7hwAAFt5B8AKlMWoAARToERA=
Date: Wed, 19 May 2021 15:57:01 +0000
Message-ID: <MN2PR05MB5981C130C3B3D31227A3D857D42B9@MN2PR05MB5981.namprd05.prod.outlook.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>
In-Reply-To: <f2e1983d56614907ba3d934ad1c073bd@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=38406765-dc4a-4a6c-9dcd-3d0737da162f; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-05-19T13:29:34Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [71.248.165.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b3c18141-6c9d-44e1-ff25-08d91adebdc3
x-ms-traffictypediagnostic: MN2PR05MB5982:
x-microsoft-antispam-prvs: <MN2PR05MB59827138AB008962EECF2820D42B9@MN2PR05MB5982.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WoAL8i6NUB1b2hw7zvcVf/4ReFHyRX3gmUkC799tXDxTkjad9xBM+Lf4QBQn0Yyvil3gDJDBIWRM5YGFsfBEd+XjW31Pizy2885phr5090KMZg3pHfki7oPUxN36LJaTpDjz2GJOei14FARX1UrftBVO3Le+dOPVHe/3jBdNkcxkNIYz3iqHGYEWd6yrOeuwaGRAoc4Ttpsa4GWUIp87OzU4bFojbdxw11u/UEZmdlcqDayzCnvFekGAkjz80iWhxdtbQjLjqR0LYV3urHX3mJBdfw0gXJD9cZb89GtZbodz2BIl1xrisB4JrzPelLE0KFPjzcdqbL74CVJdE/C3/HLCBmljAtelTiQVOMhg2xq+FBYKN3fqDA8EE4hG/E6KjSbAD/ZR9DuZmgIuDef7Y0sL0V7BZPn6n6Jd+wn3jr1suqKd2YU0H3Ya1757GnURC8QU3stQRIyWfr3XhyO9v09OwtfW8hWjOA2YoQJAZtcbIypzuz+YggUf6AxCuB8Rd1NxRf9VqdO8DUNq++FkhNdas5FnHka6Jwo5coQwSAWM5SJAQQD9VozPu16Xm3uKQDR+Y2Sa9s93MrD7zhd+sCyKbBp1Iddo5jGhYI/yi35KgtbLtg2YWGbPUvBsVnZZGNutR5Lt7mnCoBI/h1Z/RqyK5ZZcv5+ugcIeHMSoQyM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB5981.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(8936002)(316002)(6506007)(76116006)(9686003)(71200400001)(166002)(33656002)(2906002)(110136005)(478600001)(66556008)(64756008)(7696005)(9326002)(224303003)(66476007)(54906003)(66946007)(66446008)(53546011)(55016002)(5660300002)(38100700002)(26005)(966005)(52536014)(86362001)(122000001)(83380400001)(4326008)(186003)(30864003)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?b0dYcEtwZXduL3hBc0NLVVVXZHdDK1VGc2F5TnkwQWZxS1ZUeFZPMDlrY3BP?= =?utf-8?B?cGdETW5SajRiY21CUmRySFBzMURrWkxHcGVWTFdrR3pwNVptN0FEZXlTeStC?= =?utf-8?B?YUduNmhZaytEMmlRRkRhQ1hJZThUZjY5VGw2NVhqYjMrY1ppTU44Z0JGbXNT?= =?utf-8?B?a1lIR1NaN3pJTGcreHFwcXpzZ0N6NDVsNnUwbUpkVnNONElINzJDcFN2ODk0?= =?utf-8?B?T2J3Ykt5dVlmU1NuWUhoK3docUtUODVNdGN2ZzJWOXdjYlF2NFJxL2MwOHlJ?= =?utf-8?B?TDVBdEdWeFdTY09pV3NqaEJPNjV4cS9CS2wzN3FwKzJaNFhTNCs3MW85QXda?= =?utf-8?B?d3VJelR5d3NZQnA4NlVTTndmRkc0NE1NUW42M3VxV05FenloamRiUUVIUFRr?= =?utf-8?B?RWFhcjBmeERvUVdXZDMvSWhrMnJlODZodVRFOTFONjI2UzNZMyt0b2V5NEFj?= =?utf-8?B?SzREd3RxMUx0MGNVU29RNkhSSXB4KzlwMjFnbEVURGJSZjViV0JJWUl5Vm4z?= =?utf-8?B?cHdqNU5FOWJRMUN4L3ozeWt4emJWc1ZabHNiaG1hNi94aTFIVmlnZm96RGlz?= =?utf-8?B?ZWgvZlpjNTdNNWxsN1FvQkJzSGRXa3RvUmlZdFBqbEhNOWpDUVFISFZ4Sjk2?= =?utf-8?B?R0xXWTIyTVVvaU5IY3MzM1VRRmpDL1RRQzA3UjhYZVAwYXIyUmwvT3cvaVZN?= =?utf-8?B?Tzl5L0pUSWZNM21wNkpTc2FjZXdkM1k4ZkN4YlNVMFV0SXA2MVJLTkRDZGlF?= =?utf-8?B?WUU5UXRXaTBWN1lRQzErMkM1SUwwN3dxcG5WclFiZFNCaW4yY2JOdHFqdE52?= =?utf-8?B?ejQ3L3UwN2hUeFYrK1pkZVdOQmw5NDVreklNM0laTm1QbUVMdXhSMnN4YURO?= =?utf-8?B?YUo4Um4zckdGTXA5bmRIOWVrTVVMeTlLS3ZmQ1VkTUdYVTVpckJIN2tzZ3V5?= =?utf-8?B?ZmJkbXZQd2hJaXRHSFNNQzRuNndoYWRYNlkxWEhwdUN3M2lBS1hXSXk0b2dh?= =?utf-8?B?NmM0dmZrMU9kOHZscm80THNOSkM5dkViREFpakFQK0huSnQ3cmdnTHlQemlw?= =?utf-8?B?bzBrK3BGYzczZG80T2xzMlh0ZkQvSXpVczlVdkdQOXg4eXhBUFkwT1hQWWx4?= =?utf-8?B?Y3NYMHhqdUJBbWJaUjlOYkdYMFVOcFJjdnRpQkpDc29RV01OQk5ZRFdmTVY3?= =?utf-8?B?UHdOc01Ca0Jod05pcWNJR1dXNHJKUXlRMDNrcWJIdFpuaURzYkN6NzZhRlc5?= =?utf-8?B?MmF2bmVUTTlMUTZkbVU3LzhhcCtBNFAyV0JDUHhnL09XN0xmVm4vaklSaito?= =?utf-8?B?V2kxZHd6NDlVeVd0RUpuaTdUbDArekZLa0QzOE5KQ3BaNllSeEpOSmlpMzZo?= =?utf-8?B?TDFKaGtnYzNNNjFFOEd1VVY2Z0xpbE5zNkdwVVhEK3JVVG02RE5QVjZKTW9C?= =?utf-8?B?c3FNeDZpSXJ1clFUTEZHaG1rZHhJbzZXRktsUERhaHRiVTlkdVZYb1IxaUFj?= =?utf-8?B?OW0wcDhKWUhsY3hrWnZiRjBjNlRyQ1pYem54c3RDWFB4ZmU0N1dnak5TSHp2?= =?utf-8?B?aVU5K2o1dmU2ZmQzRE9sMDNQVCtlclpvcTVVME9jNUtLbW9CMkN2aGxGZWxK?= =?utf-8?B?ems3b2g4eGw5SU5KMUxQdTRxK25qako3MUwxYWZPSUJnWVJydHNna2lrNUgy?= =?utf-8?B?ejROcVB6amd2ZHRGOWZRREZIeDlySS96VHJNYXVZUmtRdTAyQW5ncGhNc1dK?= =?utf-8?Q?b3VLGdQlKCZVaaznhhQVvAABjFNT5KICl3annOe?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB5981C130C3B3D31227A3D857D42B9MN2PR05MB5981namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB5981.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b3c18141-6c9d-44e1-ff25-08d91adebdc3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 15:57:01.6967 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ojjxh/9EsXujc5PR7G8bLt0LTURPfPEZUOy56phutYOBKy++0VrXePDlIyY10AUApkYzUCf5FRgda0DXvv5tvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB5982
X-Proofpoint-GUID: gZcu2Mf1qLMFIA64DyvZxZGZOORoeyWC
X-Proofpoint-ORIG-GUID: gZcu2Mf1qLMFIA64DyvZxZGZOORoeyWC
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_07:2021-05-19, 2021-05-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 malwarescore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105190097
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ImmjY-UT9VKN13Wt9A1tmADJToc>
Subject: Re: [spring] =?utf-8?b?562U5aSNOiBDb21tZW50cyBvbiBkcmFmdC1nZW5nLXNw?= =?utf-8?q?ring-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: Wed, 19 May 2021 15:57:25 -0000

Hi Fan,

Please see zzh6> below. I will try to reply your latest new email asap.

From: Yangfan (IP Standard) <shirley.yangfan@huawei.com>
Sent: Thursday, May 13, 2021 9:21 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; 'Rishabh Parekh' <rishabhp@gmail.com>
Cc: 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>
Subject: 答复: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Hi Jeffrey,
Please see Fan4>> below.

发件人: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
发送时间: 2021年5月12日 2:37
收件人: Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>; 'Rishabh Parekh' <rishabhp@gmail.com<mailto:rishabhp@gmail.com>>
抄送: 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>>
主题: RE: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Hi Fan,

Sorry it took longer than expected, but I am continuing my email response that I started before your long weekend. If you had read that partial message that I sent accidentally, you can skip to where I my partial message ended last time.

Please see zzh5> below.

From: Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>
Sent: Thursday, April 29, 2021 11:16 PM
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<mailto:spring@ietf.org>
Subject: 答复: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Hi Jeffrey,
I add some explanations start with Fan3>>.
BTW, from 1st to 5th May, I will be on Labor Day holiday and may not be available to respond in time. ☺
Best regards,
Fan


发件人: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
发送时间: 2021年4月30日 3:06
收件人: Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>; Rishabh Parekh <rishabhp@gmail.com<mailto:rishabhp@gmail.com>>
抄送: 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<mailto:spring@ietf.org>
主题: RE: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

Hi Yangfan,

Let me pull up a few points to the top, and respond with zzh4>.


Zzh3> No. Just put the your merging segment after the replication segment. The only change to replication segment is that for the replication node, you may augment it with the semantics of adding FI/SN. No other changes at all.

Fan2>> Draft-ietf-spring-sr-replication-segment states“Notice that the segment on the leaf node is still referred to as a Replication segment for the purpose of generalization.” In other word, segment on merging node is always replication segment, no way to perform the merging behavior defined in merging segment.
Fan3>> I see your point. I will explain it by taking an example. Let’s say we have a path starts from A to D, A is redundancy node and D is elimination node. In between there are two paths A-B-D and A-C-D.
You were assuming Node B and C are the downstream nodes, followed by elimination node D.
I have different thought that D is the downstream node, B and C are not aware of any state or capability for redundancy protection, only A and D are aware of redundancy protection.
In your design, not only the redundancy node and elimination node are involved, the nodes preceding the elimination node on different paths should also be involved and further managed by controller. IMHO it is complicated.
Zzh5> That understanding is not correct.
Zzh5> The replication segment could have two branches, both to the same downstream node D. B/C are just transit nodes not aware of either replication or redundancy or merging.
Zzh5> Alternatively, the replication segment could have two branches to B and C respectively. The replication SID will have a following D node-SID and merging segment. In this case, B and C just have regular replication segment (as leaves) and not aware of merging.
Zzh5> Either way, the merging segment does not have topological semantics.

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.

Fan 4>>: I agree with the two options, right now both of them are workable. Let’s analyze it one by one.

1)      D is the downstream node.
According to replication segment draft “Notice that the segment on the leaf node is still referred to as a Replication segment for the purpose of generalization.” I understand this sentence indicates that D would be represented as Replication SID. In this case, the problem is that there will be no Merging SID. Which node will process Merging SID? How do you solve it?

Zzh6> Let me use R for replication and M for merging SIDs, A/B/C/D for node SIDs.
Zzh6> The SL includes <A,R,M>. R is installed on A and D. A gets the packet, pops A and sees R so it replicates. When D gets the packet, it sees R and pops the SID (since it is the leaf). Now M is exposed so merging happens.


2)      B and C are the downstream nodes
I assume the SL can include <A,B,D>, A is replication SID, B is replication SID as leaf, D is Merging SID, all the SID are service type of SID, not topology type. But on the replication SID of B, there is no routing/forwarding semantics for B to  forward the packet to D. How does B and C forward the packets to D?

Zzh6> The SL includes <A,R,D,M>. R is installed on A, B, and C. Because of R, A replicates packets to B/C who pops the R SID (since they’re leaves), exposing D. D is a node SID to get the packets to D, where merging happens.
Zzh6> When you say A is the redundancy SID, I am not sure it has the semantics of both “node A” and “redundancy”. In my representation above, I separated them, but of course the combination could be done for replication case as well.

For the questions in either case, I didn’t think them through. That’s why I am not convinced that replication segment can be used in redundancy protection.

Fan3>> Another pending issue here is at the downstream node B or C, the MPLS label or IPv6+SRH header is removed, how to concatenate with merging segment is not clear for me.
Zzh5> This is actually related to whether the ingress node or the replication node should add the FI/SN. I believe it should be the ingress node itself, but I will defer that to a separate email (it is coming).
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> Let me read that email thread and come back to this.

Zzh4> draft-geng has a merging segment defined:
   … two types of
   Segment including Redundancy Segment and Merging Segment are
   introduced.
Zzh4> The discussions in this email thread is only about using/augmenting the replication segment for the redundancy segment. It does not replace the merging segment. In the redundancy use case, there will be a merging segment after the replication segment, and it is the merging segment not the leaf node’s replication segment that does the merging.


Fan2>> IMHO SR P2MP policy and Tree-SID is totally unnecessary for redundancy protection.  SR P2MP policy is identified by tuple <Root, Tree-ID>. The two parameters are meaningless and inappropriate for redundancy protection service. There isn’t a tree or root at all.

Zzh4> In a network that provides redundancy protection, you will likely need multiple replication nodes (for traffic from different sources); on each replication node, you will likely need different replication behaviors (e.g., replicating to different downstream nodes because traffic could be going to different destinations).
Zzh4> You will also need to advertise those binding SIDs for the replication/redundancy segments, whether they are advertised by routing protocols or simply programmed from controllers, so that an upstream node can correctly put in a redundancy/replication SID. For that, you will either use a control plane identifier (e.g., <root-id, tree-id> in case of replication segment) or simply use the SID itself as the control plane identifier.
Zzh4> So far, separate control plane identifiers are normally used (e.g. prefix for a SID, endpoint addresses for a P2P policy, or <root-id, tree-id> for a p2mp policy). I assume something similar would be needed for redundancy segment if you insist not to reuse/augment the replication segment, but you can see that replication segment already provides all you need.
Fan3>> Yes, you are right, in control plane redundancy SID itself is the identifier. Similar to replication segment, Redundancy segment is also a Binding SID associated to a Redundancy Policy, which is identified through the tuple <redundancy node, redundancy ID, merging node>. Different from SR P2MP policy, SR policy key structure <headend, color, endpoint> and the semantics is not changed. The particular color value is used to identify the redundancy ID. No separate identifier is imported.
Zzh5> The point is that things similar to <root-id, tree-id> is needed (instead of unnecessary as you said earlier) – you’re calling them <headend, color, endpoint>. Just different representation of the same thing.

Fan4>> :
Agree, there must be an identifier to identify and direct the service flow, no matter it is a Redundancy SID or <root-id, tree-id>.

Zzh6> It’s important to distinguish between control plane and data plane. In data plane it is always a simple SID (replication or redundancy). In control plane (that sets up the replication/redundancy state on relevant nodes), it could be whatever.

I try to compare the two solutions redundancy protection and P2MP replication as follows, hope it can help the understandings.

Format: <solution> ,  <identifier of service> ,  <how it works>
<redundancy protection> , <Redundancy SID> ,  <service is identified by Red-SID, Red-SID triggers redundancy policy to assign candidate paths between redundancy node and merging node>
<P2MP replication> ,  <P2MP policy identifier (root-id, tree-id)> ,  <P2MP policy gives the tree structure of the P2MP service, replication segment is an atomic building block for packet replication and stays in root, bud and leaf>

Although each solution includes a SID and a SR-Policy, there are totally different mechanisms. I don’t think it is just a representation difference.

Zzh6> The above is actually not accurate description. I’ll have to defer it again 😊
Zzh6> I will not try to get away with keep deferring things. So far there 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 😊

Zzh4> Even if you simply use the SID itself as the control plane identifier, a p2mp tree (and its replication segments) can already be set up that way – please see https://tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller-06#section-3.3.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller-06*section-3.3.2__;Iw!!NEt6yMaO-gk!WHw9iR3vA7toDm76OT4tJGqF5AIyX1Cu7_-gh0DqmT8jdtChMi9QyFU_r7V3y7ZI$>I$>.
Fan3>> I admit R-SID itself can be building blocks for a replication use case, but the control plane is designed for multicast only. BGP MVPN family may not even be used if there is only redundancy protection required.
Zzh5> My points are the following:
Zzh5> 1. Your point about “IMHO SR P2MP policy and Tree-SID is totally unnecessary for redundancy protection.  SR P2MP policy is identified by tuple <Root, Tree-ID>. The two parameters are meaningless and inappropriate for redundancy protection service. There isn’t a tree or root at all” is not valid. Whatever you call it, you still need the similar things in the control plane to identify the replication node and distinguish different segments that go to different downstream nodes. No difference between replication segment and redundancy segment at all.

Fan4>>: from an architect point of view, you can regard redundancy protection topo as a tree with root and leaf. But from the service point of view, redundancy protection has no meaning of a tree. I don’t deny P2MP policy and Tree-SID/Replication SID can be the solution to provide replication part of redundancy protection. However, I just feel our solution would be more straightforward and easier to understand. Why don’t we use a simple one?

Zzh6> SR-P2MP can be as simple as a root with some leaves (traffic is tunneled from the root to leaves directly – referred to as Ingress Replication or IR), or more complicated with intermediate replication points. The simple IR case probably matches what you have in mind for redundancy solution. The redundancy protection could also be based on more than one branches and having intermediate replication points (pure replication no FI/SN or merging stuff). All these are satisfied by replication solution 😊
Zzh6> Thanks.
Zzh6> Jeffrey

Zzh5> 2. Even if you manage to only use a single SID in the control plane to identify, replication segment can also support that. The web link is an example that uses BGP signaling. The bgp-multicast-controller draft specifies a way to signal replication segments, which can be used for both true multicast and for redundancy protection purpose.

Fan4>>: Again, if only redundancy protection is needed between R node and M node, from the semantics point of view, it is weird to establish a BGP MVPN peer between R node and M node.
Thanks for the clarification and discussion.
Best,
Fan
Zzh5> Jeffrey

Zzh4> Talking about the signaling, we only need one sub-tlv added to existing replication segment signaling to indicate that FI/SN should be added.
Zzh4> Jeffrey

From: Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>
Sent: Thursday, April 29, 2021 6:31 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<mailto:spring@ietf.org>
Subject: 答复: [spring] 答复: Comments on draft-geng-spring-sr-redundancy-protection

[External Email. Be cautious of content]

Hi Jeffrey,
Please see inline reply starts with Fan2>>.
Regards,
Fan


-----邮件原件-----
发件人: spring [mailto:spring-bounces@ietf.org] 代表 Jeffrey (Zhaohui) Zhang
发送时间: 2021年3月26日 3:19
收件人: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; spring@ietf.org<mailto:spring@ietf.org>; Rishabh Parekh (riparekh) <riparekh@cisco.com<mailto:riparekh@cisco.com>>; Arvind Venkateswaran (arvvenka) <arvvenka@cisco.com<mailto:arvvenka@cisco.com>>
主题: [spring] Comments on draft-geng-spring-sr-redundancy-protection



Hi Xuesong, Mach, Fan,

Some comments/questions on the proposal.

1. We don't need an additional "redundancy segment" for the replication semantics. Existing "replication segment" (draft-ietf-spring-sr-replication-segment) can be used as is, especially for the scenario where the original header already carries (FI, SN) information.

------[FY1]: three considerations here:

a). For the scenario you mentioned, that is correct, redundancy segment and replication segment share a common behavior of "packet duplication". The significant difference between two segments is the behavior of adding FI and SN. Unfortunately, there is no application in SRv6 required to carry (FI,SN) information in IPv6 header, which results in a more common scenario is where the original packet doesn't carry (FI, SN). So the current design of redundancy segment is based on this scenario.

 Zzh> Since the presentation talked about scenario where the (FI, SN) information is already carried, it is fair to discuss that in my initial comments; I understand that you want to focus on the other scenario, and that’s fine – see later comments below.

Fan1>> Before we dive into the detailed design, I would like to come back to discuss the two scenarios first. Before the traffic is about to be replicated,  we name scenario 1 is the traffic has Flow Identification (FI) already:

In this case, FI could be carried either as IPv6 Flow Label in IPv6 basic header or in other EH TLVs. RFC6437 specifies the usage of Flow Label for stateless load distribution, and many existing implementations follow. Since redundancy protection and ECMP can be needed in the network at the same time,  flow label is not possible to act with two semantics unless RFC6437 is extended. In other word, at present flow label cannot be used to carry FI for redundancy protection.

To carry FI in IPv6 EH TLVs, currently there is no RFC specifies it or similar idea. It is just based on imagination. The only reason I can understand is that controller has already recognized this flow to perform redundancy protection somewhere, but the replication is not planned to happen at headend. So it assigns FI at the headend in SRv6 policy together with SID list.  The potential reason could be the headend does not have branches itself, SID list represents an E2E path for the service, but the multiple redundant paths only exist as a subnet of the entire service path, or bandwidth saving in network. If it is the case, it just means two choices to assign FI, either at headend or redundancy node. Under this circumstance, we should discuss which place is better to mark FI into packet. In the draft, we insist on adding FI at redundancy node, as FI is not necessarily to be globally managed. So it comes back to the second scenario- there is no FI in packet. All in all, there is only one scenario, where FI is to be encapsulated at the redundancy node, not before.

I didn’t put SN here, because actually FI and SN are different. It is reasonable to assign FI from controller, as FI is flow-based parameter. But SN should be encapsulated on the endpoint itself as it is a packet-based parameter. Based on this, I am afraid no one will choose to assign FI at headend, then separately add SN and replicate packet at the redundancy node.

Thus, for redundancy protection, both (FI,SN) adding and packet replication should be included in the endpoint behavior of redundancy segment.

Zzh3> In the above long paragraphs you explain why you think it is better to add FI/SN at the replication node. Even in the case where the (FI,SN) is added at the replication node, using replication segment augmented with semantics of adding (FI,SN) still works well.

Fan2>> No problem. It is important to understand the actual scenario, so that redundancy protection can be properly designed based on correct assumptions .

Zzh3> As for whether it is desired to add FI/SN at the headend, I would say there are certainly good reasons to do so, but I will defer that to a separate discussion.

Fan2>> Sure, expect to start this topic.

Fan>> I read the draft of replication segment, and have two questions if replication segment is used in redundancy protection.

1) I believe merging node should be as the downstream node, since the nodes in precedence of merging node should not be redundancy protection aware. In this case, there will be at least two identical downstream nodes. In replication segment, there is no definition of such a situation.

Zzh2> That is not explicitly excluded, and that does not mean it can’t be used.

Fan2>> Yes, it will import more parameters to replication SID, although replication SID has already had a complex logical structure.

2) The draft states replication SID MUST only appear as the ultimate SID in a SID list. What if the merging node is not the last node of the SRv6 E2E path?

 Zzh2> There is a requirement that there must be no “topological” SID. The intention is to prevent the situation where a node side comes after the replication SID, causing duplicate packets to that node. That is reasonable for the original intention of replication segment, but now it is reasonable to remove that because of this new use case of replication segment where we do want the replicated packets to the same merging node. We’d rather remove the restriction instead of defining a new segment.



Fan1>> if this restriction is removed, as draft-ietf-spring-sr-replication-segment states, the behavior at Downstream node of a replication segment is undefined. What is the solution here?

Zzh3> As I said already, the reason for that document to state so is because the topological segment would get duplicated packets. We did not think that makes sense in a regular replication situation, but obviously the redundancy use case is perfectly fine, so we will remove that text or modify accordingly to point out where it makes sense.



Fan2>> I understand there is actually a forwarding blackhole on merging node if it is not the last hop of SR path. Because in term of replication segment, merging node is the downstream node, and downstream node is also represented  as replication segment. For simplicity, merging node is assumed as leaf node. According to End.Replicate definition, MPLS label or IPv6+SRH header is removed at this time. There is no definition on how to forward the inner packet to next hop.

Unless End.Replicate is changed, simply removing the restriction of“MUST only appear as the ultimate SID in a SID-List”doesn’t work.



Moreover, as we discussed, if replication segment is used as redundancy segment,  the downstream node is actually the merging node. Merging node has its own endpoint behavior. I understand in replication segment definition, leaf node performs the endpoint behavior of replication segment.  Are you going to define another branch of merging segment endpoint behavior inside the replication segment?



Zzh3> No. Just put the your merging segment after the replication segment. The only change to replication segment is that for the replication node, you may augment it with the semantics of adding FI/SN. No other changes at all.

Fan2>> Draft-ietf-spring-sr-replication-segment states“Notice that the segment on the leaf node is still referred to as a Replication segment for the purpose of generalization.” In other word, segment on merging node is always replication segment, no way to perform the merging behavior defined in merging segment.

b). Even though IPv6 flow label could be encapsulated in header, it is used for ECMP or fragmentation, redundancy protection cannot simply reuse it since flow ID allocation has dependency on the merging node capability.

Zzh> IPv6 flow label is irrelevant here – it’s not discussed in either your draft/presentation or in my comments – so we can ignore this.

Fan>> I mentioned IPv6 flow label coz we had this discussion in DetNet WG. I agree we can come back to this thread when it is needed.

c). In protocol design, it is important to maximally reuse the existing implementation. However, instantiation of a segment is a different story. In RFC8986, there are 14 End behaviors and 4 headend behaviors defined. We understand the principle here is to keep the semantics of a segment and further functions definition neat to make the segment routing forwarding clear and efficient. To enhance the replication segment to support redundancy segment seems quite an opposite methodology.

 Zzh> RFC 8986 does specify additional flavors of End and End.X function with USP, PSP and USD behaviors which are modifications to base End and End.X function; exactly what we are proposing here – enhancing Replication Segment to add (FI,SN) when required.

Fan1>>If every function can be enhanced to one segment, it is really not necessary to define 15 End behaviors in RFC8986. One complex End behavior can do everything.

Fan>> can you explain more? I don’t see correlation between flavors and adding (FI,SN).

 2. Even for the scenario where the (FI, SN) information needs to be added by the redundancy node, the existing "replication segment" can be enhanced to add the (FI, SN) information.

-----[FY2]: Replication segment provides P2MP replication with target of supporting multicast service, and redundancy segment aims to provide redundant flow protection to URLLC services. Adding (FI, SN) doesn’t bring value to multicast services, and having the stitching capability of replication on redundancy node seems a waste and unpractical to URLLC service. Twisting them together in one segment results in a complicated function, where maybe only one type of service is required on the node.

 Zzh> Adding (FI, SN) information is only to replication segments that are used for replication for unicast redundancy purpose. It does not mean all replication segments will be added with (FI, SN) semantics.

 Fan>> How would you write the Boolean switch to differentiate the purpose of multicast replication and redundancy protection in one segment? And currently we don’t exclude the redundancy protection for multicast traffic.

Zzh2> There are two ways to do it.

Zzh2> 1. A replication segment now carries an additional attribute about adding FI/SN information. That does mean the redundancy node cannot use the same replication segment for both regular replication (w/o adding FI/SN information) and redundancy replication purposes. However, that does not mean we should not extend the existing replication segment for redundancy purpose. Also note an interesting use of replication segments here – say the redundancy node is N1 (who adds the FI/SN information) but the actual replication node could be N2. The replication tree does start at N1 but only one copy is sent to N2, who does the real replication. Now N1 will have two replication segments – one for regular multicast purpose and one for redundancy, but they will share the same replication segments downstream (because only the redundancy node adds the FI/SN information).

Fan1>> in fact, I think you raise a very good example to explain why we should not put replication segment and redundancy segment together as one segment. It makes the service deployment so complicated and confused.

Replication SID and Tree SID is defined for the P2MP scenarios. Why there are two SIDs defined because multicast services have root, bud, and leaf roles. However in redundancy protection, redundancy node has very straightforward and unique semantics. The endpoint behavior can be defined simple and clean. Why would I abandon a new segment with clear endpoint behavior but choose to become a branch of another segment’s behaviors? The reason not to introduce another segment is not very sound. Because anyway, you need to differentiate the purposes of original replication and redundancy protection separately in replication segment. I don’t understand what exactly resources we are saving.

Zzh3> A replication segment is a simple building block that replicates packets to a bunch of downstream nodes (and each replication branch can have a segment list to specify the path). A replication tree made of concatenated replication segments provide P2MP service from a root to many leaves, potentially via intermediate nodes.

Zzh3> As such, a single replication segment can be used for redundancy purpose – w/o any changes at all if the replication node does not need to add (FI,SN), and w/ a simple augmentation (a Boolean indication) to add (FI,SN) if the replication nodes needs to add (FI,SN).



Fan2>> Agree. This part of modification is fine. The key problem is described above.



Zzh3> What I describe in the above zzh2> is another example of using an replication tree when you don’t want to put all the burden on a single node.



Fan2>> This example gives a hint that operator should pay more attention on service deployment when both multicast and redundancy protection services exist in network.



Zzh3> As you can see, the replication segment (w/ the (FI,SN) augmentation when needed) and SR-P2MP (aka tree-sid) provides all the redundancy needs.

Fan2>> IMHO SR P2MP policy and Tree-SID is totally unnecessary for redundancy protection.

SR P2MP policy is identified by tuple <Root, Tree-ID>. The two parameters are meaningless and inappropriate for redundancy protection service. There isn’t a tree or root at all.

In our draft, redundancy segment performs the packet replication and adds (FI,SN), redundancy policy provides multiple simultaneous paths. The mechanism is much simpler than SR-P2MP policy/Tree-SID.

We don’t want to put unnecessary burden on redundancy protection implementation.



Zzh2> 2. We can separate out the semantics of adding FI/SN. This is easy to do with SRv6 – just use the argument bits to indicate that. For MPLS, a separate label may be used before the regular replication SID – that label will add the FI/SN information and the following replication SID will do the replication.

Fan1>> Adding FI is flow based, I don’t think it is a good idea to use segment based argument to indicate it.

Zzh3> I don’t understand the logic here. If and only if the packets of a flow include a replication segment w/ the (FI,SN) indication, then you get the desired result.



Zzh2> Not excluding redundancy protection for multicast traffic is actually a good reason to use replication segment 😊 You can see that a replication segment, either with “adding FI/SN” semantics embedded or explicitly indicated by a preceding “add FI/SN” label or by a trailing “add FI/SN” SRv6 arg bits, can be used for both multicast and unicast traffic. In case of multicast, as long as two or more branches eventually converge to the merge node, redundancy protection is achieved.

Zzh> I don’t follow your argument about “seems a waste and unpractical to URLLC service”.

 Zzh> I don’t follow your argument about “Twisting them together in one segment results in a complicated function where maybe only one type of service is required on the node” either. If you only need regular multicast service, the replication segment does not need the semantics to add (FI, SN) information. If you need redundancy protection then the replication segment does have the semantics to add (FI, SN) information). If you need both, then some will have that semantics and some will not; and if you have a scenario where you don’t need to add (FI, SN) information for redundancy protection then the existing replication segment w/o the additional semantics to add (FI, SN) information can be used for both. All can be achieved with a simple Boolean switch added to the replication segment.

Fan>> after seeing all these “if, then” shown above, I even feel more strongly to support separating two segments. ☺ In RFC8986, there is no single Endpoint behavior having such “if, then” structure to specify different functions.

 Zzh> Note that Replication Segment is not tied to multicast either (the draft only mentioned multicast once as one use case):

   We define a new type of segment for Segment Routing [RFC8402<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8402__;!!NEt6yMaO-gk!Xgth91A6kCK6jXojQgQDaqWbfJ99HWzdkEjEJg3Wt5JxGsQ9uLf_E9w2WwrIuotL$>]$>], called

   Replication segment, which allows a node (henceforth called as

   Replication Node) to replicate packets to a set of other nodes

   (called Downstream Nodes) in a Segment Routing Domain. Replication

   segments provide building blocks for Point-to-Multipoint Service

   delivery …



Zzh> It is about replicating packets to a set of other nodes – quite applicable here as a building block.

Fan>> I do think replication segment has a very elegant design, however identical downstream nodes, design of P2MP SR policy (indirectly involves Tree-ID) may seem burden too much on redundancy segment. But it is still very welcome to have further discussion on replication segment and redundancy segment.

Zzh2> Please see comments earlier 😊

Zzh2> Also tree-id is not a concern. Tree-ID is only needed when multiple replication segments need to be signaled to different tree nodes. A simple redundancy case is like ingress replication and only a single replication segment is needed so tree-id is just an internal thing on the redundancy node. Regardless, the key is that the existing redundancy segment concept can be used for redundancy purpose.

Fan1>> Tree SID and Tree-ID are useless for redundancy protection, what semantics it should be for redundancy protection?

Zzh3> The above has no base. Please see my earlier zzh3> comments.

Zzh3> Jeffrey



3. I wonder why (FI, SN) information is added as a TLV in the SRH. Would it be better to use DOH?

-----[FY3]: If the (FI,SN) is encapsulated in type of TLV, both SRH and DOH are feasible. Actually (FI,SN) information is only meaningful to merging node, putting them in the arg part of replication segment doesn't help.



Zzh> While I do think it is better to put the actual (FI, SN) information in the DOH, I did not talk about adding (FI, SN) information to the arg part of an SRv6 SID. I was saying that the argument of an SRv6 replication SID can serve as that Boolean switch to indicate if (FI, SN) information needs to be added.

Fan>> so far, this approach works for me.

Zzh2> It can work, but since only the merging node use the FI/SN information, it is more of a DOH thing instead of SRH thing.

Zzh2> Thanks!

Zzh2> Jeffrey

For #1, and #2, reusing/enhancing existing replication segment has the following benefits:



a. Reduce protocol/implementation work

b. Reduce the amount of state in the network (the same P2MP tunnel can be used for both multicast traffic and unicast redundancy)



b) can be achieved even with #2 (redundancy node needs to add (FI, SN) information): for SRv6, the semantics of adding (FI, SN) can be indicated by the arg part of the replication SID and for SR-MPLS it can be indicated by an additional label in front of the replication sid label. If using an addition label is a concern, then indeed a single label can be used to indicate both "add FI/SN information" and "replicate", but still the replication semantics can still be set up using the replication segment infrastructure.



For SR-MPLS, where would you put the (FI, SN) information? Seems that GDFH (draft-zzhang-intarea-generic-delivery-functions) is a good option and that can be used for SRv6 as well (anything in DOH that is actually independent of IP could be extracted out to GDFH).

-----[FY4]: For SR-MPLS, currently the authors plan to keep consistent with specification in RFC8964. The original intention of this draft is to provide a PREOF solution in SR data plane to DetNet. What's why the draft is discussed first in DetNet then comes to SPRING. And FYI, DetNet MPLS data plane uses a separate service label (S-Label) and PW MPLS Control Word [RFC4385] to carry FI and SN.



Zzh> I forgot that DETnet mpls data plane already reuses PW CW for SN information. That’s fine and no need to introduce GDFH for MPLS.

Zzh> Thanks.

Fan>> thanks for bring up this topic to a deeper discussion. Redundancy protection should be taken into consideration for both SP and vendor if URLLC services should be guaranteed.



Zzh> Jeffrey



Thanks.



Jeffrey



Juniper Business Use Only

_______________________________________________

spring mailing list

spring@ietf.org<mailto:spring@ietf.org>

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Rk0PGf0pg0nFb0yo3yrw4HCuRzBBn_xDVWjwUQ9HKkn1db_vI48SfuShKITTo6uG$>


Juniper Business Use Only
_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Xgth91A6kCK6jXojQgQDaqWbfJ99HWzdkEjEJg3Wt5JxGsQ9uLf_E9w2W16NLBQX$>


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only