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> 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://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.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 > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
