[spring] A technical concern regarding Circuit Style Segment Routing Policies draft

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Mon, 11 July 2022 08:15 UTC

Return-Path: <Alexander.Vainshtein@rbbn.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C12AC15A727; Mon, 11 Jul 2022 01:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rbbn.com header.b=Uo9eFjX8; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com header.b=PjBGgQau
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbXYIWaGIHeG; Mon, 11 Jul 2022 01:15:37 -0700 (PDT)
Received: from mail1.bemta34.messagelabs.com (mail1.bemta34.messagelabs.com [195.245.231.3]) (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 66645C14F749; Mon, 11 Jul 2022 01:15:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=rbbnselector03122020; t=1657527331; i=@rbbn.com; bh=8lw3JYMkD4VFcYmhJv6HPhfN1ESSnn53atoQYCRFftc=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Uo9eFjX8o1R0fDgiuuyUDJtgrFZXXjAUshKGEMCAnjuoznOHDH4oRT761f/Iv6Pzo PDv3A0Fs4toHzSiMKo9N4ymtoxEgJT6y5WSshjpsCN1oX7zSXIkSrB34indQfzU64N 9wtDhqz1lvRwMCL5+Tnb9RxdQo8i1BYCvb+3BI/R+QXyvsmt45sMeTiNk6lzK9g2Fc XGX7fwG3hDLpM6rubRUlYs+C33fG6TkphWdmk5rtSCBvnZXEY/0zLSdLo5ONhqF500 lAMv67I2f9TU3KCunAAiuneLiu5l/0sVRn97NF8sLM1HbxKhaXjYeQrOdj6/TXQbvz dK4+kbIOQuWRA==
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTf0xTVxTHuX398XCUPFoYV8S5NZnJmH1rJdP 6449lmm2MjW1GpgM3ebVvtEn72vW1WIgLxJktiCYsY6JMbEcqDIYwTETtD2GggWoziyvILyes zkkxUDuGaaBur33g2D8nn3u+557zPcm9KCKqEmSgpMVEGilCK+Gv4qpf2ayVSsZvKGUdo+sVk 54BjuLw3WGBos+3AF5D3rLbI5z3QQFPQyn1liKeuj00yTFUlltmrbkVYNxwFKxCAXYWgbV944 A9NPCga+iagD20AFhpXWSURJSLORF4cmBHTBBhVg4MdF7lsIc7AFqbQpxYFR/bChdmvdwYp2I qOOFuivdFMBeA4bFTvJggxnZDz9RJhC36CP5oc/NZxuGlL+cQdtyLsOHn1jgLsY/h7d+m4zUA exY+vt4aH4Zg6XD0njXOEMOg3XUTYTkNTgWe8Nh6I/x1shWw+bXwlrVqid+FAz4/j2UpHPmlm 8vyc7Dl+OQSr4MnGmYFLGfCieGLfJbtAuidz2O5hQsfVO1jWQbPzF/lxxaG2BkMjvz+F2CNUr C+qYvLLpMCPafuLQ1YDavdP3GrwUt1K/apW3GlbsUVNr8B2pxhPssvw8bvp5Fl9nYHOCvzNiB oAduURk2x2qQjNFqpXCaTyuWvSrMVDG7BiTIpgZNm6UGSNkk34sRBGidpGqdLdQe0KpwiTecB 88JU9HrdJVDTHMF7wGqUI0kTij03lKJkpV5VqiZo9X6jWUvSPSATRSVQ6LvNaClGspi0fKrRM u90WYZokiRVONjPyELaQOhoTTErXQcHUH+n242gNy93MXGi38PE5l4/E53xGA1HmTjUbrvC8I WFLgT99rsnTDx/5Wg3IuJSeorMSBfmjDKtsVhrtZl6Onj5j9wCazPEQpCQkCBKMpBGncb0fz0 I0lEgEQtdMf9JGsr01F+Qsc5hrH+i6o9ZNxH/SRkVnJwy16ZSx+X981XTeWAxdWwOeM3lX9xd U7PXMVGSjNeXRJ39VCglbNun6c6cMll2VvcRH0y919hrzC7PVm61v/4VUnKh+f794OmCd2Zya sJIzwle/mcdBeE1h/wkLj9EUXxzpDCYVddxsW+sdYsyua2m8pE7c5d0B9n5cHthNPrPh3XnZp DFAD+t91jWSHpzUqDijSpv27k/cr+5k+fwB/M3dTsba0NvKtb59wx3/VmbsTd59+adc8f2JOp 3vVCUN3j4h4dFx0NHstR/9z4/lGj72lHv3+hzPDr7jNhQSDRtePvBkdRtel2kPWzLbb+WoI3k b5f5Sh9nf942aC47PTAj4dJqQp6FGGniXzFWT02eBAAA
X-Env-Sender: Alexander.Vainshtein@rbbn.com
X-Msg-Ref: server-14.tower-548.messagelabs.com!1657527329!132381!1
X-Originating-IP: [104.47.55.108]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.87.3; banners=rbbn.com,-,-
X-VirusChecked: Checked
Received: (qmail 10052 invoked from network); 11 Jul 2022 08:15:30 -0000
Received: from mail-mw2nam10lp2108.outbound.protection.outlook.com (HELO NAM10-MW2-obe.outbound.protection.outlook.com) (104.47.55.108) by server-14.tower-548.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 11 Jul 2022 08:15:30 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FX70qrzmv7A8urfDuBz9qxpNUBAVPfwlTWY6L2SwNTj8X+4JQy8T3SBW97tEb+qFkMTPwSrBZ3havoB0GgCZ2jVtce06Kncw47Q40r08PAoEReY3FAhQ8/A9Cy/BW8MpM6mDPjMtIQDZ7s0egGLsBdCd/4G8skC972SM5WLK7juAFXvmtWkl7l+C4boQcilj2JEl/O7fK4XhlxuJPrqv/xU37BbjAeg3uLnW3XCo8yOGsdFNNyC55DhAre5ejOPX2Sz61ci+DATHJULCijaDFZTXkKeQDDKpa9IExLpFv81IUKhA6dxfw4VV7UDp4/jo7aS991SCd3i1AJHYal/Geg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/sbveijZgp7vzGEPDQDu5x8FM6Lz9EFXFJXAi5LmZWE=; b=OuXTApMJlElARXiMLN6vEjV3uAjMvADZHDKGbgL5EFgYn+kwJe731f/jSnBpmIiDf2eGTaBdtTvbLi4/N394m2ZrMhiyBUFmXY98MIMn9ogZA6qokU1iwwwEVjQmRJkO2JLc0HwOZbO2t9nARfG1djAh3v0MumFIby5oWHZUYhc/t7KWid3J4F00iSL22Dmr7Owx0VCpXhzoNv5c/dDkLzwX5Wegfi7HNCUx2XiFXgD4Y+3mh079MsdGPyDcT/bU4FdO3EXA5WceiPpXG5ZAjFbR9BN7RYCKcazLwVQdPCoE9FWU/iGKM31V5/JI18fWq4S4l/Owv/WqbUJF72q+2Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rbbn.com; dmarc=pass action=none header.from=rbbn.com; dkim=pass header.d=rbbn.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector2-SonusNetworks-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/sbveijZgp7vzGEPDQDu5x8FM6Lz9EFXFJXAi5LmZWE=; b=PjBGgQauAQ+3Spcv9tw8CzZIMfua3L/Ju8XmfXDXGzftfhzHu3uMkmuOoSOVEBQ1auer6v2vZBkHxuUfPzNCyQ4vA4U82Re/STE5p1mOmfnumP2moJqjJE1qAmAklXM04cndmp9L2WHdQNgoLzdT1iZylRb/JcPcTg376b768OI=
Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by BLAPR03MB5556.namprd03.prod.outlook.com (2603:10b6:208:297::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Mon, 11 Jul 2022 08:15:26 +0000
Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::3951:dd39:e905:a0e]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::3951:dd39:e905:a0e%8]) with mapi id 15.20.5417.026; Mon, 11 Jul 2022 08:15:26 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: "draft-schmutzer-pce-cs-sr-policy.all@ietf.org" <draft-schmutzer-pce-cs-sr-policy.all@ietf.org>
CC: "pce@ietf.org" <pce@ietf.org>, "spring@ietf.org" <spring@ietf.org>, Rotem Cohen <Rotem.Cohen@rbbn.com>, Nitsan Dolev <Nitsan.Dolev@rbbn.com>, Dmitry Valdman <Dmitry.Valdman@rbbn.com>
Thread-Topic: A technical concern regarding Circuit Style Segment Routing Policies draft
Thread-Index: AdiU+M9B8bIbdBbXRy+J6l7zu740jw==
Date: Mon, 11 Jul 2022 08:15:26 +0000
Message-ID: <PH0PR03MB63003CD1375C7712BF247CE8F6879@PH0PR03MB6300.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13d7ca28-df9c-446b-1ff3-08da631582b9
x-ms-traffictypediagnostic: BLAPR03MB5556:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Fa45GxiBsG+AqVCmRJBUG1c3jJGRiNRlKwa7Z2c4Nz2Z+/5PKyHf6Fcc5RbM3ZGDC4OgDbcqqNR/EZlreSF5ZcqYF8zgn9SISeY7J4yvK/5eUc2+38CXdDGqltc3o8nnRVa4TGhzBU50130KJ8+t86dndaTvTcB7qeIHnTgF95YarSsl8hG8YPSM2Ji9qJ6tnZOXu58jVG+e8goG0kyz9sakY67ysfXGzIg7QOQxPIY0pC9+YJXFhG1wTnOTx4J/87zTfbIWIJ9jRlMQzbJfyxB12Ui8qryS0tAxmb7M/COiM6TepjDhKpt4nzW1kLk8VBSfgUXGUqMN+c5D5Xc2lVLtVMLeOQiTzTmzgPdF5kYxqY4ovvUO025c1J6DgLyBUTMS39QLxWw8lKGZ/9GWtFeP/q4mcWMjfwYmdPtve+XKXPXk3Xx6eGaHRbtjzoNQpzK+ONz30SMnuVb3+lDICLHdm0ldpPZBwfI/Rl3/B3uHYQ7urPEjC43nj0Q49iJrswJsjSh4EE3f5V0EkLja/ffxiv1Gf1op1SM6RMSf/5qma3lHXuUfOfV7/cQ3Arpv27LK5KdkfTts1Cl6KpPorLr1cptRvgy3VrHKLn1vZcHLD3gkLosc3/0IFey4EbRAN0ujYG0rvh+FxWUX6y+/dzBT/SbJkVR8313Z4CXX3Nrk6n8AV67+t/KfylV8aH3/dQ7qpptsHuKROa/aCbeR+vVIg7O0p+8MqCFtnhaFTzsYzc+bSKDkzzK9AY5aCWy7hz0Loa+V36CwivmI3OdK8XLiyTdzHtnmwndhX1+EGMC46aZtTe5AUynSpsBYveoNJp+5LOMuDg2ioM3UxbfB6IkalmytOTUKHGS7TL9cY8ViBCWD5lJScLI8xObYVmjI
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR03MB6300.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(39860400002)(366004)(346002)(376002)(396003)(136003)(38100700002)(38070700005)(122000001)(166002)(186003)(107886003)(5660300002)(8936002)(66556008)(66946007)(4326008)(52536014)(76116006)(8676002)(66446008)(64756008)(66476007)(55016003)(2906002)(41300700001)(9686003)(7696005)(6916009)(316002)(450100002)(54906003)(71200400001)(478600001)(6506007)(26005)(33656002)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: hianfF9imTKr2y2FZ037abFQOl2qp1m4ZaD7CtttI53xascnzlfcxIyvxglbXZURk2epJDW/Q4jhOcRGbW/UOZ1nY2hJdCLoaL5XdTgw73endY/XIBdN2zVykqDJHrau9ThSS2tlR0KbzbWRzeVnOtRFGisaZP2HY5mClvScld2YM4idc7nfGUtcqyZXuWTLdoOMZzChuHFc371xF/kyVVH4KWqkXeXxkUCkTKGujnDz6zo3VcAu5gBWInfG8dn9OZmRdLUvi0gHlVc00P42GJOyy0TljacjEG4S7RPZOa6yPgabLtc6NMsMsYXuWiYAsW58AQA4T70kuAHxFui+0XJvYxjPD5+SxHBcjN8EBU+dgwEByy9IGz0mZtQ5JFSBm8ucG2MHbzN5rtR80w7CLMopWGVX+R2p0RNXiJFrPH0weSr0y/GfHaVtnU6rN9B+Mt12LMICoZJU8qyHQJJ0CyWsbHbE9SotX/fG6kDlZYVdxLrH6GBDpyoCE8pTtT8t3MkIMZccjRg/WmFVTnCwXjQKLIt435G7UIMsAEvsT1VWOH2IO44oFqNQ+mo9Qm0l5ymV+vgL6J2N8z39t85Ktz1wBobCLNu+uDmxmGt7RRsV7OJbAooFvCpDyXaEhDBNYBpseG0oevX0Hxjb8UYKO8hH922vABgdL0ftQf5qSvls8shwX28Kw5GldXDJ8c5bstQcjujcmuDvm1gPGWyyiAvaea0IkK2e1C+EEKzJAr+KY+6+I2R1I9bZ3kTkSASqn1Yr8lTRexDKbPQZXPeL/hJOIBDmJxFWr1bnIHYN9qocDGwRmzCBV+yFlyt8KkgnW9Iak5incOuSnBDTqsvMWkFhG314ruY2+z6iD8as+Ecsak+geNvd8YdGsoV7ib9YV56ubaDidL3WhWbJDLAd2s7EmGcFgwLObTw2riWmtHUqrsvJXZ48AnLxgg/asq2MRBdSCu7rCOFdQH5+RrCzcC3RpHaB8aWTMmEd8obavAp/1jUM34t+qgMibqOjvTW3JaWzPdWM6T/knfZKHqm9x8ijl7aPYp/6bCKXDBtRMG80a5yRbwP68wNPogHYV3pFcDdJ/kL6GCwUGBc/4FT3AlxWUhr7jtGpVE9bAXp5YRaT0eeb+JNRpu0Fl4k/JzYvjPazYwF+sPVUBLS94He6FzfDcqU1F6lHn0baL26LD1iIztFdrL5wcu/U/IxzezssalOev5XhDdUCpb//ThGdy5kdf+lhvdPgu4X9eVkJG1AItOcC77Ms+j603JilNOTd4ljTqPojG5mEUukYReHHXeeH2j1YrzfbtEPEtI/WtriGCbBr+8BJmyDMBh0GvsOxdkV7W2H4q/iqOPAeaTBFBsDP71VAZdoN1tRNI+bdj2W20GI/natvgCeHvC+crFmhUE85b7kvG65TUQK8SLXE//pwHB2XX7Ch7+e4ZRuYBIqXU4w8mME6hSXz2hbPvxc2t3HI7FLEbUkL65gMjef4pyy4jtVTmOZawLTHJnJ8nXrTKY55qqObDK6W1pR7+TmMLQ1xIW3yQ0OdlDLC7gQOO+QqEn226/EOruGr8SJ4ccE=
Content-Type: multipart/alternative; boundary="_000_PH0PR03MB63003CD1375C7712BF247CE8F6879PH0PR03MB6300namp_"
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6300.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13d7ca28-df9c-446b-1ff3-08da631582b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2022 08:15:26.4355 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 68I70pzKPaBcg37Kk2sVdLvvQ31oWxyp1sFjiG/krB55M+8jcNZThwe5StaKnLWJJWP/Uv1sJRAz1vc9JI9PKQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR03MB5556
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/J5GE4XZBYNYB-upA7qj01xJHqRQ>
Subject: [spring] A technical concern regarding Circuit Style Segment Routing Policies draft
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
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, 11 Jul 2022 08:15:41 -0000

