From nobody Wed May 24 08:59:37 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 9A2FCC1CDFBF for ; Wed, 24 May 2023 08:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_BLOCKED=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=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 0_CYc1I_IYwt for ; Wed, 24 May 2023 08:59:32 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 74606C1D2587 for ; Wed, 24 May 2023 08:59:32 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3f42d937d2eso9500765e9.2 for ; Wed, 24 May 2023 08:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1684943971; x=1687535971; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=a9pg/zFIf4uXT1IrMKI5TbvOxmau3eyOcW/YAxB2mvA=; b=KyR5TncBAYA+KRziFJTqouPDFDDDr8k8Bc1EAKVYMkjUXlDtfzX2SOz+llWw/RJbCb hJJ0k8vWpcIrqPYDLCDuC3FJdeFkbW25BtYpNR6x8nyUHCAjuQOv3enfpFQhWeEgOtRe iSkgWSxBTEB75RIJjDKcrszd8gNY939NX5x82fiqyKr6U2BnuRM5RSQfCCWt7p7Ur4RB 158YjTGa4quq9Ri/oYr16GqUwPBvbFRvxSzSE9j95SLfKgVSV75nBdiVBR6eyQ4s4Oo6 louINnlfbylQYZ4qIQGrjS55N1fNj/W/f/Hjx55yg6OExpcUI2jGuUsYqy2LOmQkUP5B 82uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684943971; x=1687535971; 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=a9pg/zFIf4uXT1IrMKI5TbvOxmau3eyOcW/YAxB2mvA=; b=W1esCW7d3zngG/D9y+Af8/v5XK0AZzFMViPKTXlmk9Yz2gtkvlVpeVfKXlxGdK4G9y UEv53LbYmEJE7PVvVRSYPBbjtpl9ngIFzSJa5X5d0zIXyn3supYylLe9go8GXKdo3R2A HRUmOcvsW2QCha63YmrU+F39dWTb7S1FlDS7BAl86UtEWagkKzUJCMCn4XextkJU/dxV IkD2LV/wovHrTS6HDEBC2xY659Td4gq7AFuhp+d9YQxhXYEFNvWDwEzTS3Kqa4lDD24+ azkEv+eX52mePH2rIdMxNxSe7I5nxaKCFEp0PH1hApFVYOXcprCAWOPulMFHOES8gA3o h4KQ== X-Gm-Message-State: AC+VfDzippcN3ocDBCIP/1tlFbzPM2gT0QNvmRjThQJ5weNlllVm7lfz RJHK8kN2T14lZNBeTjk9xpaDR6wMYuspMMBFXe8nmQ== X-Google-Smtp-Source: ACHHUZ5jwnOyd0LeaZQIRAE6XEDbqM8dwdxEY2RLAA3srf1IkQRvhgsq6JdxzQjfGGw3Mngw0LasDbcL04P7b4tykqw= X-Received: by 2002:a05:600c:21d8:b0:3f6:580:b07d with SMTP id x24-20020a05600c21d800b003f60580b07dmr219232wmj.21.1684943970597; Wed, 24 May 2023 08:59:30 -0700 (PDT) MIME-Version: 1.0 References: <168424587271.45431.10014516596562429177@ietfa.amsl.com> <1EDBB134-BE9C-4874-9CCC-513BD6D100D4@nokia.com> <8d03ca72-cc5c-6ea4-69b7-102a9b14a078@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Wed, 24 May 2023 17:59:19 +0200 Message-ID: To: Daniele Ceccarelli Cc: Joel Halpern , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d595de05fc729675" Archived-At: Subject: Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption" 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: Wed, 24 May 2023 15:59:36 -0000 --000000000000d595de05fc729675 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > why intense admission control would be a problem in the network ? Imagine you are Tier 1 and not selling access, but doing basic peering with other Tier 1s. What admission control do you configure there ? Equal to your ingress bw ? That's of no use as physics is your ceiling already. Lower than that ? Your peer may not be very happy about it. And as you can guess Internet traffic can and goes to your every egress port so now you need 100% of TE to have some level of control. Partial hot spot TE will not cut it. So good luck with that. Best, R. On Wed, May 24, 2023 at 5:31=E2=80=AFPM Daniele Ceccarelli wrote: > Hi Robert, > > i wouldn't just focus on the guaranteed bandwidth (which in any case has > been working with RSVP-TE and this solution will provide something as goo= d > as that), but also on the other key requirements that SR-CS can meet (lik= e > correctly identified in the draft): > - Predictable E2E TE paths with predictable bidirectional delay > - E2E recovery (i.e. protection and restoration) > - Path integrity > - Data plane remaining up while control plane is down > > These requirements are not less important that the guaranteed bandwidth. > > Moreover, pardon me for asking, why intense admission control would be a > problem in the network ? > > Cheers, > Daniele > > On Wed, May 24, 2023 at 4:35=E2=80=AFPM Robert Raszuk = wrote: > >> > If you want to have a network slice for remote surgery probably you >> > need something more reliable, but otherwise it's a good enough solutio= n. >> >> Spot on ! >> >> And that is my main point. We are reusing notion of completely different >> technology like SONET/SDH containers. >> >> And that is to create only a poor approximation of it assuming very >> strong/tight admission control to the entire network, no multicast >> which can spoil the game at any replication node and with huge pray and >> hope that there is going to be no unplanned and unaccounted traffic in t= he >> underlay. >> >> See till today I still meet folks who believe reading marketing slides >> that RSVP-TE (incl. GB) does actual data plane reservation. >> >> Here we are going step further and claim that SONET/SDH can be sold when >> running over IP :) >> >> Cheers, >> R >> >> >> >> >> >> >> >> >> On Wed, May 24, 2023 at 3:23=E2=80=AFPM Daniele Ceccarelli < >> daniele.ietf@gmail.com> wrote: >> >>> Hi Robert, >>> >>> i had in mind something with the same capabilities/characteristics of >>> RSVP-TE. >>> The same problem has been addressed for decades by operators using LDP >>> for 90% of the traffic and RSVP-TE just for a small portion of the traf= fic >>> (e.g. phone call back in the days). >>> With mix of admission control and proper planning it is possible to >>> achieve decent performances. If you want to have a network slice for re= mote >>> surgery probably you need something more reliable, but otherwise it's a >>> good enough solution. >>> >>> Cheers, >>> Daniele >>> >>> On Wed, May 24, 2023 at 11:27=E2=80=AFAM Robert Raszuk >>> wrote: >>> >>>> Hi Daniele, >>>> >>>> Could you kindly elaborate on what level of "guaranteed bandwidth" you >>>> expect SR to provide ? Especially in the context of _circuit_ emulatio= n ? >>>> >>>> And even if you build the mechanism to account for bandwidth on a per >>>> class of service basis and use controller to push your policies everyw= here >>>> in the network it is still only done in the control plane. >>>> >>>> So how are you going to assure that in your default IGP topology there >>>> is no traffic of a given class (external or internal or accidental) wh= ich >>>> would impact the promise of your emulated circuits ? >>>> >>>> This draft in section 1 makes IMO a very dangerous illusion that you >>>> can accomplish analogy to SONET/SDH in IP networks. I do not agree nei= ther >>>> that this is the case nor that it should be the case. >>>> >>>> Cheers, >>>> Robert >>>> >>>> >>>> On Wed, May 24, 2023 at 9:15=E2=80=AFAM Daniele Ceccarelli < >>>> daniele.ietf@gmail.com> wrote: >>>> >>>>> Hi Joel, >>>>> >>>>> the phrase "circuit style" attracted my attention and reviewed the >>>>> draft. >>>>> I think segment routing should provide good support for proper traffi= c >>>>> engineering (guaranteed bandwidth, recovery, path constraints etc.) h= ence i >>>>> believe the draft should be adopted. >>>>> >>>>> Cheers, >>>>> Daniele >>>>> >>>>> On Fri, May 19, 2023 at 5:13=E2=80=AFPM Joel Halpern >>>>> wrote: >>>>> >>>>>> In case it is not clear to folks, the chairs are particularly >>>>>> itnerested in hearing from folks who are not authors of the document= , but >>>>>> have opinions on whether this is good work for the WG to undertake. >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Joel >>>>>> On 5/19/2023 10:11 AM, Andrew Stone (Nokia) wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> As co-author, also support adoption. >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Andrew >>>>>> >>>>>> >>>>>> >>>>>> *From: *"Rokui, Reza" >>>>>> *Date: *Thursday, May 18, 2023 at 7:29 AM >>>>>> *To: *IETF Secretariat >>>>>> , >>>>>> "draft-schmutzer-spring-cs-sr-policy@ietf.org" >>>>>> >>>>>> >>>>>> , >>>>>> "spring-chairs@ietf.org" >>>>>> , "spring@ietf.org" >>>>>> , "Rokui, Reza" >>>>>> >>>>>> *Subject: *Re: [**EXTERNAL**] The SPRING WG has placed >>>>>> draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adopt= ion" >>>>>> *Resent-From: * >>>>>> *Resent-To: * , >>>>>> , >>>>>> , >>>>>> , >>>>>> *Resent-Date: *Thursday, May 18, 2023 at 7:29 AM >>>>>> >>>>>> >>>>>> >>>>>> You don't often get email from rrokui@ciena.com. Learn why this is >>>>>> important >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *CAUTION:* This is an external email. Please be very careful when >>>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>>> additional information. >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> As co-author, I support the adoption. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Reza >>>>>> >>>>>> >>>>>> >>>>>> *From: *IETF Secretariat >>>>>> >>>>>> *Date: *Tuesday, May 16, 2023 at 10:04 AM >>>>>> *To: *draft-schmutzer-spring-cs-sr-policy@ietf.org >>>>>> >>>>>> , >>>>>> spring-chairs@ietf.org >>>>>> , spring@ietf.org >>>>>> >>>>>> *Subject: *[**EXTERNAL**] The SPRING WG has placed >>>>>> draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adopt= ion" >>>>>> >>>>>> >>>>>> The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in stat= e >>>>>> Candidate for WG Adoption (entered by Joel Halpern) >>>>>> >>>>>> The document is available at >>>>>> >>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-s= chmutzer-spring-cs-sr-policy/__;!!OSsGDw!PrF5MLj2VoK47BuWO76oeewImBaGMafe29= 4qNONXqhmq7i57ixXHdL_zK2azlh1DsID1fgczKQ2sDmGvgCW8AZU$ >>>>>> >>>>>> [datatracker[.]ietf[.]org] >>>>>> >>>>>> Comment: >>>>>> This starts a two week adoption call for the subject draft. Please >>>>>> speak up >>>>>> if you support or object to WG adoption. Two notes: 1) WG adoption >>>>>> is the >>>>>> start of the process. The basic question is whether you agree that >>>>>> the >>>>>> subject is worth the working group time to work on, and whether this >>>>>> represents a good starting point for the work. 2) Please include >>>>>> explanation >>>>>> for your view. Yes or no are not very helpful answers, as this is >>>>>> not a vote >>>>>> but an evaluation of support and concerns. Thank you, Joel (for the >>>>>> WG Chairs) >>>>>> >>>>>> We expect to close this call at the end of May, 2023. >>>>>> >>>>>> _______________________________________________ >>>>>> spring mailing list >>>>>> spring@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>> >>>>> _______________________________________________ >>>>> spring mailing list >>>>> spring@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spring >>>>> >>>> --000000000000d595de05fc729675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>=C2=A0why intense admission contro= l would be a problem in the network ?

