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