Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 20 May 2020 17:58 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E993A0CE0; Wed, 20 May 2020 10:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=F2m08+is; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U14V1sl5
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 KFyMZH5_ad4K; Wed, 20 May 2020 10:58:42 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFAC3A0CDF; Wed, 20 May 2020 10:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=304269; q=dns/txt; s=iport; t=1589997521; x=1591207121; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ANpQ3rqbEU6ddi3yJPHKRiy3rjre/TzEiXLVfm/aEqc=; b=F2m08+isKnY6L1qKQwwrW41allgCUq+Oi9RcIyKY/xkConjijP4M7Szt 7DKebtY4hA3uFUxd5JPztquJEd2irrltxVXY6Vhu6qSqb1u3c0QUFs8PP 2uBORO0WwpqDJjM+kBgBvwFH1N789v4ovRomE32yZlh1UBSZRU3v0E0fz 0=;
X-Files: image001.png : 158645
IronPort-PHdr: =?us-ascii?q?9a23=3AUC5lwh01axYtpK0CsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dtkVbWUISd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkhIEdnzZhvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBABob8Ve/4ENJK2FW7tPBQEBEgM?= =?us-ascii?q?CAQUEjQc6yF2QHYGzKBgN?=
X-IronPort-AV: E=Sophos;i="5.73,414,1583193600"; d="png'150?scan'150,208,217,150";a="482225838"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 May 2020 17:58:40 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 04KHweFv013778 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 May 2020 17:58:40 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 May 2020 12:58:40 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 May 2020 12:58:39 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 20 May 2020 12:58:39 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ehCVOEHL8x/yu+Y9b7QZ2hV2GXRdbOkHMQgF3ZM/rarrn/Ixpl7T15BOqiMmwg2k5iKkm0by3DLE/5JYSc1zorg0ZOhDj6y66HEm3SlkcPMoNd7CbJrxH90jNEoqRVRWf01U31Sey8aqcBFvC6nE7FeIZilb0OQncLmmvTqRiSMjA1/P3GADo18j83t370wFVjz6pRGDfcD3TbJALVa2X/V6TM2b8OrMb8cwXHWv6Xta2hl/RsWWPM9JXOdAMzgxMwziX2xZozIGReC8j8Sxp6mck4wAKm+/6cP1bU5ViPihjFAP7JHLqULQksNKO8FraQ5Vk/EN9dT/Szd128JK5w==
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=Qs2ScYrjH8E9S9dV1sUf6ZYsr15GLSafblMcv1WQlYI=; b=PVjy9LEKL01X7WMguFV2QYLRBzE5H7Bhfywdk6pm5614zjzdi5HS8j6XKDwMbVYZiNmRSjIzlNzVLUw8Qf3ThrUGsnyDSk+SXpWa2J48IIr1qiAPzRRSHEa3dC3QCMZYVC8y9iXOoHKOT+d/EO5FiKl7pGsNQfO7MzvZrqRGgvKy5MI3t9UB979m4cGMKT64X8VG9+sRKWtbIvGM5cD0vkyDsxBRgqFSbyUUCdz1ZDlepMc+uVHcNAxohjmePMEmZ3lnvD1CDJm/OQ5Rkz8E2IMzFBJtT8GU1UAcWMCgLj+EXALlryF9yxap71ZwtgQVoQC9OvcBXP59uquWg8riFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qs2ScYrjH8E9S9dV1sUf6ZYsr15GLSafblMcv1WQlYI=; b=U14V1sl5WWpNS1hcm441gi04f6hnQD76w6VZvJKK6WKSsQtQosoQLV0IzU7IWLq+ipQXsx6A/c/v9wK77aw3O6FiVZ78P9qaZW2QyiULNG8BK1+lOwlHRQFxgnJ01neg3lt3aWGcsKzBIDjvOJWBVHFs4F11yMiXpLA0QUySCi4=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MW3PR11MB4603.namprd11.prod.outlook.com (2603:10b6:303:5e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.24; Wed, 20 May 2020 17:58:37 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::9552:d301:4b19:601c%5]) with mapi id 15.20.3021.020; Wed, 20 May 2020 17:58:37 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Fangsheng <fangsheng@huawei.com>, Robert Raszuk <robert@raszuk.net>
CC: "Chengli (Cheng Li)" <c.l@huawei.com>, "draft-ietf-spring-segment-routing-policy@ietf.org" <draft-ietf-spring-segment-routing-policy@ietf.org>, idr wg <idr@ietf.org>, SPRING WG <spring@ietf.org>, stefano previdi <stefano@previdi.net>, Yangang <yangang@huawei.com>
Thread-Topic: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)
Thread-Index: AdYek4MmKSUhOySlR86q9L0AexcDnQANyexgAAFPYwADjsRb8ABl7jKAAADuRQAAAkA7gAAIGZVw
Date: Wed, 20 May 2020 17:58:37 +0000
Message-ID: <MW3PR11MB457080117E6483332BE0F2B1C1B60@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <C7C2E1C43D652C4E9E49FE7517C236CB029FAC88@dggeml529-mbx.china.huawei.com> <MW3PR11MB45702B49025A293583346F36C1AA0@MW3PR11MB4570.namprd11.prod.outlook.com> <CAOj+MMGbjvgn6VL3dKviuxzNNRk0pwFkBOTJUz15D8iSM9=-Rw@mail.gmail.com> <MW3PR11MB457083E56B77688CA68A2500C1B80@MW3PR11MB4570.namprd11.prod.outlook.com> <83bae48cc52d4a5da9a7ee76529a8d20@huawei.com> <CAOj+MMFs2fGy0ciyBJvoWng++oepamF8YxyO=QtR9yYWbazbqg@mail.gmail.com> <05da1ce8c7f949cf9ba5bec27fd1d64c@huawei.com>
In-Reply-To: <05da1ce8c7f949cf9ba5bec27fd1d64c@huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aaf6754e-f66f-4e22-86a2-08d7fce76c3b
x-ms-traffictypediagnostic: MW3PR11MB4603:
x-microsoft-antispam-prvs: <MW3PR11MB460353D8E811DD3EB66BAA2FC1B60@MW3PR11MB4603.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04097B7F7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: R+aUlFpXvlC9hlM+qiI4OaIgBzGFQp5FpuPrj6UtjY3isL2PVqhUP6Byouucv7PLQ/aCPwBTaPKsXLw3m4sJqfCC0rrsdYTgGGIRL3cdYMYxbk68QPloZNaA1824IJ2lm+1McdTlKtUOPZDFZPCHGD5XfGDpzdsFRW/gQbj3nTjruU/yNxJWYgjv30qkS0Y+xjfqLSCI6RLNuVeJrua8Gl6JvZfFvTgdwxo23B8K+JRXtn6cTF+KQGRfU3ew82Y6sFckGqR7nWrW8lhsJW4zFS6qJ+m9HFVhCUkRXdzXv3qtMgov7zUUpROUAGLXoAcvdJFIUL05/DYH2OcOC3FrT6pEo9KagjvSlbii+8XHZt2OkqnFvI7dROWGZztTVP684Vl+XkddcqX3BT7eBkg2/g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(66946007)(5660300002)(64756008)(66556008)(66476007)(66616009)(7696005)(86362001)(76116006)(66446008)(4326008)(166002)(33656002)(71200400001)(478600001)(966005)(66574014)(2906002)(26005)(186003)(110136005)(8676002)(9686003)(9326002)(30864003)(55016002)(54906003)(6506007)(8936002)(316002)(99936003)(53546011)(52536014)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: kk8/AJ0f2XO6gAJznr5YNMWXjclPbO9lZ/c1I4fVSdKR01rGYOQYsS4RqbkITxMeo8AEd99IQ4LkgmfX7ZSf0/d7WEo2HR2J/Hm3cO38DvnO0CAwOIitBFUXya3NVNLrKaLI3tRxLP48x5Bt53qycMtdvgCwDvhRKCLgJw1MMzlpMZdJ0fQ4yxJ5/Br7iJ/ojJKyGIfG6NSrKSpCtczkNN4raLsFfxQnnt5rX5bicZ4TfXmCKvaELtjkNJF8zcIEARD3CygBsHGe7OXblJZzrSXi8Pr2dv0KFle0/JR0rTUmZ5WM64xkJ3tmPPic5ssrU0/1IV6O9GFBRwWm7oKcFg/oLpUkS9KcQQjrw8U3T3d7EXpSNgwF2zJW8V6gTR3RvY9o41VV93zAj4QnhfUFSTPgoXU4Ut+oq33T+UfywhA785Eyvcjb2CQ0+ykNwZQkkXWRwF2ac3DcatzA234mZ6t1lMej4tVCvzkoRWTtP2ilidV6Dt0/+aZcxndvWhaP
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_MW3PR11MB457080117E6483332BE0F2B1C1B60MW3PR11MB4570namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aaf6754e-f66f-4e22-86a2-08d7fce76c3b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 17:58:37.7957 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HwnN+K9Bm22JZB2HbJFayxuzgeRbL10gSyv4e7S1UcjBVDQc7bYTXuBnuRkvvqOcRFEEV9SIAxq9IIPm7qel3w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4603
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/-x9zgD74YAoYgNIyrw6yCTj7mYA>
Subject: Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 17:58:46 -0000

