Dhruv, Lots of thanks for acknowledging my questions. However, please notice that these questions have been primarily for the authors of the Circuit Style Segment Routing Policies<https://clicktime.symantec.com/15t5jWprMFR4ubqCP7aHR?h=MVuCPsRl9Rk-r8RbxoxSLZM9p9UCquDVAjz9I0EB8Ok=&u=https://datatracker.ietf.org/doc/html/draft-schmutzer-pce-cs-sr-policy-02> draft and not for the authors of the PCEP extensions for Circuit Style Policies<https://datatracker.ietf.org/doc/html/draft-sidor-pce-circuit-style-pcep-extensions-02> (there is an overlap).
According to the current agenda, the former will not be presented at the PCE WG session in Philadelphia, only the latter. And the agenda of teh SPRING WG session is not available yet. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Sunday, July 17, 2022 4:43 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Cc: draft-schmutzer-pce-cs-sr-policy....@ietf.org; p...@ietf.org; spring@ietf.org; Rotem Cohen <rotem.co...@rbbn.com>; Nitsan Dolev <nitsan.do...@rbbn.com>; Dmitry Valdman <dmitry.vald...@rbbn.com> Subject: [EXTERNAL] Re: [Pce] A technical concern regarding Circuit Style Segment Routing Policies draft Hi Sasha, Great Questions! Samuel Sidor might still be on a break. Can any other author like to take a stab at replying? I would also suggest covering this point during the slot in the PCE WG session. Thanks! Dhruv On Mon, Jul 11, 2022 at 1:45 PM Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: 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://clicktime.symantec.com/15t5jWprMFR4ubqCP7aHR?h=MVuCPsRl9Rk-r8RbxoxSLZM9p9UCquDVAjz9I0EB8Ok=&u=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://clicktime.symantec.com/15t5pM28os6fKYf7vfyS3?h=sKgq7rLSfOLBA5TTAOIDFeNZuHEeAyQF2na9pJYN-Ec=&u=https://datatracker.ietf.org/doc/html/rfc8402%23section-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://clicktime.symantec.com/15t5uBDRGUnFjVV3UENaf?h=TjPuumA14QW_bHx3Y39htKH4yjrsw6ftbeOuPFGP7G0=&u=https://datatracker.ietf.org/doc/html/rfc8667%23section-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://clicktime.symantec.com/15t5egdZtdjUVf1GqZB8o?h=ZELRMHfCGIrPSCjAH9SMAGfgRuBgDBhGK1ysUz8Az4o=&u=https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-08%23section-6.3> * Micro-loop Avoidance using Segment Routing<https://clicktime.symantec.com/15t5ZrSHS23t5iBMHzmzB?h=ubP-F1zfcTnv7mh4KkKrPKW3N_IpKByoFRWdr7iuF1s=&u=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.vainsht...@rbbn.com<mailto:alexander.vainsht...@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. _______________________________________________ Pce mailing list p...@ietf.org<mailto:p...@ietf.org> https://www.ietf.org/mailman/listinfo/pce<https://clicktime.symantec.com/15t5z1Qhj6Tr9SJy1nmjH?h=sBdzXyDtpMBuqKtMudUCU8RiS9-ow82sRIgrtYbQA5o=&u=https://www.ietf.org/mailman/listinfo/pce> 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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
