IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Thu, 15 June 2023 15:35 UTC

Return-Path: <robert@raszuk.net>
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 6E0CDC151082 for <spring@ietfa.amsl.com>; Thu, 15 Jun 2023 08:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=ham 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 V5Y3amn1GDMF for <spring@ietfa.amsl.com>; Thu, 15 Jun 2023 08:35:25 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 B1E65C15199A for <spring@ietf.org>; Thu, 15 Jun 2023 08:33:58 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-4f845060481so1015729e87.3 for <spring@ietf.org>; Thu, 15 Jun 2023 08:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1686843236; x=1689435236; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=F1xxbeJ37CkG8VM3ayuniUEaHWYbwfVWDVdZbNwN+1s=; b=TG6s5MMfIgZlWcsRh6NnsDGPcI6rWCvZM7XBbgGHU2vpnFap5beppA5q0gYWTbRg36 oLH58915uuIH/gdwWAsCz7Ya2ifLLJ6GY9z0GVjDHImuXPBtALriKgiJqL+797J3RTNn bv7WPNRH69sCrkpWJxTdpHSqvXFRW5YL0zHfv1fdvua0gfzlFlB8gG7PGawzvFr/SEOL yIxCbZGrU1MS0Yi3e/xldHCXYbAqHGOLxE3/B8RwYlSUdH2iELj4W4E2vvGfkd0kQw0R dvYMkjwcjRXfUArXxbTtpwE1+m+fAsEad77RvZ/SnZ5wqKCFpy1v5LTSqPW+vSAYpUgo VQfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686843236; x=1689435236; 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=F1xxbeJ37CkG8VM3ayuniUEaHWYbwfVWDVdZbNwN+1s=; b=cGNeADF0XLnJuorgeF244fBZsEcYWlJV/ePDhwbTstrZhbfkC3GiN9deSh4PAL9uh1 VmSGjaG5mdx++P8z8gxgyr+HwX9cgQwpHQB8ZrYcjR2ep6E85t+SIqI0gEO0nP7aTvES hsP0eqOaozvHs/TmbXF3V+ROwGJhfBMX9+ZZRBzPOKaXJtDhd9r5oBWpaEo5JvRUBl/d 2KAvFD8TndyI7L4XCgL6lSufWMs7Ao6DLXLGQ1uM2/1DRbE6tBA2tD55ceghOnSoiMit TMki5UN/FQRwt11+NFUP5etahMzwFL9zOyZlN91IC+6OHVaWRxThr+R8g6S5mLqh2per u42g==
X-Gm-Message-State: AC+VfDyJAdOh1940NCDSHDKAv7tuW7E1pXj8GF8YF6gZGEKoCHrDqcwZ New4tNMH66pUmRElA696Xlyh1NKzNpuU7oLMsJvy4Q==
X-Google-Smtp-Source: ACHHUZ4hqhuWovOcgDCnLaVbOuFoVuR6VoLY9d25CnU21UnRS1KLqDH3scXGZuCf69GjBgNi6Gg/1CBUfM75GZgh1yU=
X-Received: by 2002:a2e:b0d2:0:b0:2b1:afe6:896b with SMTP id g18-20020a2eb0d2000000b002b1afe6896bmr9278493ljl.32.1686843236491; Thu, 15 Jun 2023 08:33:56 -0700 (PDT)
MIME-Version: 1.0
References: <PH0PR03MB63007D82CD11836C4BE5B13AF6929@PH0PR03MB6300.namprd03.prod.outlook.com> <664D8681-C2DD-4163-B6CD-7BC8E785805D@cisco.com> <PH0PR03MB630015DFF140BC9D1405D311F6949@PH0PR03MB6300.namprd03.prod.outlook.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> <PH0PR03MB63001BE463F4AA237C8F9AC8F65BA@PH0PR03MB6300.namprd03.prod.outlook.com> <CAOj+MMF3=LQ3j+mU8_tLPy1mFOOvTX80_HFqekq84-xz15MCqg@mail.gmail.com> <PH0PR03MB6300DBEB8E0282A12AA59C40F65BA@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB6300DBEB8E0282A12AA59C40F65BA@PH0PR03MB6300.namprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Jun 2023 17:33:45 +0200
Message-ID: <CAOj+MMFMTtTw9RZH9BjerNDX2qsHtyh0Ts6SZpXg4-GNFSUMZQ@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>, "spring@ietf.org" <spring@ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e73b1905fe2ccb22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/CeDOdYr29mSVVNj_5MZE161zOr8>
Subject: Re: [spring] [EXTERNAL] Re: 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\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jun 2023 15:35:29 -0000

Hi,


> I have probably did not say it explicitly, but the default topology would
> use its own resources – and experience its own problems, strictly
> orthogonal to whatever happens in the dedicated CS topology.
>
> IMHO and FWIW this could be treated as a possible approach for
> implementing the (in)famous “network slicing”.
>

Isn't the default topo an underlay for any custom topology ? You seems to
think that default topology can function "in parallel", but this is not how
I understand it.


> As for “circuit switching over connectionless paradigm” – well, TDM
> circuit emulation has been standardized by the IETF years ago, has been
> quite widely deployed, and, AFAIK, is still growing as more operators try
> to scrap their SDH networks.
>

Yeh happened to be for a number of years on a customer side using such an
"invention" and my resistance to the subject draft is coming from this
(bad) experience.

Sure it is cool for operators ... not so for customers.

I even wrote a draft one time trying to detect the hidden problems by such
innovations:

https://www.ietf.org/archive/id/draft-turaga-mpls-test-labels-01.txt

Thx,
R.

>

v2.23.0 | Report a Bug | By Email