Hi Fangsheng,

The BGP best-path run at CSG1 will pick one of the two paths from the two RRs since it is the same NLRI from two neighbors. So the best path is what would be given by BGP to the SR Policy component. The other path is to provide/offer redundancy at the BGP level as Robert mentioned.

See example 1 in https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-05#section-4

The only aspect that I understood or misunderstood was that you wished the “originator” that was reported to SR Policy component to be the controller instead of either RR1 or RR2 in the current case. Or at least I got the impression that was what Chengli was trying to say but I may be wrong.

As such, it is not a functional issue per se. The “originator” is used only for the tiebreaker between CPs in the SR Policy component and nothing else.

Thanks,
Ketan

From: Fangsheng <fangsheng@huawei.com>
Sent: 20 May 2020 19:33
To: Robert Raszuk <robert@raszuk.net>
Cc: Ketan Talaulikar (ketant) <ketant@cisco.com>; Chengli (Cheng Li) <c.l@huawei.com>; draft-ietf-spring-segment-routing-policy@ietf.org; idr wg <idr@ietf.org>; SPRING WG <spring@ietf.org>; stefano previdi <stefano@previdi.net>; Yangang <yangang@huawei.com>
Subject: RE: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

Hi,

I don't think CSG1 needs to "generate" anything. Peers which send you particular policy are well known at CSG1.