Imagine = you are Tier 1 and not selling access, but doing basic peering with other T= ier 1s.=C2=A0

What admission control do you config= ure there ?=C2=A0

Equal to your ingress bw ? That&= #39;s of no use as=C2=A0physics is your=C2=A0ceiling already.=C2=A0

Lower than that ? Your peer may not be very happy about i= t.=C2=A0

And as you can guess Internet traffic can= and goes to your every egress port so now you need 100% of TE to have some= level of control. Partial hot spot=C2=A0TE will not cut it.=C2=A0

So good luck with that.=C2=A0

Bes= t,
R.
=C2=A0

On Wed, May 24, 2023 at 5:31=E2=80=AFPM Dan= iele Ceccarelli <daniele.ietf@= gmail.com> wrote:
Hi Robert,

i wouldn't ju= st focus on the guaranteed bandwidth=C2=A0(which in any case has been worki= ng with RSVP-TE and this solution will provide something as good as that), = but also on the other key requirements that SR-CS can meet (like correctly = identified in the draft):=C2=A0
- Predictable E2E TE paths with p= redictable bidirectional delay
- E2E recovery (i.e. protection an= d restoration)
- Path integrity
- Data plane remaining = up while control plane is down

These requirements = are not less important that the guaranteed=C2=A0bandwidth.=C2=A0
=
Moreover, pardon me for asking, why intense admission contro= l would be a problem in the network ?

