Hi, I am sensing two elements in this discussion here 1. Guaranteeing bandwidth commitment between CS-SR and non-CS-SR traffic as well as among CS-SR policies 2. Can we trust routers to do what we want them to do
For #1 I don’t think we are doing anything radically different than what has been done for RSVP-TE or MPLS-TP so far. If we are concerned that the mechanisms described in this document alone can not ensure bandwidth guarantees or the wording used is giving false expectations, we could always “soften” the text (similar to what has been done for RSVP-TE & MPLS-TP) that only bandwidth reservations are done but the actually resource commitment is out of scope of this document? This would allow freedom of choice for implementing the resource commitment related mechanisms. Having worked on several router implementations I hear you Robert on #2. But I think time has changed for the better and routers no longer are designed with uncontrolled ingress oversubscription leading to all sort of unwanted behavior. Also the proposed performance measurement of draft-ietf-spring-stamp-srpm I believe is giving us a good toolset to validate the integrity and performance of a CS-SR policy … looking at the current text, I agree we may want to adjust the wording a bit around what we mean by “failure/fault” (i.e. not only a link down but also issues detected by SRPM) and how to react to it (i.e. bring down a CS-SR policy) Cheers Christian On 18.06.2023, at 09:33, Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: Robert. I do not assume about 100% traffic in the given network is SR. I only assume that the operator prevents any traffic paths from using SIDs that have been associated with the CS topology and its resources (e.g., steering all non-CS traffic across the default topology), be it intentionally or due to some transient condition (FRR, micro-loop avoidance etc.). Regards, Sasha From: Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Sent: Thursday, June 15, 2023 6:43 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: Christian Schmutzer (cschmutz) <cschm...@cisco.com<mailto:cschm...@cisco.com>>; spring@ietf.org<mailto:spring@ietf.org>; Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>> Subject: Re: [EXTERNAL] Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00 Physical links would be shared, but “soft” resources (queues, buffers etc.) would not. Well ingress or egress interface queue is a physical resource last time I checked. Leave alone zero view of intra chassis fabric issues and drops. Then last but not least you are making a huge assumption that in the given network 100% of traffic is SR .. Good luck ! Robert Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