è Yes, The word “generate” is indeed inaccurate, I mean that CSG1 finalizes the key of the candidate path, not the controller. For example, when CSG1 needs to notify the controller of the traffic statistics of each segment list, the controller cannot recognize the key of the candidate path to which these segment lists belong.


Well what you call "waste" I call redundancy. Sure keeping extra paths requires some cost, but building redundancy in control plane pays off.


è I think it is enough to keep the route redundant in the BGP SR Policy address family, but for the SR Policy component, because the keys of the two candidata paths are different, it does not even know that these two paths are redundant


Thx

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Wednesday, May 20, 2020 8:59 PM
To: Fangsheng <fangsheng@huawei.com<mailto:fangsheng@huawei.com>>
Cc: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>; draft-ietf-spring-segment-routing-policy@ietf.org<mailto:draft-ietf-spring-segment-routing-policy@ietf.org>; idr wg <idr@ietf.org<mailto:idr@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; stefano previdi <stefano@previdi.net<mailto:stefano@previdi.net>>; Yangang <yangang@huawei.com<mailto:yangang@huawei.com>>
Subject: Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

Hi,

> the node-address is generated by CSG1

I don't think CSG1 needs to "generate" anything. Peers which send you particular policy are well known at CSG1.

> The process described above will result in a waste of redundant candidate paths on CSG1,

Well what you call "waste" I call redundancy. Sure keeping extra paths requires some cost, but building redundancy in control plane pays off.

Thx,
R.




On Wed, May 20, 2020 at 2:32 PM Fangsheng <fangsheng@huawei.com<mailto:fangsheng@huawei.com>> wrote:
Hi Robert,
Take the following picture as an example, I think you can understand our problem more easily.
The controller needs to notify the headend CSG1 through BGP SR Policy to create a candidate path of SR Policy. This BGP SR Policy route will be advertised to CSG1 through RR1 and RR2.
According to the definition in draft, the key of a candidate path is <Protocol-Origin, originator, discriminator>, where originator = <ASN, node-address>, so a complete candidate path key is <Protocol-Origin, ASN, node-address , discriminator>.
However, in this specific example, the node-address is generated by CSG1, and because CSG1 receives BGP SR Policy routes from RR1 and RR2, respectively, CSG1 will get two different node-addresses. CSG1 thinks that it is necessary to create two  candidate paths, and the controller does not know what the node-address CSG1 will eventually generate. Maybe:
Candidate path 1’ key:  <BGP,RR1’s ASN, RR1’ BGP Router ID, discriminator1>
Candidate path 2’ key:  <BGP,RR2’s ASN, RR2’ BGP Router ID, discriminator2>
The process described above will result in a waste of redundant candidate paths on CSG1,
At the same time, when CSG1 needs to announce the SR Policy information to the controller through BGP LS, it needs to carry the keys of the candidate path in it, and the controller cannot recognize these keys.


[cid:image001.png@01D62EFE.BFF53F60]

To solve these problems,  We recommend carrying the Route Origin Community (defined in RFC 4360) directly when the controller advertises BGP routes.
In this way, the key  of the CP is determined by the controller and will not change during the advertisement of BGP routes.




发件人: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com<mailto:ketant@cisco.com>]
发送时间: 2020年5月18日 20:00
收件人: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
抄送: Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>; draft-ietf-spring-segment-routing-policy@ietf.org<mailto:draft-ietf-spring-segment-routing-policy@ietf.org>; idr wg <idr@ietf.org<mailto:idr@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Fangsheng <fangsheng@huawei.com<mailto:fangsheng@huawei.com>>; stefano previdi <stefano@previdi.net<mailto:stefano@previdi.net>>
主题: RE: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

Hi Robert,

