> 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.i...@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 <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>
<mailto:rro...@ciena.com>
*Date: *Thursday, May 18, 2023 at 7:29 AM
*To: *IETF Secretariat
<ietf-secretariat-re...@ietf.org>
<mailto:ietf-secretariat-re...@ietf.org>,
"draft-schmutzer-spring-cs-sr-pol...@ietf.org"
<mailto:draft-schmutzer-spring-cs-sr-pol...@ietf.org>
<draft-schmutzer-spring-cs-sr-pol...@ietf.org>
<mailto:draft-schmutzer-spring-cs-sr-pol...@ietf.org>,
"spring-cha...@ietf.org"
<mailto:spring-cha...@ietf.org>
<spring-cha...@ietf.org>
<mailto:spring-cha...@ietf.org>,
"spring@ietf.org" <mailto:spring@ietf.org>
<spring@ietf.org> <mailto:spring@ietf.org>,
"Rokui, Reza" <rro...@ciena.com>
<mailto: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>
<mailto:alias-boun...@ietf.org>
*Resent-To: *<andrew.st...@nokia.com>
<mailto:andrew.st...@nokia.com>,
<praveen.maheshw...@airtel.com>
<mailto:praveen.maheshw...@airtel.com>,
<z...@cisco.com> <mailto:z...@cisco.com>,
<rro...@ciena.com> <mailto:rro...@ciena.com>,
<cschm...@cisco.com> <mailto: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
<http://nok.it/ext> for additional information.
Hi,
As co-author, I support the adoption.
Cheers,
Reza
*From: *IETF Secretariat
<ietf-secretariat-re...@ietf.org>
<mailto: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>
<mailto:draft-schmutzer-spring-cs-sr-pol...@ietf.org>,
spring-cha...@ietf.org
<spring-cha...@ietf.org>
<mailto:spring-cha...@ietf.org>,
spring@ietf.org <spring@ietf.org>
<mailto: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
