Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

["Christian Schmutzer (cschmutz)" <[e-mail]>]

Hi Dongjie,

As long as traffic of a CS-SR policy is within the “bandwidth contract” established during the CS-SR policy instantiation (or last update) I don’t see any issue with resource competition.

Cases where a CS-SR policy is “out of contract” we tried to address so far with those two sentences
https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-policy-01#section-3.1-6
https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-policy-01#section-7.3-3

Packet bursts of course are a different story, but do equally apply to RSVP-TE and MPLS-TP/GMPLS and I don’t think have been explicitely discussed in respective documents there? Having said that we can think of expanding on https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-policy-01#section-3.1-3.1 and discuss how policer burst values and network interface queue limits can be tuned to accomodate for bursts.

I would propose to incorporate potential changes in the future, or do you see final text for these topics gating WG adoption call?

regards
Christian

On 28.04.2023, at 10:58, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Christian,

Thanks for updating the draft and reminding me about my comments on the previous version.

I’ve gone through the text in section 3.1, and think it describes useful approaches for providing bandwidth guarantee to CS policies. While I have one remaining question:

My reading is that the bandwidth is allocated to all the CS SR policies (either via a physical link, a logical link or a queue), this could ensure the total bandwidth of all the CS policies are guaranteed. While since different CS policies share the same set of resources, is it possible that in some cases the services carried by the CS policies may compete with each other for that set of shared resources (e.g. due to burst in some CS services)? If so, do you want to mention this in the draft, and may also provide some approaches to avoid or mitigate this effect.

Best regards,
Jie

From: Christian Schmutzer (cschmutz) [mailto:[e-mail]]
Sent: Thursday, April 27, 2023 6:37 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Dear WG,

As we are preparing for WG adoption call, could you please let us know if the concerns have been addressed?

Thanks in advance
Christian


On 15.02.2023, at 19:24, Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jie and Sasha,

We recently published a new version of the draft trying to address your concerns on assumptions and procedures for guaranteeing bandwidth for CS-SR policies in the following section https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-policy-01#name-ensuring-bandwidth-guarante

Probably not perfect but wondering what you think? Further input and discussion is welcome !

regards
Christian


On 26.07.2022, at 22:23, Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Sasha and Christian,

To my understanding the potential services of CS-SR require some level of performance guarantee, which means the traffic needs to be distinguished from other traffic in the network and be treated separately. As discussed in this thread, one approach would be to steer the traffic to a separate queue or a separate set of resources.

I agree with Sasha that requesting a dedicated traffic class may not be easy. Sasha gave a mechanism based on the coexistence of MPLS-TP and SR-MPLS. An alternative to that would be to use a separate set of SR SIDs for the CS-SR, and associate such set of SR SIDs with a separate set of network resources (e.g. sub-interfaces or queue). That could be achieved by using resource-aware SIDs as defined in draft-ietf-spring-resource-aware-segments.

Best regards,
Jie

From: Pce [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, July 26, 2022 3:48 PM
To: Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Rotem Cohen <[e-mail]<mailto:[e-mail]>>; Nitsan Dolev <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Pce] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Christian,
Lots of thanks for your prompt response to my concerns about the SR-CS Policy draft.
Unfortunately I will not be able to attend the SPRING session later today (even remotely).

Regarding your explanation, I believe that the key point is the sentence “everything not running over CS-SR has no bandwidth guarantee, is of lower priority and can undergo packet drops during DiffServ PHB processing”.

This statement is an assumption that:

  1.  Is critical for SR-CS to deliver its promise
  2.  Is actually a requirement (and quite a strong one) for the operator of the SR network to enforce strict separation of traffic that uses SR-CS and all the rest of traffic to different traffic classes. Implementing this requirement in a live operational network may be quite a non-trivial operation
  3.  Unless I am mistaken, is not explicitly stated in the current version of the draft (or in any of the associated drafts),