You are right that the “Originator” is not used in BGP best path and is just for a tie-breaking logic in SRTE between paths from different protocols and controllers. I doubt if there is a functional issue here.

I thought that Chengli was bringing in some new/different requirement for the “Originator” field for some deployment design. I haven’t seen a response/clarification from him as yet, and so perhaps I misunderstood him in which case we are ok here.

Thanks,
Ketan

From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: 30 April 2020 14:46
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Chengli (Cheng Li) <chengli13@huawei.com<mailto:chengli13@huawei.com>>; draft-ietf-spring-segment-routing-policy@ietf.org<mailto:draft-ietf-spring-segment-routing-policy@ietf.org>; idr wg <idr@ietf.org<mailto:idr@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; Fangsheng <fangsheng@huawei.com<mailto:fangsheng@huawei.com>>; stefano previdi <stefano@previdi.net<mailto:stefano@previdi.net>>
Subject: Re: [Idr] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

Hi Chengli and Ketan,

Well I think (perhaps to your surprise) the current text is actually correct.

See the overall idea of section 2.4 is not to define the real source of the candidate path. That is done in section 2.5 The idea here is to keep multiple *paths or versions* of the candidate paths in the local system uniquely.

See if you continue reading section 2.6 demystifies the real objective:


   The tuple <Protocol-Origin, originator, discriminator> uniquely

   identifies a candidate path.



So the real originator is encoded in discriminator and here it just means the peer candidate path was

received from. And if you read on this entire exercise only servers best path selection as described in section 2.9.



.... the following order until only one valid best path is selected:



   1.  Higher value of Protocol-Origin is selected.



   2.  If specified by configuration, prefer the existing installed

       path.



   3.  Lower value of originator is selected.



   4.  Finally, the higher value of discriminator is selected.

+

      The originator allows an operator to have multiple redundant

      controllers and still maintain a deterministic behaviour over

      which of them are preferred even if they are providing the same

      candidate paths for the same SR policies to the headend.

Thx,
R.

On Thu, Apr 30, 2020 at 10:46 AM Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hi Cheng,

I assume you are recommending the use of Route Origin Extended Community (https://tools.ietf.org/html/rfc4360#section-5) for conveying the “Originator” when the SR Policy update is propagated over eBGP sessions via other eBGP/iBGP sessions instead of direct peering with the headend.

I believe it does address the scenario you describe given that it is expected that SR Policy propagation via BGP is happening within a single administrative domain even if it comprises of multiple ASes.

Also copying the IDR WG for inputs since this would likely need to be updated in draft-ietf-idr-segment-routing-te-policy.

Thanks,
Ketan

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Chengli (Cheng Li)
Sent: 30 April 2020 07:34
To: draft-ietf-spring-segment-routing-policy@ietf.org<mailto:draft-ietf-spring-segment-routing-policy@ietf.org>
Cc: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; huruizhao <huruizhao@huawei.com<mailto:huruizhao@huawei.com>>; Fangsheng <fangsheng@huawei.com<mailto:fangsheng@huawei.com>>
Subject: [spring] Comments: Route Origin Community in SR Policy(draft-ietf-spring-segment-routing-policy)

Hi authors,

In section 2.4 of [draft-ietf-spring-segment-routing-policy-06], introduced how the node-address of "Originator of CP(Candidate Path)" is generated when the Protocol-Origin is BGP. It says:
    “Protocol-Origin is BGP SR Policy, it is provided by the BGP component on the headend and is:
     o  the BGP Router ID and ASN of the node/controller signalling the candidate path when it has a BGP session to the headend, OR
     o  the BGP Router ID of the eBGP peer signalling the candidate path  along with ASN of origin when the signalling is done via one or  more intermediate eBGP routers, OR
     o  the BGP Originator ID [RFC4456] and the ASN of the node/controller  when the signalling is done via one or more route-reflectors over  iBGP session.”

In the operator's network, in order to reduce the number of  BGP sessions in controller and achieve scalability, the controller only establishes eBGP peer with the RR. And the RR establishes iBGP peers with the headends. As mentioned in the draft, the headend will use the RR's Router ID as the CP's node-address (the signaling is done via route transmission from RR to the headend instead of route reflection).  The headend needs to carry the CP's key when reporting the SR Policy status to the controller through BGP-LS. And there is a problem that the controller may not recognize the key because the node-address is generated by the RR node.

For network robustness, two or more RRs are usually deployed. This will introduce another problem.. When the same CP advertised by the controller is delivered to the headend through different RRs, the headend cannot distinguish whether it is the same CP because the node-address in the CPs' key  comes from different RRs.

To solve these problems,  We recommend carrying the Route Origin Community (defined in RFC 4360) directly when the controller advertises BGP routes.  In this way, the key  of the CP is determined by the controller and will not change during the advertisement of BGP routes.

Thanks,
Cheng
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr