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