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

[Robert Raszuk <[e-mail]>]

Hi Joel,

> Your argument, retained below, seems to assume that you simply offer
> the service to all customers for all traffic.

Nope, not at all.

My point is that to offer the service in reality of operational networks as
described in the draft is hard if not impossible.

What you can offer is the illusion of circuit switching paradigm. Sure that
may be good enough for some. After all David Copperfield is a celebrity and
a rich man.

Cheers,
Robert


On Wed, May 24, 2023 at 6:07 PM Joel Halpern <[e-mail]> wrote:

> 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]> <[e-mail]>
>>>>>>> *Date: *Thursday, May 18, 2023 at 7:29 AM
>>>>>>> *To: *IETF Secretariat <[e-mail]>
>>>>>>> <[e-mail]>,
>>>>>>> "[e-mail]"
>>>>>>> <[e-mail]>
>>>>>>> <[e-mail]>
>>>>>>> <[e-mail]>,
>>>>>>> "[e-mail]" <[e-mail]>
>>>>>>> <[e-mail]> <[e-mail]>, "[e-mail]"
>>>>>>> <[e-mail]> <[e-mail]> <[e-mail]>, "Rokui,
>>>>>>> Reza" <[e-mail]> <[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]> <[e-mail]>
>>>>>>> *Resent-To: *<[e-mail]> <[e-mail]>,
>>>>>>> <[e-mail]> <[e-mail]>,
>>>>>>> <[e-mail]> <[e-mail]>, <[e-mail]>
>>>>>>> <[e-mail]>, <[e-mail]> <[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 for
>>>>>>> additional information.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As co-author, I support the adoption.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Reza
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From: *IETF Secretariat <[e-mail]>
>>>>>>> <[e-mail]>
>>>>>>> *Date: *Tuesday, May 16, 2023 at 10:04 AM
>>>>>>> *To: *[e-mail]
>>>>>>> <[e-mail]>
>>>>>>> <[e-mail]>,
>>>>>>> [e-mail] <[e-mail]>
>>>>>>> <[e-mail]>, [e-mail] <[e-mail]>
>>>>>>> <[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
>>>>>>
>>>>>