Alexander, I understand the differences in label values put on the packets between those approaches. But I was more referring to the aspect resource guarantees … I failed to find any public reference on implementations providing per LSP queuing nor a IETF document specifying it (but maybe I didn’t search hard enough so far).
Christian On 19.06.2023, at 10:21, Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> wrote: Christian, I respectfully disagree with the statement “I don’t think we are doing anything radically different than what has been done for RSVP-TE or MPLS-TP so far”. In both these cases you could be sure that the labels allocated for the LSP by each of the nodes on the paths are not used by any other LSP. Specifically, Section 3.1.3 of RFC 5960 does not point-to-multipoint LSP among the types of LSPs supported by MPLS-TP. But the label that represents an Adj-SID may be included in multiple different SR Policies. What’s more, these policies may be locally computed by various nodes in the SR domain, e.g., as part of TI-PFA repair paths or as part of loop-avoiding paths. The draft proposes mechanisms that are out of scope of SR to guarantee that such policies do not violate the BW guarantees of CS-SR policies, but, IMHO and FWIW, a “pure SR” mechanism preventing such violations is preferable. My 2c, Sasha From: Christian Schmutzer (cschmutz) <cschm...@cisco.com<mailto:cschm...@cisco.com>> Sent: Monday, June 19, 2023 10:33 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: Christian Schmutzer (cschmutz) <cschm...@cisco.com<mailto:cschm...@cisco.com>>; Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>>; 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] [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00 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. 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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
