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

> 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 <daniele.ietf@gmail.com>
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 <robert@raszuk.net> 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 <
>> 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 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 <robert@raszuk.net>
>>> 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 <
>>>> 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 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 <jmh@joelhalpern.com>
>>>>> 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" <rrokui@ciena.com> <rrokui@ciena.com>
>>>>>> *Date: *Thursday, May 18, 2023 at 7:29 AM
>>>>>> *To: *IETF Secretariat <ietf-secretariat-reply@ietf.org>
>>>>>> <ietf-secretariat-reply@ietf.org>,
>>>>>> "draft-schmutzer-spring-cs-sr-policy@ietf.org"
>>>>>> <draft-schmutzer-spring-cs-sr-policy@ietf.org>
>>>>>> <draft-schmutzer-spring-cs-sr-policy@ietf.org>
>>>>>> <draft-schmutzer-spring-cs-sr-policy@ietf.org>,
>>>>>> "spring-chairs@ietf.org" <spring-chairs@ietf.org>
>>>>>> <spring-chairs@ietf.org> <spring-chairs@ietf.org>, "spring@ietf.org"
>>>>>> <spring@ietf.org> <spring@ietf.org> <spring@ietf.org>, "Rokui, Reza"
>>>>>> <rrokui@ciena.com> <rrokui@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> <alias-bounces@ietf.org>
>>>>>> *Resent-To: *<andrew.stone@nokia.com> <andrew.stone@nokia.com>,
>>>>>> <praveen.maheshwari@airtel.com> <praveen.maheshwari@airtel.com>,
>>>>>> <zali@cisco.com> <zali@cisco.com>, <rrokui@ciena.com>
>>>>>> <rrokui@ciena.com>, <cschmutz@cisco.com> <cschmutz@cisco.com>
>>>>>> *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 <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 <ietf-secretariat-reply@ietf.org>
>>>>>> <ietf-secretariat-reply@ietf.org>
>>>>>> *Date: *Tuesday, May 16, 2023 at 10:04 AM
>>>>>> *To: *draft-schmutzer-spring-cs-sr-policy@ietf.org
>>>>>> <draft-schmutzer-spring-cs-sr-policy@ietf.org>
>>>>>> <draft-schmutzer-spring-cs-sr-policy@ietf.org>,
>>>>>> spring-chairs@ietf.org <spring-chairs@ietf.org>
>>>>>> <spring-chairs@ietf.org>, spring@ietf.org <spring@ietf.org>
>>>>>> <spring@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.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
>>>>>> spring@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>
>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> spring@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>
>>>>