Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Tarek Saad <tsaad@juniper.net> Thu, 11 March 2021 17:17 UTC

Return-Path: <tsaad@juniper.net>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F83A14DC; Thu, 11 Mar 2021 09:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.245
X-Spam-Level:
X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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, 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=IPoutNML; dkim=pass (1024-bit key) header.d=juniper.net header.b=VMJIiSCq
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 gAtxBASMO9D9; Thu, 11 Mar 2021 09:17:42 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 6EE963A14CF; Thu, 11 Mar 2021 09:17:42 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12BH9t7x023031; Thu, 11 Mar 2021 09:17:41 -0800
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=1AAYcyn+EYPiktZwp29IKr7n2T5c0m+/C32z1WLRyys=; b=IPoutNMLJ5yexgZNKW+aWp1IYaA602kH9Q19dtKW8rLui8tvmFo567/xnyMaNNsziqnv cl7JvFVDgBb7N9OeNu2+7+CpojbbpSw/kF9cT1eCmingV/PWvtR0uI9hFXe1yPRwDpFp eDSN+1PnlbDZATln3gv1KTNpp4Dmt8v7JZoANCwuf7SrGH7XQwgbn6GNrevS2d6rjJ3z V211kDYJq93dYJRB2Xui09JGXEy+S7meNqyX6O0Ht0LtHRNHIbQ3WUBE0J6p45nEdkKu hPSOSEXgNL9dXuOziG1HcB4Sv2sAkzXYqMuFytc8GFAPWAvQsEYkeaSC6jIsI65LvC2c NQ==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2054.outbound.protection.outlook.com [104.47.37.54]) by mx0a-00273201.pphosted.com with ESMTP id 376g2h4c33-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Mar 2021 09:17:40 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=odWaJnDgVXltQdfEV8s6bIPNFIBBpPs55pBGi4nnhVirMRvfU8z/wlCePCo3WZgvUux28P0zk33Tx6hn9gfKYoUbtfSum8fjqvZNimIy0ZdL6LWu/+ycW6S8aDqBcND0jr5lXdCyYKzX0gjTYEZXVLWlQaCGoBezUPEn3ie3lOW09XjSkNpHNbSC+0FxapVLqXYSpR1UJIS9GD5G+JMkW9iv09C5QGxc2wMV5mpqRd6QLtjRtRTLzbinT8RjzelzK7UMMQCaWQO7kC3Md6rGUaepblUivHp6bvargs5lTwHPX78EqcNT9bOEJ6nmvzd+x1VM8XCmTkZt3g10GFcv7g==
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=1AAYcyn+EYPiktZwp29IKr7n2T5c0m+/C32z1WLRyys=; b=PPXHoMfeCBnPiwyTLFVI3/Ps0IP7JCz9v+lXjmBgkHzNICoMOnnc7xwRDUfbhpR1Ikg/evEJ9NtyPBVdKSNqDxdIogjJkIvmCcud6wNFqkXD9l/OKuZTE0UV9RCX0SbAr7NBLtCqXUzwOW+NsQuuWx04P15LsSXbUx26rXawBHMVJDRgJziPJaHPWJ5W8e5itCQW6UZ9OhPZ+5Z9wsYpAl1v3U+D8cMd5/AP4f1OiS7uSdbJDEDLP8AGkm83yurEbNS/wuGszsYKrJPpXmtLRccsGdm3j+o4py0JuNyoak4pevdhwrG8LLjIQqbrGCMDaBe+FgbD82N8A90UchtCjw==
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=1AAYcyn+EYPiktZwp29IKr7n2T5c0m+/C32z1WLRyys=; b=VMJIiSCqVQk04OWTx4J253pvvrWojWns9QTtP36KFnNt63QeWw/sdeSLzdhHAXM/Ah+ymdWiSJvMC8k7aTx1E3qtUUC4HO6GF+GuxEs8mflHYOik6HZUb815mKZp+B51Ov00yubFUz+omI0KsHS6awGGqLcx2dDAy/OnWEZjouQ=
Received: from BYAPR05MB4136.namprd05.prod.outlook.com (2603:10b6:a02:85::18) by BY5PR05MB6833.namprd05.prod.outlook.com (2603:10b6:a03:1f7::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.11; Thu, 11 Mar 2021 17:17:30 +0000
Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::a5df:f171:3457:b8bc]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::a5df:f171:3457:b8bc%3]) with mapi id 15.20.3933.031; Thu, 11 Mar 2021 17:17:30 +0000
From: Tarek Saad <tsaad@juniper.net>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>
CC: "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Thread-Topic: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
Thread-Index: AQHXEHfecMxtL6iamESmL3FT0KMM8qp0yQeAgADgb4CABusLAP//1JaA
Date: Thu, 11 Mar 2021 17:17:30 +0000
Message-ID: <12135E00-1E51-474D-89C2-84BD089562DF@juniper.net>
References: <DM6PR08MB3978834687ACFA7C599AF90C91A10@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5YUG2HhDqwCXbhAzO27P18GEL6Rdr6nkYBvW9yzCHLHjQ@mail.gmail.com> <DM6PR08MB3978524B94C0FB4D21B6A1CF918E9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5buVgy=HhT-+ZnhYZcE1AYRmOxK9-Md=4FJxqu7BLK3Zg@mail.gmail.com> <DM6PR08MB39780572111C11CDF6EFC7D4918B9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5YjxiMTnUT7zVHYDeYqxvQR8ESQf7ydngPYObVPHLU8uA@mail.gmail.com> <DM6PR08MB397847235D7ADDF7C4B7D028919B9@DM6PR08MB3978.namprd08.prod.outlook.com> <35FBCBF8-0EF2-4404-8AA8-C39C4F929249@juniper.net> <CAB75xn5QTTEKOLm_tvEteEWx0x2S4qWufFY_6P-CU8CXFaBF2g@mail.gmail.com> <252B18FD-D296-4E1C-AF75-1293511B3E4A@nokia.com> <CAB75xn7AnjtY9O6C07i9P3M=2rSGCo+UqQKnSaJajQsXPiTg=A@mail.gmail.com>
In-Reply-To: <CAB75xn7AnjtY9O6C07i9P3M=2rSGCo+UqQKnSaJajQsXPiTg=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=8e006d10-4474-4305-a600-c5ed293806e1; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-03-10T05:10:28Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
user-agent: Microsoft-MacOutlook/16.46.21021202
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [2607:fea8:e31f:e400:a468:cbd3:77d6:6593]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e6e5c46b-9ae4-48e8-2a92-08d8e4b18d4a
x-ms-traffictypediagnostic: BY5PR05MB6833:
x-microsoft-antispam-prvs: <BY5PR05MB683319FE8B0BB420FB8E59C5B7909@BY5PR05MB6833.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: dBEVCbFy9o7/N2elx56eordQpGUgc8uxnJbGRJtImOaoWdRKv99stYyA154mhOo5CCtjSmIreuYlmskjKb+z/+tTDxF0SetiO3FzYFL84gbCl10DzxorhQ3JmZbJH7AyfLZHl5kGCNrbY5r6Rivj0z+xQ9y3xDaA/f5Ptc5pwDHb3Ch6AEruzfiseY7FFlg1FuStIt3NbXmAI3CGGzN7E3I4SIFLUAdvugyT32sqmh2VNs5CcCPh1Sjr6B7UkZNZ+kHMaMs4Rn6sIx/v2m2X0q9MRyIuz/8dKLmCJTHPFObTbdp2Y04D6Qf6RpyaZszlUqGlX6oOvL0tF5WY0GS+KApw8wXdoBC9riPfj22Nml4lQGZlSlbEvCAk8h+c/D46uNOCHJSxQ7tujphCmkOG686jFXyJLmdHqKxzEyKPk3ejRzG6g56mKYUWZn2euoW3AJZLhjANNSKN20XVIk4TZlCfH8tw6/krvYHcjL2+vEnF8rcBwHzZCi4TdRCTO17UVsDDLkEp5mO6Iz0u95EuF03AxWBiRbZTdL13Ez1oQJ3uHgqx1z1URG3blpIx5ASMmkiTSeE40WYBbrhhW17SgIOm/pT0zzZT1QZLlturBuV7sgfQTF3NVXh4fi4+A8MeFIm5c21zXYV5UXVWUyA8vRvb+iJl21X3yi1tLDMK0QpQHfzxN/H+lzps9J7AlIBF
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(8676002)(8936002)(71200400001)(316002)(110136005)(2906002)(6486002)(186003)(5660300002)(54906003)(4326008)(6512007)(91956017)(2616005)(30864003)(33656002)(966005)(64756008)(66946007)(478600001)(66476007)(66556008)(66446008)(76116006)(86362001)(6506007)(83380400001)(53546011)(36756003)(166002)(45980500001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?dXBMNE04cnZ5aDF6K1diQTNQUnAzcjMvemFmYUwrQkl4ZlZLSkxBZkhlZGdk?= =?utf-8?B?UGxySFRCTTVVaGNuZzBNZzNLMzZ0dUlEZXZZWlhnQ0lVZmZQUkdIWmtiWmxp?= =?utf-8?B?ZldZVzU5SlhLUFpMZTFrTU1wekM4NEQ1VUUxL042ZHNCbG9PYlFsczhBYnZE?= =?utf-8?B?dU9tUDVzUFU0L0VmVk5JYUVvRDU3Z3hudjI3TmFyM0FKN3crbmdzYUhRNHZy?= =?utf-8?B?U1FvblU4YWJmbzhOWW1JOERSSUNlVGR4MkVZRkdFMDNWSTNwSDY4d3RuSWk5?= =?utf-8?B?M09kQkhLam5ObTgxYzJDVUVieVBHVWs2d0dtTk9pYm9Dbk5rZUZkSFJGZ3VS?= =?utf-8?B?MWhJMUtiZkhkbk9xZi90WFVPb2s1bXkyNHR2YjZBdVlxVzhhaW5rRXplTnpR?= =?utf-8?B?ZVVIc2F3WjN0Y01mSm1Bbk1ucHY3eHJVN2Vnb3NwWHRzLy8vTDNIQ0xwdzBJ?= =?utf-8?B?ZVBVQUlsaEx3a0dUQ3prelZoZE1LdTlkUXpRRlBRU244R2VGc2tpVmpxLzNE?= =?utf-8?B?TnpLZmxyU2FCWjNXUW5SNlQrVXhqZUE4QmsyWjEralM3NU5oRlNrY29XcVRj?= =?utf-8?B?UHhEZFFGZXVDVTE0eUNIRzZoWTZ0azkyUkRYZVl2cm0rajR6ckFwVFlKWXRW?= =?utf-8?B?RUpNUzVpdk00VEhodGVwNTNwbCtJZUVETVloNXJQU2FRK2pDUWNVQXpkTXhH?= =?utf-8?B?dkszZVA2YXUyczl5b3BRY0RFbWhiWUtka2JWWndFY29Yb2QxdEZXVmJpZXA5?= =?utf-8?B?c1U2aGthcXhsUG41cHE5SXdzSVp1bnorUVNpdG5GNjJia1NQYTVnUEZRUWcw?= =?utf-8?B?c2FVdXVDSkorVU5QcWlJaWUyeXFIMU9iQlQwSVQ2eVJFMEFzaVJ1NndEektL?= =?utf-8?B?K1N4MUowRjFqSExWbzk3Q3ZML0VidXZ3REZPeWIyNmlpcWU1U0tmM2h0MTZD?= =?utf-8?B?emhhWnpTY2oxZE95bmNWaEd2ZHIwMm1BOXhpM1dhaW1OY1FJaE1VN1l2QWJI?= =?utf-8?B?OVUxNjM5STFTU3FoZlFXL1FpNytMK05lakN5dEVncEsraDhaZi9uOFZkYnNB?= =?utf-8?B?STVwckRyZTdQL0U4NGRvR0V1RXR4R1pFTVJwTVFnLzlQanVFTDR6SHl5bjY1?= =?utf-8?B?Q1ZJM25WUmZvUU5tMDZZUlZiMFJkTEJqdWdTQUljNTVCR05tMnF1N1RSekhF?= =?utf-8?B?cWZPMEo2dDV5bFpFNnpMeEpZU0RFQ1lzWGppblFrRXczL3RvVWppU3hNKzNj?= =?utf-8?B?UXMxTkdIaHVRMEdtOGlYS1R2aUxianVBcDVMQ29kbUlIamdNTWRHc01INWR4?= =?utf-8?B?TkVzYXJVZzdueWxlTUNyQlBQQ1ZJNGZsQzRwdkhCS0RzNjloYUJ6UDd5V2Ex?= =?utf-8?B?LzBrMlBhVThDTmlhMzc0VHZ1OFMva2F0TGh3SnRwL21DclJCYk8ycUgrWEZX?= =?utf-8?B?Wm9KWmF3UVA5djVReVc5KzNCQ0VpMERQZGNjejFkb2VlNGJVQXpLTFVXSE5j?= =?utf-8?B?VVRYUUQyOTZ3Z1RuL3p0aXdmNDRPQ3pMaTU4Z09iNi82UUtDQkhNTFhXbmNX?= =?utf-8?B?RnBESVVMN0lVa3BMVHRPbHlRUU9YajR3Y2FBbEJCbWhRUE5CQU0wMjd1ZWZM?= =?utf-8?B?Z0JJQ0lzL1MvOUdhN2ZpbWdaYnljSnQ4N1Z4cnpmN1pMNG96ZDBxeW5jUEZz?= =?utf-8?B?ZzFZODhoc3RUalZpOVVtUUlCV0lNS0hUZWNIMnA5elA1WDVtbXNXU2RnbGRB?= =?utf-8?B?dktFODRHdFhBNHJzRFhLTlg5Z2JxazZvOXMvd05GR3NaYS9IaE45VStydGtP?= =?utf-8?B?Y0FtbzdmbXNYK0R2ZTVXQklidWcwQzR3RWVKY0xvYjhYYlJCWjJaSzVodUEv?= =?utf-8?B?aUpMMm5MSVpDVDdmbWtSdWF1ZVNEbjZXdWc2eEdwSkVxWWc9PQ==?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_12135E001E51474D89C284BD089562DFjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e6e5c46b-9ae4-48e8-2a92-08d8e4b18d4a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2021 17:17:30.1538 (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: iladH9Yb5D8bpgodSpVHeAKAc4qD/cvzot+21xBl6fZEnz9QtXBfGJbOyhuqaViKASpPkqt4XOOo4/DCz4DfIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR05MB6833
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-11_06:2021-03-10, 2021-03-11 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 malwarescore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 lowpriorityscore=0 clxscore=1011 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103110089
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/JqSuIBjW5ztBXNPm3F0hjQ2yeEU>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Mar 2021 17:17:49 -0000

Hi Dhruv/all,

Thanks, meant to send this earlier too.

>> "figure out if the act of downloading the replication segment is considered a PCECC operation or a regular stateful operation"
[TS]: Indeed, IMO it can be a regular stateful operation and many of the machinery already defined (e.g. rfc8231, rfc8281) can be reused.

>> Also, in all stateful operations, the unit of signaling is an LSP (RFC 8281, RFC 8664, SR Policy Candidate Path, Multipath ERO). I guess you see the replication segment as an LSP operation (and so do the instructions sent to the leaves).  I see them as central controller instructions that require coordination across multiple nodes. This is a good discussion and I am glad we are having it :)
[TS]: Yes, I think when sharing of replication SIDs (section 3.1.1), this also allows a single replication SID to be treated independently. Thanks.

Regards,
Tarek

On 3/9/21, 10:09 PM, "Dhruv Dhody" <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>> wrote:

[External Email. Be cautious of content]

Hi Andrew,

Thanks for your email.

On Fri, Mar 5, 2021 at 11:00 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com<mailto:andrew.stone@nokia.com>> wrote:
Hi Dhruv,

"figure out if the act of downloading the replication segment is considered a PCECC operation or a regular stateful operation"

Could you expand on how you see the fundamental difference of PCECC operation vs regular stateful? Or correct the following statements if incorrect or missing something (?):

        PCECC : Explicit incoming/outgoing instructions on each hop end to end for a LSP that is sourced at a headend


I would say this is the first use-case. RFC 8283 also highlighted SR use cases which are all about programming and coordinating across nodes (not necessarily directly connected). IMHO the same is true for the SFC use case.

       Regular Stateful: Explicit outgoing instruction(s) on a headend where binding label could be used to help steer into that head end



And this has always seen as an LSP operation/state.

The view I have of replication segment is it has a “family relation” to the unicast SR Policy, and specifically it’s usage of binding label and egress label stack. Key difference of course that replicating packets vs weighted ecmp egress forwarding. PCE can deploy a unicast SR Policy with the intention of using it on that targeted headend or even as a transit for an upstream headend to achieve label stack reduction. A replication segment has the same philosophy with the exception that a replication segment can be encoded to indicate if it's shared or tied to a specific tree. Important encodings (binding label, multi-path ero) are being leveraged from objects being delivered in the unicast use case. I do consider leveraging these same encodings and mechanisms consistent between unicast and replication segment, and also consistent whether it’s a root, bud or leaf - without having to define new and reusing the concepts defined in those related docs. Yes, PCECC defines similar concepts and objects but appears to me like we’d have to define more-new things to leverage it and have replication segment deviate from its unicast relative and in return it would be picking only a very small part of what PCECC is accomplishing.


I can understand your point of view when I look at the headend operation on the replication node. It is the operation on the leaf nodes and coordination of SIDs required that gives me a pause. I also understand the wish to keep the PCEP message the same on the root, bud, and leaves.

But, the Replication segment is described as forwarding instructions. See  -

https://datatracker.ietf.org/doc/html/draft-hsd-pce-sr-p2mp-policy-02#section-3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hsd-pce-sr-p2mp-policy-02*section-3__;Iw!!NEt6yMaO-gk!WYXbT0WXt-LI_aq9HpXAvSL9U7NWznbT3vL3sdy7v6dR4a-7X0-oQv24IWfouA$>
   A replication segment is set of forwarding instructions on a specific
   node.  As an example the push information on the Root node or swap
   and outgoing interface information on the transit nodes or pop
   information on the bud and leaves nodes.

Also, in all stateful operations, the unit of signaling is an LSP (RFC 8281, RFC 8664, SR Policy Candidate Path, Multipath ERO). I guess you see the replication segment as an LSP operation (and so do the instructions sent to the leaves).  I see them as central controller instructions that require coordination across multiple nodes. This is a good discussion and I am glad we are having it :)

