Re: [spring] [EXTERNAL] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Robert Raszuk <> Mon, 19 June 2023 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEF11C1524B3 for <>; Mon, 19 Jun 2023 03:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.095
X-Spam-Status: No, score=-0.095 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, GB_VISITOURSITE=2, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x5CNpR94uALf for <>; Mon, 19 Jun 2023 03:10:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id F361CC14CEF9 for <>; Mon, 19 Jun 2023 03:10:43 -0700 (PDT)
Received: by with SMTP id 4fb4d7f45d1cf-514ab6cb529so8416798a12.1 for <>; Mon, 19 Jun 2023 03:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1687169442; x=1689761442; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TXL8s4Qx781YhI9DEsLtxUGM1nQQyEMzdV4C3F2KGTI=; b=HbjcuCqM5xC3I/qxdf5omSQ3tY3zVxqFhaPPAqUmyO13bkFk5MJd5G4pCZ48Qs3bKF mEDtm8GAzgfCoZ0JfjZ6WEk8jAG7sU0U+hu9PyhhIyuf6l7HetTXxlmJzgLYkHXjaw2x wLkX0wKF+CVrX6Lxvr6ucz+3C8RyySkG21CYsmN7aXwFSTPgFJUPg5uQ5ulko3fg2vtc nB93XaHWuTbenTVXTee9iqxphwaTAqEHRLuzgVMJi+CaRjx/TyLcvqVKjO1XW11m/itz nu5/cvm3rOyAjbMy/d+/g/bmUNndgVtRpv31LxR3//DuqwIcrnlke9hhNQ8eOMp9I88H 3Rdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1687169442; x=1689761442; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TXL8s4Qx781YhI9DEsLtxUGM1nQQyEMzdV4C3F2KGTI=; b=ZaA5DB/3CJvN0vup1cRzrQc5ZjlWNUPjy6LHKWUyfJChQyuhuzmDN4LJn5FW56UwCv 9sr7bLfmwGFg3EFEU8Rj9a+hAlCxJkQPPoChDqihoTW8bZNSXLWd1icgH2N9OyNNtTBm wN0F0w/HJaRuigx6psHKvJmSdiRKdj78vP4WgFuWmz/TJHrKw9/VutA0EFGngSYpiGhZ xDfYeSu9tEvi6RCICsvcG+jB4tlyCbJyiIrhSTnjwgLZepKK1cPeQx39pFXVzmohjk8w 2WkmgtR+ldP8IoZq2jxusCyULAO/HrT4FzmYkGTGS2io+rrIB2mYazxVuyG8bOAEKt1I 9suw==
X-Gm-Message-State: AC+VfDwfQU9Dzb8U3YyiV5/LjBdHdYrStWqm78OrIl3Zi4n+qc+5qqMB 1oUXB1qD6PpZJxsiWmbTdqz3wfCfW/LtR30CZBUhKA==
X-Google-Smtp-Source: ACHHUZ4as83xF7KEgX2TqFss9AM3HsM3FuRQK1UOYVURoYtosVOLY3P5MqNpDSIOhz/oED3Uy7lB/xtMKzLHK/FO7Hc=
X-Received: by 2002:a05:6402:1e89:b0:510:e8dc:f2a7 with SMTP id f9-20020a0564021e8900b00510e8dcf2a7mr14739096edf.7.1687169441937; Mon, 19 Jun 2023 03:10:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 19 Jun 2023 12:10:30 +0200
Message-ID: <>
To: "Christian Schmutzer (cschmutz)" <>
Cc: Alexander Vainshtein <>, "" <>, "Dongjie (Jimmy)" <>, Stewart Bryant <>
Content-Type: multipart/alternative; boundary="000000000000434f5c05fe78bfb3"
Archived-At: <>
Subject: Re: [spring] [EXTERNAL] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Jun 2023 10:10:48 -0000

Hi Christian,

> I agree we may want to adjust the wording a bit around what we mean by
“failure/fault” (i.e. not only a link
> down but also issues detected by SRPM) and how to react to it (i.e. bring
down a CS-SR policy)

