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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 29 March 2021 21:06 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 B0B203A21AE for <spring@ietfa.amsl.com>; Mon, 29 Mar 2021 14:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_BLOCKED=0.001, 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=RDcrbXbI; dkim=pass (1024-bit key) header.d=juniper.net header.b=ac5/sNRI
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 i3quoGmEgq1T for <spring@ietfa.amsl.com>; Mon, 29 Mar 2021 14:06:22 -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 EF8D23A21AC for <spring@ietf.org>; Mon, 29 Mar 2021 14:06:21 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12TL48nb003431; Mon, 29 Mar 2021 14:06:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=DiacWBw8TkooBcW2lpHQ9HFtrDSi3Q3xeT9b5TBwoUs=; b=RDcrbXbINKQsVPm6Hi75VaApj+BPjYRCTTcRhh9MLxlC69eY7UqLGM8kUfN7DWzRR9/4 ZjObJ6JsiiI8Sby71NPRDSdb5O4JvDOt5O6yWxWkQjyowprqvGeMmZ6KFnhqHkMj7QlW n7Q2TMBaJ9fTvYLVHugT/060TKGOtCPrOg6aUKwighjz8yaO9GDm6DdCsVDnnYNVapJo jpwek2v1ktuf4AYnu135skK+cSd/SFx0pkmWuKKJYPXHgPw9qKbRmFq5XcfubS7IW9GL x0DoRC6pme55oVocHkWxpO1tLGKe8eeFZ5Dvdf5tZKs2JDRua7VCFmrMM4lKgsYaYY3d SA==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by mx0b-00273201.pphosted.com with ESMTP id 37k7p79sd5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Mar 2021 14:06:12 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=md2AxqnQsYnujYs2blJ9CuZuQgELrnqu4pQRago98V2Vv9Kf4ey7jgrpa8NOVGl1scgm9/Xe+zGUYFY4MAXf1cW1keX+JJXogDIY1Yi3Xznvqy/pI1ESlbeqShId1CDZPq10yg0a8K7ePo0zBeEm7gkVQRtdCjjYa33TpSHsrnFi/y3RMOGnXQMx0vzNM4r5DuW85A8A4a8l09ZY6FigFOxyrKwwOti53L8l6LekXnMYmtPHwedKXX+dCfO81lsi4kJOSsGXrvSc6+D/FPYSfhJJ1TW9E2ItjIlwFhuyClGbUBPatHA8smOOBt4zj7KQAxDc2I0uA7eLf2qVKUg4Dg==
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=DiacWBw8TkooBcW2lpHQ9HFtrDSi3Q3xeT9b5TBwoUs=; b=GqUN6Ct1jnAgkKBjVRj1PUkfmUmNsjvheil+CE7YIzOml/Xsutn6B+NvbVubKc0sCSSpS4iy2b6htX3tBDwnLbG76ghfoEGqddzEJFBUOLx+8OMSF3m0VCghCFKz8uHDmB6LTEsScXFBRFwmpl0JiKaxaHErLyPoWqKSB3AO3Jpgs72qG4ydQCW2IOKw2G8tNfJgWO9iMjAn9n8zzPGNmGx00hvO4gPP9Z4W+0DHZOTDeS/NaDplkpZNl40v+G12qxsZSH06acVE1QvNCa8SUBdq1hRakOIQF5OyjuYakcodKvxT1UN1cieDaprjs4UqWeAjip2S2U/QhUvEOycPMA==
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=DiacWBw8TkooBcW2lpHQ9HFtrDSi3Q3xeT9b5TBwoUs=; b=ac5/sNRI5ZiNnRbWnZUk5OGZX0yo5iGxTWPQyFcxv7pCPPpZArTjsnzsWkGdgyMxfU0+rhmHX90h4m2P02EPFukWJ3kr7GmX3UhvagYqsnwzkDIKWx4YiURcaaMrTiQZ7z+9EQ4GGemQUo7uTmIYiuo0fPPmDnnYWlka3IR3xho=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by BLAPR05MB7427.namprd05.prod.outlook.com (2603:10b6:208:291::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.15; Mon, 29 Mar 2021 21:06:08 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::203e:7f1f:be91:161c]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::203e:7f1f:be91:161c%6]) with mapi id 15.20.3999.016; Mon, 29 Mar 2021 21:06:08 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Yangfan (IP Standard" <shirley.yangfan@huawei.com>, "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: Comments on draft-geng-spring-sr-redundancy-protection
Thread-Index: AdchqNboBkzcTc+pQz2/1sLPSorrgABEdhUgAIVha+AAAImLwA==
Date: Mon, 29 Mar 2021 21:06:08 +0000
Message-ID: <MN2PR05MB5981AA3B0A5E0D6DDB60F46FD47E9@MN2PR05MB5981.namprd05.prod.outlook.com>
References: <MN2PR05MB59812099F115C3FF43CA9077D4629@MN2PR05MB5981.namprd05.prod.outlook.com> <59384be985ae4d3bb9563bed2642bff1@huawei.com> <BYAPR11MB300030B313D45266695FA702DE7E9@BYAPR11MB3000.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB300030B313D45266695FA702DE7E9@BYAPR11MB3000.namprd11.prod.outlook.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.0.76
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=6c1ab6a8-a0c6-4244-9386-96bbf21a6e03; 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-03-29T19:33:12Z; 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-ht: Tenant
x-ms-office365-filtering-correlation-id: 71eaace4-9a07-4817-1846-08d8f2f67951
x-ms-traffictypediagnostic: BLAPR05MB7427:
x-microsoft-antispam-prvs: <BLAPR05MB742789F9B21E847425D78C33D47E9@BLAPR05MB7427.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: 4AFRXeQBqyZBlHQewyS8mrfYxDW32mI9xzW5sHyqj/OWWuEFgO0Msto+K9J2Cs5GsNoKDTdHaLejGNFJ3sfv046KUxItE5AryZu+H2UPkEJDK4z1G6xuh4AxObE89Qgk3tepR2t4+ndZhvB4mTRNj/ciFLJJyEOcBuTIiqDntQW8PiPCAl8IMFPMp7mHGrqGW+81UYCct4A/4y8ngVgwDger8/HSC/tCR9D8M9I4etrQZjKnbWZIV5WZaZzblsBqLL5fvoU9ZcAxgmSJo536kAxFEmqeUSqW8Ai1sPa2dn1ysZ6paGRfuY2DO/esMaysgMW8lJ3fSJm87nA64Z7zpVEMMTsALqNb9dDhhEGkzbP1TlCmNF1BT5/NlxTatLreifg6tfX+dB7TzXxsGmPwtmsj4RrBN72tuxFm4IAvaKZiz1t89lb0MEkKEN4Ps87btx7S4Nx11udQ/PHelNQhLUIuA+VQOxTeXjHY/5ROgRZ92euGpkLcS+bxEgqhBaiFUcjNyfui5b4u5g0Oh1mrN/ZyIWno4u/+LGcua+yXa5i3onVDu2xLFljVL+gqvPnXt0EIUdBXxxHcXM5ZvRQKhiXgs3X4Dg35f4gGhA9akR/dhabEjw1lmzFb7q/i2XvD/P/mY8I95a/47n3YxoXAaBAapw11vKPhMLFeooNc6m5TRlQIvuawrjvQ7zWioW2YGoLAqTT/YUbZG+aeAgBqgWYMa3EkWUtx2CYMggM+n3M=
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)(346002)(376002)(39860400002)(396003)(366004)(136003)(8676002)(166002)(26005)(53546011)(83380400001)(66946007)(76116006)(2906002)(66556008)(966005)(33656002)(66446008)(38100700001)(9686003)(8936002)(186003)(5660300002)(9326002)(110136005)(86362001)(71200400001)(52536014)(64756008)(6506007)(66476007)(55016002)(316002)(478600001)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?cDNZc1kvRFpMb0xac3JBbmNnZlJXcTFEc3Ezb1hCQjNPOXErRXVVZW9tSk44?= =?utf-8?B?WHpzcWIrNXd5RWVvb2VZOStwMDE2ZEhuMFZhMDJ5a1p5YjBsTXQzR00ybHAz?= =?utf-8?B?aTVxU3JHRkV4Y1poV0xjRG4zWS9kOEU3WnZHQWMwYTRZYjByVzE3aGVvK2k3?= =?utf-8?B?eXp3ZFlLMUZySGkwcGtaMlJvWHFEMCtpSUp2VXMvaFVVdkNkTGhGRXp0ZHQv?= =?utf-8?B?SkxOYVM1NVdEWVg1eG9aY20yM1RPOW5nVHpVUVdsNzNJWjVpN1A5RDlTcDdr?= =?utf-8?B?Yk1ycEd3emFqY2V4NGtkQ2FaMWlBcERtd2JoekxsbFJucHprdFR6ZnFsbmpj?= =?utf-8?B?aUk4TWFia09YU2xFdnV2L2V0amgzNXdMUGlJRi92a3MrM0NLaVNicTRWNTA5?= =?utf-8?B?cExaaFFyaTRLb0laTE00Q3VRbWFldjAwb05YeVcxdmRENEViVjhUa0RJUUV3?= =?utf-8?B?NFI0RmFtdjZ5RkNvMmgxeGMrVjB4Nk5VTkNQeWZYWVR0c08yTjd1MWJKTmxZ?= =?utf-8?B?WUxLWEdBWUk3UFJyTDFQc3E0OTdlNHFiL0RyV0ZLUzc4cmlsKy9VdzVncUdv?= =?utf-8?B?YWZRR25vU0ZCYmJwRFVkbWVwRVdzRURLNmttR1JMNS9aNHU2N25neXIwdWox?= =?utf-8?B?MG9OSmhHWXlsa2Z4Tm1Cb2R6RUZQaWRaVGhBY2ptaWt1R29RUUpVWEVNdmt5?= =?utf-8?B?TUQwTVgzbHU2bklSV09tRk4za2VVVTdZczdkb0twM3hPSE9VNUFrTHFOVllJ?= =?utf-8?B?MU9XQjlHT01vZWtXaXY0NHRKalVDYzEzeEhWOUtOZTFRak9oSVAvWDV5Y2ds?= =?utf-8?B?aVd1TlZ3aUh4SUxrWVNNdnlCQldGRE9pOXRnaU5aWXBtc2dvTXdQUEVCcUFQ?= =?utf-8?B?QTdYWGY0VVQySUFSZDYyNVB0aEQyRlJJenZPRXVxWGQxcTRlRzBsYkg0M0JW?= =?utf-8?B?ZmM4VzlsYjI4eTByc2hoaks1TGZscFhtVFZRdW15bStBMk9ZYnBWdlhLSnVF?= =?utf-8?B?Nm5FYWt4RkpZaFZLZWRUWEVlNHcxMWFmRmptME5KMTZFc0U4R3RmUytWd25C?= =?utf-8?B?cTM3SG9nU0RESmp6MlhWaU1lWlorRmgxTldPSnRNV3RPU0JHMkN6QytoYzBK?= =?utf-8?B?bGMyNDRxbGxNZ2huajVzdmErcmNxdUdXek1HNEl4emlKQ1FQTHpmSG9KL0Jh?= =?utf-8?B?ZXRVd0pwd0EwQjlCRWROM3oyeStzTUtOM0lRM3hFcmxWOG9WNUFmR1NFWVZC?= =?utf-8?B?TjgvanRmY1lPK0MrV1E1V0VTM3ZYVXFSYjQ4ZzE3U0p5Z1laYjlNZENpVElX?= =?utf-8?B?ak5LOVYxTlVXQ2JLVEY3QUJTV3FJcldiQnM2VTBjT2hUK0R1ZkJQWHluM1dy?= =?utf-8?B?bDBWUzM4akpoYWNaeDhzZFdUdVpYOEhKOUYrekw2ZDZWdXMrRXNsaTZnRTVx?= =?utf-8?B?QzNFZXJJblUrM2ppUHU5bk1tTFY2ZXVxYzcreC9SaU9MbzZwVnR4ZWVFUU5O?= =?utf-8?B?T2NKbFp5UW1rb0hiQXFnWlYvUDlYNEd2WlNjWXZ0MVdjcVBOU2lVZDRydndM?= =?utf-8?B?UjRnT2I3amdaM1BCaGVPZ3Z5UVk0RTNJclRUd1V2MzBUbG9VQTJUUi9NcUwv?= =?utf-8?B?a3pkRVFRa2xzQmlHU1YyaEpqSHd5U2RFRVlOeER3SHpVdXJBbEJpTHJQVmJ4?= =?utf-8?B?OXBjaHZrMXllOGJVKzl6MG1wd1Y4TjBoWDFLTHFrWFRyTTlDUEpqWkJVRnQ0?= =?utf-8?Q?Vzgh3SbFQA/tkohnBtTeU/ejyQoGAhBAXv2Ewg6?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB5981AA3B0A5E0D6DDB60F46FD47E9MN2PR05MB5981namp_"
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: 71eaace4-9a07-4817-1846-08d8f2f67951
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2021 21:06:08.1431 (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: 3zlJs2A5C3zXXZeaar36chGufY03f4/QkxYlEUgGv6J39b9mnP8qK0Skapdq3IqdkfWal5t7K0oSZfRFdYSiSw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7427
X-Proofpoint-GUID: mgqMZyTj6sWe4PSHfsJKnkc4AIxRsD_d
X-Proofpoint-ORIG-GUID: mgqMZyTj6sWe4PSHfsJKnkc4AIxRsD_d
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-29_12:2021-03-26, 2021-03-29 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 clxscore=1015 lowpriorityscore=0 malwarescore=0 spamscore=0 adultscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103250000 definitions=main-2103290156
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/RRR610la_6xBSkj4z4qfJ7jrUxw>
Subject: Re: [spring] Comments on draft-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: Mon, 29 Mar 2021 21:06:27 -0000

Hi Fan,

Please see zzh> below.

From: Yangfan (IP Standard) <shirley.yangfan@huawei.com<mailto:shirley.yangfan@huawei.com>>
Sent: Friday, March 26, 2021 11:58 PM
To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; 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>>
Subject: 答复: Comments on draft-geng-spring-sr-redundancy-protection


Hi Jeffrey,



Thank you for the comments, please see the reply inline starts with [FY#].



Cheers,

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.



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.



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.



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.



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.



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://tools.ietf.org/html/rfc8402>]2>], 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.





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.



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.

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