Hi all,
I would like to share with you what I see as a serious (and probably critical) technical issue with the Circuit Style Segment Routing Policies<https://datatracker.ietf.org/doc/html/draft-schmutzer-pce-cs-sr-policy-02> draft.

As I see it:

  *   One of the key objectives of this draft is to provide bandwidth guarantees for SR-CS policies
  *   The draft proposes to be achieve this objective by implementing these policies as stacks of unprotected Adj-SIDs (augmented by B-SIDs as teh stack depth reduction mechanisms) and associating specific BW guarantees with these Adj-SIDs that are known to the PCE-based controller.

The problem with this approach (as defined in the draft) is that IMHO and FWIW it completely ignores the possibility of using Adj-SIDs that participate in SR-CS policies for other purposes that are neither controlled or recognized by the PCE.

It all starts with the definitions in Section 3.4 of RFC 8402<https://datatracker.ietf.org/doc/html/rfc8402#section-3.4> that state that:


   A node SHOULD allocate one Adj-SID for each of its adjacencies.

   A node MAY allocate multiple Adj-SIDs for the same adjacency.  An
   example is to support an Adj-SID that is eligible for protection and
   an Adj-SID that is NOT eligible for protection.

This approach is aligned with the way Adj-SIDs are advertised in IS-IS extensions (see Section 2.2.1 of RFC 8667<https://datatracker.ietf.org/doc/html/rfc8667#section-2.2.1>) and parallel definitions for OSPF.

It is my understanding that in practice, in modern networks exactly two Adj-SIDs - unprotected and protected - are allocated for each IGP adjacency, while the SR-CS draft explicitly precludes usage of protected Adj-SIDs in SR-CS policies. SR-CS draft neither explicitly require allocation of additional SIDs nor specifies any way for differentiation of such SIDs (if they were allocated) from the "normal" unprotected SIDs in their IGP advertisements.

And unprotected Adj-SIDs  may be - and typically are - used by the following mechanisms:

  *   TI-LFA as described in Section 6.3 of the TI-LFA draft<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-08#section-6.3>
  *   Micro-loop Avoidance using Segment Routing<https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-13>. Multiple examples in this document explicitly refer to usage of Adj-SIDs in the micro-loop avoidance paths, and, to the best of my understanding, usage of unprotected Adj-SIDs is expected to guarantee loop avoidance.

Both above-mentioned mechanisms are commonly considered as necessary for reliable delivery of what the SR-CS draft calls "connection-less services" and, AFAIK,  are widely deployed today. Both rely on network elements locally computing certain SR-TE paths after each topology change and using them for forwarding traffic under certain conditions while the PCE, even if it exists,  remains completely unaware about both potential and actual usage of these paths and amount of traffic they carry.  The time when these paths are used can vary and may easily be extended to a few seconds "to be on the safe side" (e.g., to guarantee that all the routers  in the network have completed their IGP convergence).

It is easy to see that, if the same Adj-SID is simultaneously used in the active candidate path of a SR-CS policy and in a transient SR-TE path computed by one of the above-mentioned mechanisms, all the BW guarantees of the CR-CS policy in question can be violated. And there is not anything that the PCE or the head-end of the SR-CS policy) can do about that; most probably they even will not be aware of the violation.


Hopefully these notes will be useful.


Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.