That would be super helpful and indeed a significant improvement.

- -

As far as discussion about router design - we perhaps should not do that on
this list. Yes you may be correct in respect to the properly working node
(some of them at least). I am worried about bugs and moments of unexpected
events handling. Stamp-srpm end to end may detect it though and if this has
a auto loop to service state or at least to notify external transit users I
am fine.

- -

In respect to comparison with RSVP-TE to me it looks like this proposal IS
suggesting a radically different approach. Even GB-TE was using control
plane reservations while your draft is suggesting use of data plane
dedicated resources.

Clearly it requires a global (to the network scope) controller not only to
push SR policy properly, but what is even more important is to push traffic
policing to all ingress nodes. Then as we established control plane traffic
will use higher precedence queue so any bugs in control plane resulting in
excessive traffic could easily result in broken CS service.

Hi Sasha,

As to the mapping of flows to queuing don't we have an option to use say
flow label ? Why would that need to be embedded in adj-SID ? Of course
irrespective of how the mapping is carried, resources must be there -
blocked and wasted if not in use - even if the entire system works as


On Mon, Jun 19, 2023 at 9:33 AM Christian Schmutzer (cschmutz) <> wrote:

> Hi,
> I am sensing two elements in this discussion here
> 1. Guaranteeing bandwidth commitment between CS-SR and non-CS-SR traffic
> as well as among CS-SR policies
> 2. Can we trust routers to do what we want them to do
> For #1 I don’t think we are doing anything radically different than what
> has been done for RSVP-TE or MPLS-TP so far. If we are concerned that the
> mechanisms described in this document alone can not ensure bandwidth
> guarantees or the wording used is giving false expectations, we could
> always “soften” the text (similar to what has been done for RSVP-TE &
> MPLS-TP) that only bandwidth reservations are done but the actually
> resource commitment is out of scope of this document? This would allow
> freedom of choice for implementing the resource commitment related
> mechanisms.
> Having worked on several router implementations I hear you Robert on #2.
> But I think time has changed for the better and routers no longer are
> designed with uncontrolled ingress oversubscription leading to all sort of
> unwanted behavior. Also the proposed performance measurement of
> draft-ietf-spring-stamp-srpm I believe is giving us a good toolset to
> validate the integrity and performance of a CS-SR policy … looking at the
> current text, I agree we may want to adjust the wording a bit around what
> we mean by “failure/fault” (i.e. not only a link down but also issues
> detected by SRPM) and how to react to it (i.e. bring down a CS-SR policy)
> Cheers
> Christian
> On 18.06.2023, at 09:33, Alexander Vainshtein <
>> wrote:
> Robert.
> I do not assume about 100% traffic in the given network is SR.
> I only assume that the operator prevents any traffic paths from using SIDs
> that have been associated with the CS topology and its resources (e.g.,
> steering all non-CS traffic across the default topology), be it
> intentionally or due to some transient condition (FRR, micro-loop avoidance
> etc.).
> Regards,
> Sasha
> *From:* Robert Raszuk <>
> *Sent:* Thursday, June 15, 2023 6:43 PM
> *To:* Alexander Vainshtein <>
> *Cc:* Christian Schmutzer (cschmutz) <>;;
> Dongjie (Jimmy) <>; Stewart Bryant <
> *Subject:* Re: [EXTERNAL] Re: [spring] A technical concern regarding
> draft-schmutzer-spring-cs-sr-policy-00
> Physical links would be shared, but “soft” resources (queues, buffers
> etc.) would not.
> Well ingress or egress interface queue is a physical resource last time I
> checked.
> Leave alone zero view of intra chassis fabric issues and drops.
> Then last but not least you are making a huge assumption that in the
> given network 100% of traffic is SR ..
> Good luck !
> Robert
> *Disclaimer*
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast, a leader in email security and cyber
> resilience. Mimecast integrates email defenses with brand protection,
> security awareness training, web security, compliance and other essential
> capabilities. Mimecast helps protect large and small organizations from
> malicious activity, human error and technology failure; and to lead the
> movement toward building a more resilient world. To find out more, visit
> our website.