Cheers,
Daniele=C2=A0=C2=A0

On Wed, May 24, 2023 at 4:35=E2=80=AFPM Robe= rt Raszuk <robert= @raszuk.net> wrote:
> If you want to have a network slice for re= mote surgery probably you=C2=A0
> need something more reliable, but = otherwise it's a good enough solution.

Spo= t on !=C2=A0

And that is my main point. We are reu= sing notion of completely different technology like SONET/SDH containers.= =C2=A0

And that is to create only a poor approxima= tion of it assuming very strong/tight admission control to the entire netwo= rk, no multicast which=C2=A0can spoil the game at any replication node and = with huge pray and hope that there is going to be no unplanned and unaccoun= ted traffic in the underlay.=C2=A0

See till today = I still meet folks who believe reading marketing slides that RSVP-TE (incl.= GB) does actual data plane reservation.=C2=A0

Her= e we are going step further and claim that SONET/SDH can be sold when runni= ng over IP :)=C2=A0

Cheers,
R
=




=


On Wed, May 24, 2023 at 3:23=E2=80=AFPM Daniele Ce= ccarelli <da= niele.ietf@gmail.com> wrote:
Hi Robert,

i had in= mind something with the same capabilities/characteristics of RSVP-TE.=C2= =A0
The same problem has been addressed for decades by operators = using LDP for 90% of the traffic and RSVP-TE just for a small portion of th= e traffic (e.g. phone call back in the days).=C2=A0
With=C2=A0mix= of admission control and proper planning it is possible to achieve decent = performances. If you want to have a network slice for remote surgery probab= ly you need something more reliable, but otherwise it's a good enough s= olution.

