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 <rob...@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.i...@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 <rob...@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.i...@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 <j...@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" <rro...@ciena.com> <rro...@ciena.com> >>>>> *Date: *Thursday, May 18, 2023 at 7:29 AM >>>>> *To: *IETF Secretariat <ietf-secretariat-re...@ietf.org> >>>>> <ietf-secretariat-re...@ietf.org>, >>>>> "draft-schmutzer-spring-cs-sr-pol...@ietf.org" >>>>> <draft-schmutzer-spring-cs-sr-pol...@ietf.org> >>>>> <draft-schmutzer-spring-cs-sr-pol...@ietf.org> >>>>> <draft-schmutzer-spring-cs-sr-pol...@ietf.org>, >>>>> "spring-cha...@ietf.org" <spring-cha...@ietf.org> >>>>> <spring-cha...@ietf.org> <spring-cha...@ietf.org>, "spring@ietf.org" >>>>> <spring@ietf.org> <spring@ietf.org> <spring@ietf.org>, "Rokui, Reza" >>>>> <rro...@ciena.com> <rro...@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-boun...@ietf.org> <alias-boun...@ietf.org> >>>>> *Resent-To: *<andrew.st...@nokia.com> <andrew.st...@nokia.com>, >>>>> <praveen.maheshw...@airtel.com> <praveen.maheshw...@airtel.com>, >>>>> <z...@cisco.com> <z...@cisco.com>, <rro...@ciena.com> >>>>> <rro...@ciena.com>, <cschm...@cisco.com> <cschm...@cisco.com> >>>>> *Resent-Date: *Thursday, May 18, 2023 at 7:29 AM >>>>> >>>>> >>>>> >>>>> You don't often get email from rro...@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-re...@ietf.org> >>>>> <ietf-secretariat-re...@ietf.org> >>>>> *Date: *Tuesday, May 16, 2023 at 10:04 AM >>>>> *To: *draft-schmutzer-spring-cs-sr-pol...@ietf.org >>>>> <draft-schmutzer-spring-cs-sr-pol...@ietf.org> >>>>> <draft-schmutzer-spring-cs-sr-pol...@ietf.org>, spring-cha...@ietf.org >>>>> <spring-cha...@ietf.org> <spring-cha...@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 >>>> >>>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