At the same time, I agree that, if this assumption holds, SR-CS can deliver its promise.

Please notice also that in the  case of MPLS networks the same results can be achieved with MPLS-TP running as “ships in the night” with SR-MPLS but without the overhead of deep label stacks required by SR-CS. This approach has been developed and deployed for quite some time now. IMHO it would be interesting to compare these two approaches.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 25, 2022 6:45 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Cc: Christian Schmutzer (cschmutz) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Rotem Cohen <[e-mail]<mailto:[e-mail]>>; Nitsan Dolev <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00

Hi Sasha,

Many thanks for reviewing draft-schmutzer-pce-cs-sr-policy (draft-schmutzer-spring-cs-sr-policy) and sharing your input / concerns. Let me try to address them.

CS-SR policies don’t require additional unprotected adj-SIDs. The unprotected adj-SID part of the two adj-SIDs you mentioned typically being present per link in a network does suffice.

Further the draft does not assume bandwidth guarantees for those unprotected adj-SIDs. Bandwidth is managed by the PCE at a link level and bandwidth guarantees are achieved by ensuring that the total amount of bandwidth requested by all candidate-paths going via a link is kept below the reservable maximum bandwidth defined.

To ensure a link is never congested by just CS-SR traffic, end-to-end path-protection and restoration is used. This ensures traffic does only flow along a path (working, protect or restore) for which bandwidth admission control has been done during path establishment.

You are correct, mechanisms such as TI-LFA may lead to congestion, but the assumption is that everything not running over CS-SR, has no bandwidth guarantee, is of lower priority and can undergo packet drops during DiffServ PHB processing.

There are many ways to fulfil those PHB processing requirements. One way is to mark CS-SR policy traffic with a unique EXP/DSCP and map it into a dedicated priority queue. CS-SR traffic may share a EXP/DSCP and/or queue with other traffic if the operate is certain that the queue will never be congested (i.e. the non CS-SR traffic is important but has very low volume and the queue’s bandwidth is over-provisioned to be enough for CS-SR and non CS-SR traffic together)

I will take the action on thinking about how some more / better text could be added to the draft without being to specific to limit deployment choices.

Hopefully the above does provide a bit more clarity. I am happy to discuss more, fyi I will present the draft in the SPRING WG session, but will be attending IETF114 online only.

Regards
Christian


On 24.07.2022, at 19:02, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,
I would like to clarify that, from my POV, my technical concerns about draft-schmutzer-pce-sr-cs-routing-policies<https://clicktime.symantec.com/15t5ZrUvivrzY8sT1ijxH?h=oARDBH4W-5ffeLBR147jEqYwP_rR1J1Akb38blbagcY=&u=https://datatracker.ietf.org/doc/html/draft-schmutzer-pce-cs-sr-policy-02> presented in my email dated 11-Jul-22<https://clicktime.symantec.com/15t5eggDBYYax5hNZH96u?h=SF8xdDZrlCfJegvv79QramWDaqy05gg48KBreJtvyuM=&u=https://mailarchive.ietf.org/arch/msg/spring/ctrAx6JFaNwLhMCQB5QUdBCR7B8/> fully apply to this draft.

Specifically, the authors do not define any mechanisms that would prevent possible usage of unprotected Adj-SIDs used in the configuration of the candidate paths of CR-CS policies from being also used by such well-known and widely deployed mechanisms as TI-LFA and Segment Routing Microloop Avoidance.  As a consequence, the “strict BW guarantees”  that are expected of SR-CS policies would be violated every time one of these mechanisms would result in some “regular” traffic being sent via the paths defined by such mechanisms.

Even if such mechanisms were defined in a future version of  draft-schmutzer-spring-cs-sr-policy, a retrofit of existing implementations of TI-LFA and/or SR Microloop Avoidance would be required.

I understand the motivation for CR-SC Policies, but I strongly suspect that SR cannot be used as a replacement for MPLS-TP when it comes to BW guarantees.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.