Cheers,
Daniele=C2=A0=C2=A0

On We= d, May 24, 2023 at 11:27=E2=80=AFAM Robert Raszuk <robert@raszuk.net> wrote:
Hi Dani= ele,

Could you kindly elaborate on what level of "g= uaranteed bandwidth" you expect SR to provide ? Especially in the cont= ext=C2=A0of _circuit_ emulation ?

And even if you = build the mechanism to account for bandwidth=C2=A0on a per class of service= basis and=C2=A0use controller to=C2=A0push your policies everywhere in the= =C2=A0network it is still only=C2=A0done in the control plane.=C2=A0
<= div>
So how are you going to assure that in your default IGP = topology there is no traffic of a given class (external or internal or acci= dental) which would impact the promise of your emulated circuits ?=C2=A0

This draft in section 1 makes IMO a very dangerous= =C2=A0illusion that you can accomplish analogy to=C2=A0SONET/SDH in IP netw= orks. I do not agree neither that this is the case nor that it should be th= e case.=C2=A0

Cheers,
Robert
<= br>

On Wed, May 24, 2023 at 9:15=E2=80=AFAM Daniele Ceccarelli <daniele.ietf@gmail= .com> wrote:
Hi Joel,

the phrase "circuit s= tyle" attracted my attention and reviewed the draft.=C2=A0
I= think segment routing should provide good support for proper traffic engin= eering (guaranteed bandwidth, recovery, path constraints etc.) hence i beli= eve the draft should be adopted.