Thanks!
Dhruv (as a WG member)


Thanks
Andrew

From: Pce <pce-bounces@ietf.org<mailto:pce-bounces@ietf.org>> on behalf of Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Date: Thursday, March 4, 2021 at 11:08 PM
To: Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" <pce@ietf.org<mailto:pce@ietf.org>>, "pce-chairs@ietf.org<mailto:pce-chairs@ietf.org>" <pce-chairs@ietf.org<mailto:pce-chairs@ietf.org>>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Tarek,

Thanks for your message.

As I said to Hooman, the key is for WG to figure out if the act of downloading the replication segment is considered a PCECC operation or a regular stateful operation.

Since the replication segment state needs to be programmed on the leaves and the replication node; plus coordination is needed for SID/labels across these instructions. I lean towards PCECC.

And the argument for using CCI for PCECC operations is consistency and the ability to reuse concepts already defined. When an implementation supports multiple of these PCECC use cases, there will be consistency in implementation. But this is not written in stone and if the WG decides otherwise then that's that!

Thanks!
Dhruv

On Thu, Mar 4, 2021 at 3:25 AM Tarek Saad <tsaad=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Hi Dhuruv/WG,

From the RBNFs below (extracted from the bottom of this email), the difference I see between the 2 proposals is that the PCE-CC approach requires a new P2MP CCI object just to carry the resplication-sid  (which can already be carried today w/mechanisms in [draft-ietf-pce-binding-label-sid without the CCI].
Yes, both proposals I presume would work to signal the replication-segment. However, IMO, we need not mandate an approach (especially that the difference below is minimal and most vendors already have support for the “current” proposal). Let me know, and apologies if I misunderstood the proposals below.

>>
Current:
   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>] as described in [draft-sivabalan-pce-binding-label-sid]
 [(<PATH-ATTRIB><ERO>)...]
