> 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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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" <[email protected]> <[email protected]> >>>>>> *Date: *Thursday, May 18, 2023 at 7:29 AM >>>>>> *To: *IETF Secretariat <[email protected]> >>>>>> <[email protected]>, >>>>>> "[email protected]" >>>>>> <[email protected]> >>>>>> <[email protected]> >>>>>> <[email protected]>, >>>>>> "[email protected]" <[email protected]> >>>>>> <[email protected]> <[email protected]>, "[email protected]" >>>>>> <[email protected]> <[email protected]> <[email protected]>, "Rokui, Reza" >>>>>> <[email protected]> <[email protected]> >>>>>> *Subject: *Re: [**EXTERNAL**] The SPRING WG has placed >>>>>> draft-schmutzer-spring-cs-sr-policy in state "Candidate for WG Adoption" >>>>>> *Resent-From: *<[email protected]> <[email protected]> >>>>>> *Resent-To: *<[email protected]> <[email protected]>, >>>>>> <[email protected]> <[email protected]>, >>>>>> <[email protected]> <[email protected]>, <[email protected]> >>>>>> <[email protected]>, <[email protected]> <[email protected]> >>>>>> *Resent-Date: *Thursday, May 18, 2023 at 7:29 AM >>>>>> >>>>>> >>>>>> >>>>>> You don't often get email from [email protected]. 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 <[email protected]> >>>>>> <[email protected]> >>>>>> *Date: *Tuesday, May 16, 2023 at 10:04 AM >>>>>> *To: *[email protected] >>>>>> <[email protected]> >>>>>> <[email protected]>, >>>>>> [email protected] <[email protected]> >>>>>> <[email protected]>, [email protected] <[email protected]> >>>>>> <[email protected]> >>>>>> *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 >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>> >>>>> _______________________________________________ >>>>> spring mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/spring >>>>> >>>>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
