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
