Re: [spring] [**EXTERNAL**] The SPRING WG has placed draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption"

[Joel Halpern <[e-mail]>]

Speaking only as an individual.

I am unable to follow your argument here.

If you are a service provider (any tier, any kind) either you are 
offering some of your customers circuit-like services, or you aren't.  
If you aren't, then this draft does nothing for you, and does you no 
harm, because you are not its target.

If you are offering some customers circuit-like services, you are almost 
certainly offering them such services for a defined amount of bandwidth, 
as otherwise you can't deliver the service with any meaningful 
reliability.  As such, if I have understood the draft properly, this 
draft becomes an additional  tool that you may use to offer such services.

Your argument, retained below, seems to assume that you simply offer the 
service to all customers for all traffic.  Not going to happen.  More 
importantly, not the target assumption space for any of the TE work 
around the IETF.

Yours,

Joel

On 5/24/2023 11:59 AM, Robert Raszuk wrote:
>
> > 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 PM Daniele Ceccarelli 
> <[e-mail]> 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 good as that), but also on the other key requirements
>     that SR-CS can meet (like 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 PM Robert Raszuk <[e-mail]>
>     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 solution.
>
>         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 the 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 PM Daniele Ceccarelli
>         <[e-mail]> 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 traffic (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 remote 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 AM Robert Raszuk
>             <[e-mail]> wrote:
>
>                 Hi Daniele,
>
>                 Could you kindly elaborate on what level of
>                 "guaranteed bandwidth" you expect SR to provide ?
>                 Especially in the context of _circuit_ emulation ?
>
>                 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 everywhere 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) which 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 neither
>                 that this is the case nor that it should be the case.
>
>                 Cheers,
>                 Robert
>
>
>                 On Wed, May 24, 2023 at 9:15 AM Daniele Ceccarelli
>                 <[e-mail]> wrote:
>
>                     Hi Joel,
>
>                     the phrase "circuit style" attracted my attention
>                     and reviewed the draft.
>                     I think segment routing should provide good
>                     support for proper traffic engineering (guaranteed
>                     bandwidth, recovery, path constraints etc.) hence
>                     i believe the draft should be adopted.
>
>                     Cheers,
>                     Daniele
>
>                     On Fri, May 19, 2023 at 5:13 PM Joel Halpern
>                     <[e-mail]> 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" <[e-mail]>
>>                         <mailto:[e-mail]>
>>                         *Date: *Thursday, May 18, 2023 at 7:29 AM
>>                         *To: *IETF Secretariat
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         "[e-mail]"
>>                         <mailto:[e-mail]>
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         "[e-mail]"
>>                         <mailto:[e-mail]>
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         "[e-mail]" <mailto:[e-mail]>
>>                         <[e-mail]> <mailto:[e-mail]>,
>>                         "Rokui, Reza" <[e-mail]>
>>                         <mailto:[e-mail]>
>>                         *Subject: *Re: [**EXTERNAL**] The SPRING WG
>>                         has placed
>>                         draft-schmutzer-spring-cs-sr-policy in state
>>                         "Candidate for WG Adoption"
>>                         *Resent-From: *<[e-mail]>
>>                         <mailto:[e-mail]>
>>                         *Resent-To: *<[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         <[e-mail]> <mailto:[e-mail]>,
>>                         <[e-mail]> <mailto:[e-mail]>,
>>                         <[e-mail]> <mailto:[e-mail]>
>>                         *Resent-Date: *Thursday, May 18, 2023 at 7:29 AM
>>
>>
>>                         	
>>
>>                         You don't often get email from
>>                         [e-mail]. Learn why this is important
>>                         <https://aka.ms/LearnAboutSenderIdentification>
>>
>>                         	
>>
>>                         	
>>
>>                         *CAUTION:*This is an external email. Please
>>                         be very careful when clicking links or
>>                         opening attachments. See the URL nok.it/ext
>>                         <http://nok.it/ext> for additional information.
>>
>>                         Hi,
>>
>>                         As co-author, I support the adoption.
>>
>>                         Cheers,
>>
>>                         Reza
>>
>>                         *From: *IETF Secretariat
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>
>>                         *Date: *Tuesday, May 16, 2023 at 10:04 AM
>>                         *To:
>>                         *[e-mail]
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         [e-mail]
>>                         <[e-mail]>
>>                         <mailto:[e-mail]>,
>>                         [e-mail] <[e-mail]>
>>                         <mailto:[e-mail]>
>>                         *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.org/doc/draft-schmutzer-spring-cs-sr-policy/__;!!OSsGDw!PrF5MLj2VoK47BuWO76oeewImBaGMafe294qNONXqhmq7i57ixXHdL_zK2azlh1DsID1fgczKQ2sDmGvgCW8AZU$
>>                         <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-schmutzer-spring-cs-sr-policy/__;!!OSsGDw!PrF5MLj2VoK47BuWO76oeewImBaGMafe294qNONXqhmq7i57ixXHdL_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
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/spring
>
>                     _______________________________________________
>                     spring mailing list
>                     [e-mail]
>                     https://www.ietf.org/mailman/listinfo/spring
>