CCI-Object:
   <Common Header>
   <SRP>
   [<LSP>] <- not included for shared case
   <CCI> <- you can carry the replication-sid as TE-binding as a TLV here
   [(<PATH-ATTRIB><ERO>)...] <- this is a list

To Recap
- you needed ERO and PATH-ATTRIB and you get that here!
- the unit of signaling is a programming instruction and not a Path for the above case!
- aligns with other use cases in PCEP
<<

Regards,
Tarek

On 2/28/21, 5:24 PM, "Pce on behalf of Bidgoli, Hooman (Nokia - CA/Ottawa)" <pce-bounces@ietf.org<mailto:pce-bounces@ietf.org> on behalf of hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>> wrote:

Hi Dhruv

As per draft-ietf-spring-sr-replication-segment, a replication segment allows a node (henceforth called as Replication Node) to replicate packets to a set of other nodes(called Downstream Nodes) or hosts in a Segment Routing Domain.

A Replication segment can replicate a packet to directly connected nodes/hosts or to downstream nodes (without need for state on the transit routers). In some use cases replication segments can be stitch directly “Tree” or via a unicast segment routing domain “spraying”. In other use cases the replication segment can be a stand alone resource and act as a root and the leaf on the same node. In short a replication segment is a logical construct and behaves as a standalone resource, as an example it can be thought of as a binding SID on that particular node encoded via draft-ietf-pce-binding-label-sid

This is why the authors on this draft feel a replication segment does not fit the PCE-CC Architecture Design, as each replication segment is really a head-end resource or a root that does a form of replication regardless if it plays the role classified as a root, bud or leaf to deliver a multicast service. As well, the authors view is that encoding the data in a CCI object does not add enhancements, however introduces further complexity with new identifiers to be used in message exchange, new object codepoint and capability allocations, when the existing proposal based on simply ERO encoding using already defined objects achieves the intended goals consistently regardless if one would consider the role a node plays in an overall tree.

In addition the concept of CCI object will create further complexity for the protection paths of the replication segment. The replication segment outgoing interfaces can be protected via a single protection ERO. The ERO object combined with draft-koldychev-pce-multipath will create the perfect solution for this.

In conclusion to repeats the original point since a replication segment is stand alone resource on each node (as an example a shared replication segment as per draft-ietf-pim-sr-p2mp-policy) with the function of providing a replication instruction on that node it really does not break the PCE-CC Architecture.

I hope above clarifies the questions about PCE-CC decision.

Thanks

Hooman



From: Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>
Sent: Thursday, February 11, 2021 9:00 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>
Cc: pce-chairs@ietf.org<mailto:pce-chairs@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.


Hi Hooman,

On Fri, Feb 12, 2021 at 5:36 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>> wrote:
[Dhruv]: I feel there is some misunderstanding here. The PCECC extensions defined a new object called CCI, with different object-types to be defined for various use-cases. There is common handling for all such instructions and it is defined once and can be reused across multiple use cases. I understand that you want to use the ERO object with multi-path, and that *is* fine, you could in fact easily define the RBNF in such a way that both CCI and ERO are included for the new CCI object type for SR-P2MP.

Hi Dhruv

I am not sure if I understand are you suggesting we include both CCI and ERO as an option and vendor chooses? What benefit does this have? How would this improve the interop?
No, I did not say "or", it is not a choice!

In PCEP when we communicate with the head-end we use Candidate Path as the unit of signaling (with Policy as an association). For programming instructions (and not paths) we use CCI Object. New CCI Object-type for each use case can be defined.

I think your proposal to program the replication and leaf nodes as (section 3.4.2) -

   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>]
   as described in [draft-sivabalan-pce-binding-label-sid]
   [<ERO-Attributes Object>]
   as per [draft-koldychev-pce-multipath]

* RBNF is not correct, but I get the idea! I.e. you are signaling this as a path on the branches and leaves :(
=

What I suggested is that for programming the branch and leaf node, we should use CCI as a unit of signaling and you can include the ERO and PATH-ATTRIB along with the CCI. Note this is a new CCI Object-type and RBNF can be updated for it -

   <Common Header>
   <SRP>
   [<LSP>] <- not included for shared case
   <CCI> <- you can carry the replication-sid as TE-binding as a TLV here
   [(<PATH-ATTRIB><ERO>)...] <- this is a list

To Recap
- you needed ERO and PATH-ATTRIB and you get that here!
- the unit of signaling is a programming instruction and not a Path for the above case!
- aligns with other use cases in PCEP

Hope I am able to explain myself clearly and this helps!

Thanks!
Dhruv


Thanks
Hooman

-----Original Message-----
From: Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>
Sent: Thursday, February 11, 2021 5:01 AM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>
Cc: pce-chairs@ietf.org<mailto:pce-chairs@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Hi Hooman,

Please see inline...

On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>> wrote:
>
> Hi Dhruv
>
> Much appreciate your reply, Inline
>
> Thanks
> Hooman
>
>
> -----Original Message-----
> From: Dhruv Dhody <dd@dhruvdhody.com<mailto:dd@dhruvdhody.com>>
> Sent: Tuesday, February 9, 2021 5:28 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>>
> Cc: pce-chairs@ietf.org<mailto:pce-chairs@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Apologies! Missed replying to this email...
>
> On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com<mailto:hooman.bidgoli@nokia.com>> wrote:
> >
> > Dear Chairs
> >
> >
> >
> > Looking at the wiki page there was a comment on the sr-p2mp-policy draft.
> >
> >
> >
> > draft-hsd-pce-sr-p2mp-policy
> >
> > 109; More work is needed - align to PCECC, text needs to aligned to
> > the PCE WG style
> >
> >
> >
> > The authors took an action to setup a meeting and discuss the alignment with PCECC farther. The final outcome of this meeting was unanimous agreement, by all the authors/vendors on the draft, to go forward with ERO object.
> >
> >
>
> As an individual I-D, it is up to the co-authors to decide the content of the I-D.
>
> The comment (and earlier discussions) was to make sure we maintain consistency across all our documents that we produce. RFC 8283 describes the PCECC architecture, where the PCE needs to interact with not only the head-end routers (the usual stateful/stateless PCE case) but also with the egress and the internal P routers. The WG has just sent the first PCECC extension for MPLS label allocation along the path to the IESG. For other use cases such as SR/SRv6 SID allocation as well as for the branch node in the P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all use cases where the PCE needs to interact with other nodes beyond the ingress and provide instructions to them are using PCECC architecture.
>
> So when the PCE is interacting with the head end for SR P2MP Policy, it can use the usual stateful PCE extensions but when the PCE is interacting with the branch nodes and leaf nodes for replication segment, we strongly feel it should be described under the PCECC architecture. So you could use the ERO object for encoding the full P2MP path (and SR P2MP Policy) when interacting with the root node.
> But when interacting with other nodes, use the PCECC technique i.e. a new CCI object type (which could be used with the ERO if needed). This would help you to not reinvent things as well as maintain consistency.
> To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only and not the whole document. If you still disagree please list the technical reason why so that the WG can evaluate them.
>
> HB> As I am sure you do appreciate there are many ways to skin the cat. TreeSID can be connected via unicast SR path and not every node needs to be programmed. In addition as explained the PCECC did not provide the with flexibility to configure backup/fast reroute paths and the current methods does provide that capability.
> Again as mentioned we looked at PCECC very hard and tried to implement treeSID via this method but there were major short comings for backup and FRR paths.
> There are multiple implementation in the field that is using the ERO object for treeSID with success.
> Are the chairs suggesting that the working group is only dictating PCECC and is not open to any other option but PCECC for the purpose of programming the PCC and multicast?
> We have been asking for adaptation since 3 IETF ago and we keep getting pushback because our implementation does not follow the PCECC, why is PCECC the only choice on the table? Why isn't the working group open to other options to solve the multicast requirements? Given the fact that the ERO has been implemented and is in the field and in multiple providers labs being tested with successful outcome, I think the WG should have a open view to this implantation. Especially when multiple vendors and providers (Cisco, Juniper, Nokia, Ciena, Bell Canada) to name a few have agreed to this implementation.
>
>

[Dhruv]: I feel there is some misunderstanding here. The PCECC extensions defined a new object called CCI, with different object-types to be defined for various use-cases. There is common handling for all such instructions and it is defined once and can be reused across multiple use cases. I understand that you want to use the ERO object with multi-path, and that *is* fine, you could in fact easily define the RBNF in such a way that both CCI and ERO are included for the new CCI object type for SR-P2MP.

Thanks!
Dhruv

> >
> > The authors feel ERO object in addition to draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath Information (ietf.org<https://urldefense.com/v3/__http:/ietf.org__;!!NEt6yMaO-gk!WYXbT0WXt-LI_aq9HpXAvSL9U7NWznbT3vL3sdy7v6dR4a-7X0-oQv1oayAjlg$>) for backup paths is the easiest and the most efficient way to address the programming of a replication segment on PCC from to the PCE.
> >
> >
> >
> > The authors would like to move forward with the adaptation call please. In addition the authors are open to discuss the ERO preference in an interim open session with the chairs.
> >
> >
>
> The document has not been updated after 109, last we discussed this, we found that the document needed more work because it does not follow the way the PCEP extensions are usually defined. It follows a very unusual format (e.g. section 5) at places. It is good to provide examples but suggest it be done in a way that is more readable. Please follow the RBNF notations when specifying PCEP message changes (in a backward-compatible way). Some of your co-authors have vast experience in writing documents in this WG, I suggest taking their help. Hopefully, a more readable version will help you get more reviews.
>
> HB> sure this is cosmetics and we will follow the WG suggestion, that said this should not stop the adaptation call. The sooner we have adaptation call the sooner we can have input.
>
> HB> to close, as you mentioned some of the co-authors have vast experience in PCE WG and the same co-authors have agreed and recommended ERO implementation. As such I ask the chairs for adaptation call again ASAP. We will fix the cosmetics to be inline with WG recommendations asap.
>
>
>
> Hope this helps, and again accept our apologies for missing replying to this email earlier.
>
> Thanks!
> Dhruv & Julien
>
> >
> > Regards
> >
> > Hooman
> >
> >
> >
> >


Juniper Business Use Only
_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/pce__;!!NEt6yMaO-gk!WYXbT0WXt-LI_aq9HpXAvSL9U7NWznbT3vL3sdy7v6dR4a-7X0-oQv1Ut8b5-A$>


Juniper Business Use Only