From nobody Mon Jun 19 03:10:49 2023 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF11C1524B3 for ; Mon, 19 Jun 2023 03:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5CNpR94uALf for ; Mon, 19 Jun 2023 03:10:44 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id F361CC14CEF9 for ; Mon, 19 Jun 2023 03:10:43 -0700 (PDT) Received: by mail-ed1-x52b.google.com 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; d=raszuk.net; 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; d=1e100.net; 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: <664D8681-C2DD-4163-B6CD-7BC8E785805D@cisco.com> <598b3d2ef59b4bb5978f05d225f11925@huawei.com> <54EFE818-3243-4FE0-854E-11866145C79E@cisco.com> <5D7BCEE9-BE8E-42DF-B15A-3270C0678DE0@cisco.com> <71cf2d9e791645f4b84ea032f134e801@huawei.com> <965B838D-A3BA-45CF-AAE1-C98CCCA1717E@cisco.com> <2E6802E6-2E2C-48CF-A7AD-C8F47EAAC3FB@cisco.com> In-Reply-To: <2E6802E6-2E2C-48CF-A7AD-C8F47EAAC3FB@cisco.com> From: Robert Raszuk Date: Mon, 19 Jun 2023 12:10:30 +0200 Message-ID: To: "Christian Schmutzer (cschmutz)" Cc: Alexander Vainshtein , "spring@ietf.org" , "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-BeenThere: spring@ietf.org 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 --000000000000434f5c05fe78bfb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christian, > I agree we may want to adjust the wording a bit around what we mean by =E2=80=9Cfailure/fault=E2=80=9D (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 designed. Thx, R. On Mon, Jun 19, 2023 at 9:33=E2=80=AFAM Christian Schmutzer (cschmutz) < cschmutz@cisco.com> 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=E2=80=99t think we are doing anything radically different th= an 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 =E2=80=9Csoften=E2=80=9D the text (similar to what has been done f= or 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 o= f > 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 =E2=80=A6 lookin= g at the > current text, I agree we may want to adjust the wording a bit around what > we mean by =E2=80=9Cfailure/fault=E2=80=9D (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 < > Alexander.Vainshtein@rbbn.com> 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 SID= s > 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 avoidan= ce > etc.). > > Regards, > Sasha > > *From:* Robert Raszuk > *Sent:* Thursday, June 15, 2023 6:43 PM > *To:* Alexander Vainshtein > *Cc:* Christian Schmutzer (cschmutz) ; spring@ietf.or= g; > Dongjie (Jimmy) ; Stewart Bryant < > stewart.bryant@gmail.com> > *Subject:* Re: [EXTERNAL] Re: [spring] A technical concern regarding > draft-schmutzer-spring-cs-sr-policy-00 > > > > Physical links would be shared, but =E2=80=9Csoft=E2=80=9D resources (que= ues, 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 m= ay > 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. > > > --000000000000434f5c05fe78bfb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Christian,=C2=A0

> I a= gree we may want to adjust the wording a bit around what we mean by =E2=80= =9Cfailure/fault=E2=80=9D (i.e. not only a link=C2=A0
> down but als= o 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.=C2=A0

- -=C2=A0
<= div>
As far as discussion about router design - we perhaps sh= ould not do that on this list. Yes you=C2=A0may be correct in respect to th= e properly working node (some of them at least). I am worried about bugs an= d moments of unexpected events handling. Stamp-srpm end to end may detect i= t though and if this has a auto loop to service state or at least to notify= external transit users I am fine.=C2=A0

- -=C2=A0=

In respect to comparison with RSVP-TE to me it lo= oks like this proposal IS suggesting a radically different approach. Even G= B-TE was using control plane reservations while your draft is suggesting us= e of data plane dedicated resources.=C2=A0

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 polici= ng to all ingress nodes. Then as we established control plane traffic will = use higher precedence queue so any bugs in control plane resulting in exces= sive traffic could easily result in broken CS service.=C2=A0

=
Hi Sasha,

As to the mapping of flow= s 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 map= ping is carried, resources must be there - blocked and wasted if not in use= - even if the entire system works as designed.=C2=A0

<= div>Thx,
R.


On Mon, Jun 19, 2023 at 9:33=E2= =80=AFAM Christian Schmutzer (cschmutz) <cschmutz@cisco.com> wrote:
Hi,

I am sensing two elements in this discussion here
1. Guaranteeing bandwidth commitment between CS-SR and non-CS-SR traff= ic as well as among CS-SR policies
2. Can we trust routers to do what we want them to do

For #1 I don=E2=80=99t 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 bandwi= dth guarantees or the wording used is giving false expectations, we could always =E2=80=9Csoften=E2=80=9D the= text (similar to what has been done for RSVP-TE & MPLS-TP) that only b= andwidth 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 de= signed with uncontrolled ingress oversubscription leading to all sort of un= wanted 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 =E2=80=A6 looking at the current text, I agree we may want to= adjust the wording a bit around what we mean by =E2=80=9Cfailure/fault=E2=80=9D (i.e. not only a link down but als= o issues detected by SRPM) and how to react to it (i.e. bring down a CS-SR = policy)

Cheers
Christian=C2=A0

On 18.06.2023, at 09:33, Alexander Vainshtein <Alexander.Vainshtein@rbbn.co= m> wrote:

Robert.
I do not assume about 100% traffic in the given network is SR.
=C2=A0
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., ste= ering all non-CS traffic across the default topology), be it intentionally = or due to some transient condition (FRR, micro-loop avoidance etc.).
=C2=A0
Regards,
Sasha
=C2=A0
From:=C2=A0Robert Raszuk <robert@raszuk.net>=C2=A0 Sent:=C2=A0Thursday, June 15, 2023 6:43 PM
To:=C2=A0Alexander Vainshtein <Alexander.Vainshtein@rbbn.com= >
Cc:=C2=A0Christian Schmutzer (cschmutz) <cschmutz@cisco.com>;=C2=A0spring= @ietf.org; Dongjie (Jimmy) <jie.dong@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>
Subject:=C2=A0Re: [EXTERNAL] Re: [spring] A technical c= oncern regarding draft-schmutzer-spring-cs-sr-policy-00
=C2=A0
=C2=A0
Physical links would be shared, but =E2=80=9Csoft=E2=80=9D resources (queue= s, buffers etc.) would not.
=C2=A0
Well ingress or egress interface queue is a physical resource last time I c= hecked.=C2=A0
=C2=A0
Leave alone zero view of intra chassis=C2=A0fabric issues and drops.=C2=A0<= u>
=C2=A0
Then last=C2=A0but not least you are making a huge assumption=C2=A0that in = the given=C2=A0network 100% of traffic is SR ..=C2=A0
=C2=A0
Good luck !
Robert
=C2=A0


Disclaimer

The information contained in this communication from the sender is confiden= tial. 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 a= ny disclosure, copying, distribution or taking action in relation of the contents of this information is strict= ly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been auto= matically archived by Mimecast, a leader in email security and cyber resili= ence. Mimecast integrates email defenses with brand protection, security aw= areness 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.


--000000000000434f5c05fe78bfb3--