Cheers,
Daniele=C2=A0=C2=A0

On Fri, May 19, 2023 at 5:13=E2=80=AFPM Joel Halp= ern <jmh@joelha= lpern.com> wrote:
=20 =20 =20

In case it is not clear to folks, the chairs are particularly itnerested in hearing from folks who are not authors of the document, but have opinions on whether this is good work for the WG to undertake.

Thank you,

Joel

On 5/19/2023 10:11 AM, Andrew Stone (Nokia) wrote:
=20 =20 =20

Hi all,

=C2=A0=

As co-author, also support adoption.

=C2=A0=

Thanks=

Andrew=

=C2=A0=

From: "Rokui= , Reza" <rro= kui@ciena.com>
Date: Thursday, May 18, 2023 at 7:29 AM
To: IETF Secretariat <ietf-secretariat-reply@ietf.org>, "draft-schmutzer-spring-cs-sr-policy@ietf.org&quo= t; <draft-schmutzer-spring-cs-sr-policy@ietf.org>, &= quot;spring-chairs@ietf.org" <spring-chairs@ietf.org>, "sp= ring@ietf.org" <spring@ietf.org>, "Rokui, Reza" <rro= kui@ciena.com>
Subject: Re: [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"
Resent-From: <alias-bounces@ietf.org>
Resent-To: <andrew.stone@nokia.com>, <praveen.maheshwari@airtel.com>, <zali@= cisco.com>, &l= t;rrokui@ciena.com>, <c= schmutz@cisco.com>
Resent-Date: Thursday, May 18, 2023 at 7:29 AM<= u>

=C2= =A0

You don't often get email from rrokui@ciena.com. Learn why this is important

=C2=A0

=C2=A0<= /p>

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

=C2=A0

Hi,

= =C2=A0

As co-author, I support the adoption.

= =C2=A0

Cheers,

Reza

= =C2=A0

From: IET= F Secretariat <ietf-secretariat-reply@ietf.org>
Date: Tuesday, May 16, 2023 at 10:04 AM
To: draft-schmutzer-spring-cs-sr-policy@iet= f.org <draft-schmutzer-spring-cs-sr-policy@ietf.org&g= t;, spring-chairs@ietf.org <spring-chairs@ietf.org>, spri= ng@ietf.org <sp= ring@ietf.org>
Subject: [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"


The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state
Candidate for WG Adoption (entered by Joel Halpern)

The document is available at
https://urldefense.com/v3/__https://datatracker.ietf.or= g/doc/draft-schmutzer-spring-cs-sr-policy/__;!!OSsGDw!PrF5MLj2VoK47BuWO76oe= ewImBaGMafe294qNONXqhmq7i57ixXHdL_zK2azlh1DsID1fgczKQ2sDmGvgCW8AZU$ [datatracker[.]ietf[.]org]

Comment:
This starts a two week adoption call for the subject draft.=C2=A0 Please speak up
if you support or object to WG adoption.=C2=A0 Two notes: 1) WG adoption is the
start of the process.=C2=A0 The basic question is whether you agree that the
subject is worth the working group time to work on, and whether this
represents a good starting point for the work. 2) Please include explanation
for your view.=C2=A0 Yes or no are not very helpful answers, as this is not a vote
but an evaluation of support and concerns. Thank you, Joel (for the WG Chairs)

We expect to close this call at the end of May, 2023.<= /u>

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000d595de05fc729675--