Hi Christian, > 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)
That would be super helpful and indeed a significant improvement. - - As far as discussion about router design - we perhaps should not do that on this list. Yes you may be correct in respect to the properly working node (some of them at least). I am worried about bugs and moments of unexpected events handling. Stamp-srpm end to end may detect it though and if this has a auto loop to service state or at least to notify external transit users I am fine. - - In respect to comparison with RSVP-TE to me it looks like this proposal IS suggesting a radically different approach. Even GB-TE was using control plane reservations while your draft is suggesting use of data plane dedicated resources. Clearly it requires a global (to the network scope) controller not only to push SR policy properly, but what is even more important is to push traffic policing to all ingress nodes. Then as we established control plane traffic will use higher precedence queue so any bugs in control plane resulting in excessive traffic could easily result in broken CS service. Hi Sasha, As to the mapping of flows to queuing don't we have an option to use say flow label ? Why would that need to be embedded in adj-SID ? Of course irrespective of how the mapping is carried, resources must be there - blocked and wasted if not in use - even if the entire system works as designed. Thx, R. On Mon, Jun 19, 2023 at 9:33 AM Christian Schmutzer (cschmutz) < cschm...@cisco.com> wrote: > 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> 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> > *Sent:* Thursday, June 15, 2023 6:43 PM > *To:* Alexander Vainshtein <alexander.vainsht...@rbbn.com> > *Cc:* Christian Schmutzer (cschmutz) <cschm...@cisco.com>; spring@ietf.org; > Dongjie (Jimmy) <jie.d...@huawei.com>; Stewart Bryant < > 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
