From nobody Thu Jun 15 07:52:59 2023 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BBAC151998 for ; Thu, 15 Jun 2023 07:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_VISITOURSITE=2, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-aj5cdENVYu for ; Thu, 15 Jun 2023 07:52:50 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF503C151074 for ; Thu, 15 Jun 2023 07:52:26 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-51a21185130so1383021a12.0 for ; Thu, 15 Jun 2023 07:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1686840745; x=1689432745; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vC56/3VsbCIdJJIq9EZ+Bjk1hpIqdKCFn+qG1OsuBOo=; b=VXPSqd5BY+qGzbSbxXgmqoA3ejVv2eqN60GRFIj+QXjM7OTem4KS6HgSKkf6LgcbsE 7EOthmLxeYnpk4ZIes0bqHBSO7tndZSmmLL+qA3CzAJuvTY+RxiY5IkaMi3+ImZWd8ck IqwFe4/e3yrOywiJ9pBx/xSuN/fm31RJjA0dokla9DFUW1sMS2YB0xn+IEAVNWmNLGuh hEubQgTCLiRIzI1+Fbr8uh/RcR4at83Y/olx5REzy0AWOIZrZBIbyfXlugemWQHRyIpZ nlLVqVKsI64B8GNdItgAX7OHeAYqP2AiS8NUQ4AdIXgSUHdLWBRqCC8Qs0FaX5g0hC8v C38A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686840745; x=1689432745; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vC56/3VsbCIdJJIq9EZ+Bjk1hpIqdKCFn+qG1OsuBOo=; b=K0wd5BJfc2GYzdlBmT6yic1G9i62hbm0Ql9OnOvHgFPet27Q/iHb63avwWVzGvXvgy jBoRxInRWU1gmELoeLO1zyTW8AUKnWjTtkfdCMRB+gperY4wDJXthRaQkLYCD7aafT6s XAE0V23i69GSdFIvkx8jIeqBW2iL494H+O/6X0T7efo3aC86MAqNlRzIM+hR240r2lAS h4KgBLLSLHFSBvj0yRROGBDEichUaFK6nyA/277gFUUD7EJUOuHFm63Ds1yd/1MQ87ui vV6QMpiDfZvCAyZyCvl4vnwhrw08xTrt/2lMuJwiYMThZOuUlXOVchPqGUg60J0GDRnH PImA== X-Gm-Message-State: AC+VfDxJEDA6FheyzHIt6xKp//KUiYS3H1K1y1Vp5IaVrSWda6jVtG1O Jyu3K41rmDyHWHSxE9N8U194CfoINmx322A03dzTig== X-Google-Smtp-Source: ACHHUZ79bQdHnufR4WiDmBghKBLgar4OwgdPIKTkmmWYYp8gkthS3bTGlbM17/MI68PRAehXl+R6KWEGaOHEkWN4yZ8= X-Received: by 2002:aa7:cd89:0:b0:50c:52d:7197 with SMTP id x9-20020aa7cd89000000b0050c052d7197mr10184090edv.2.1686840744569; Thu, 15 Jun 2023 07:52:24 -0700 (PDT) MIME-Version: 1.0 References: <664D8681-C2DD-4163-B6CD-7BC8E785805D@cisco.com> <598b3d2ef59b4bb5978f05d225f11925@huawei.com> <54EFE818-3243-4FE0-854E-11866145C79E@cisco.com> <5D7BCEE9-BE8E-42DF-B15A-3270C0678DE0@cisco.com> <71cf2d9e791645f4b84ea032f134e801@huawei.com> <965B838D-A3BA-45CF-AAE1-C98CCCA1717E@cisco.com> In-Reply-To: From: Robert Raszuk Date: Thu, 15 Jun 2023 16:52:13 +0200 Message-ID: To: Alexander Vainshtein Cc: "Christian Schmutzer (cschmutz)" , "draft-schmutzer-spring-cs-sr-policy.all@ietf.org" , "spring@ietf.org" , "Dongjie (Jimmy)" Content-Type: multipart/alternative; boundary="0000000000005f8b3405fe2c37b9" Archived-At: Subject: Re: [spring] A technical concern regarding draft-schmutzer-spring-cs-sr-policy-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2023 14:52:54 -0000 --0000000000005f8b3405fe2c37b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sasha, 1. > Activate multi-topology IGP (e.g., MT-ISIS, RFC 5120 ) Don't you still run default topology which could suffer in the very same - and a very valid issue - you are reporting ? - - - The biggest issue for me for this proposal is that it highlights how to accomplish egress soft queuing reservation without any real time checks and automated operational measurements/feedback including auto terminating the service if operational assumptions are not met. Yes we do not have such a feedback model translated into service operations adopted in IETF but we are neither proposing circuit switching over connectionless paradigm. We are used to the notion that it is better to deliver degraded service then no service which IMO does not hold when it comes to guaranteed delivery promise. Thx, Robert On Thu, Jun 15, 2023 at 3:54=E2=80=AFPM Alexander Vainshtein < Alexander.Vainshtein@rbbn.com> wrote: > Christian and all, > > I have read Section 3.1 of the latest available version of the draft > , > and it seems that the BW guarantee mechanisms proposed in this section re= ly > on some mechanisms that prevent non-CS traffic from stealing resources fr= om > the CS-SR Policies in all cases including such unplanned events as > activation of TI-LFA paths following link failure and/or activation of > micro-loop avoidance paths following, say, link recovery. > > > > There seems to be no way to guarantee that this mechanisms would be > actually deployed and used correctly. > > > > IMHO and FWIW a clean and =E2=80=9Cpure SR=E2=80=9D solution (at least fo= r SR-MPLS) can be > provided along the following lines: > > 1. Activate multi-topology IGP (e.g., MT-ISIS, RFC 5120 > ) > 2. Configure a certain non-default topology on all the interfaces that > you expect to use for CS-RS policies, and: > 1. Allocate the required resources (BW etc.) for this topology on > each link where it is defined > 2. Request MT-ISIS to advertise Adj-SIDs for this topology (in > addition to whatever is advertised for the default topology), and t= ake care > that packets received with the labels allocated for these adjacenci= es are > forwarded using the topology-specific resources > 3. Report multi-topology configuration and Adj-SIDs to the SDN > controller and instruct it to build CS-SR Policies from Adj-SIDs belon= ging > to the SC-SR topology. > > > > Your feedback would be highly appreciated. > > > > Regards, > > Sasha > > > > *From:* Christian Schmutzer (cschmutz) > *Sent:* Tuesday, May 2, 2023 7:29 PM > *To:* Dongjie (Jimmy) > *Cc:* Christian Schmutzer (cschmutz) ; Alexander > Vainshtein ; > draft-schmutzer-spring-cs-sr-policy.all@ietf.org; spring@ietf.org > *Subject:* [EXTERNAL] Re: A technical concern regarding > draft-schmutzer-spring-cs-sr-policy-00 > > > > Hi Dongjie, > > > > As long as traffic of a CS-SR policy is within the =E2=80=9Cbandwidth con= tract=E2=80=9D > established during the CS-SR policy instantiation (or last update) I don= =E2=80=99t > see any issue with resource competition. > > > > Cases where a CS-SR policy is =E2=80=9Cout of contract=E2=80=9D we tried = to address so far > with those two sentences > > *https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-polic= y-01#section-3.1-6 > * > > *https://datatracker.ietf.org/doc/html/draft-schmutzer-spring-cs-sr-polic= y-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=E2=80=99t 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 b= e > 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) wrote: > > > > Hi Christian, > > > > Thanks for updating the draft and reminding me about my comments on the > previous version. > > > > I=E2=80=99ve 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 ensur= e > the total bandwidth of all the CS policies are guaranteed. While since > different CS policies share the same set of resources, is it possible tha= t > in some cases the services carried by the CS policies may compete with ea= ch > 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:cschmutz@cisco.com > ] > *Sent:* Thursday, April 27, 2023 6:37 PM > *To:* Dongjie (Jimmy) ; Alexander Vainshtein < > Alexander.Vainshtein@rbbn.com> > *Cc:* Christian Schmutzer (cschmutz) ; > draft-schmutzer-spring-cs-sr-policy.all@ietf.org; spring@ietf.org > *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) < > cschmutz@cisco.com> 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) 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:pce-bounces@ietf.org ] *On > Behalf Of *Alexander Vainshtein > *Sent:* Tuesday, July 26, 2022 3:48 PM > *To:* Christian Schmutzer (cschmutz) > *Cc:* draft-schmutzer-spring-cs-sr-policy.all@ietf.org; spring@ietf.org; > Rotem Cohen ; Nitsan Dolev ; > pce@ietf.org; Michael Gorokhovsky > *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 = =E2=80=9C*everything > not running over CS-SR has no bandwidth guarantee, is of lower priority a= nd > can undergo packet drops during DiffServ PHB processing*=E2=80=9D. > > > > 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 th= is > 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 ca= n > be achieved with MPLS-TP running as =E2=80=9Cships in the night=E2=80=9D = with SR-MPLS but > without the overhead of deep label stacks required by SR-CS. This approac= h > has been developed and deployed for quite some time now. IMHO it would be > interesting to compare these two approaches. > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@rbbn.com > > > > *From:* Christian Schmutzer (cschmutz) > *Sent:* Monday, July 25, 2022 6:45 PM > *To:* Alexander Vainshtein > *Cc:* Christian Schmutzer (cschmutz) ; > draft-schmutzer-spring-cs-sr-policy.all@ietf.org; spring@ietf.org; Rotem > Cohen ; Nitsan Dolev ; > pce@ietf.org; Michael Gorokhovsky > *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=E2=80=99t require additional unprotected adj-SIDs. The > unprotected adj-SID part of the two adj-SIDs you mentioned typically bein= g > 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 th= e > 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 volum= e > and the queue=E2=80=99s 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 coul= d > 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 discus= s > 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 < > Alexander.Vainshtein@rbbn.com> wrote: > > > > Hi all, > > I would like to clarify that, from my POV, my technical concerns about > draft-schmutzer-pce-sr-cs-routing-policies > > presented in my email dated 11-Jul-22 > > 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 =E2=80=9Cstrict BW guarantees=E2=80=9D = that are expected > of SR-CS policies would be violated every time one of these mechanisms > would result in some =E2=80=9Cregular=E2=80=9D 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 th= at > *SR cannot be used as a replacement for MPLS-TP* when it comes to BW > guarantees. > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@rbbn.com > > > > > 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 copie= s, > 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 copie= s, > including any attachments. > > > > > *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 m= ay > 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 > --0000000000005f8b3405fe2c37b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div>= We are used to the notion that it is better to deliver degraded service the= n no service which IMO does not hold when it comes to guaranteed delivery p= romise.=C2=A0=C2=A0

Thx,
Robert

On Thu, Jun 15, 2023 at 3:54=E2=80= =AFPM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> wrote:

Christian and all,

I have read Section 3.1 of the latest available version of the draft, and it seems = that the BW guarantee mechanisms proposed in this section rely on some mech= anisms that prevent non-CS traffic from stealing resources from the CS-SR P= olicies in all cases including such unplanned events as activation of TI-LFA paths following link failure and/= or activation of micro-loop avoidance paths following, say, link recovery.<= u>

=C2=A0

There seems to be no way to guarantee that this mech= anisms would be actually deployed and used correctly.

=C2=A0

IMHO and FWIW a clean and =E2=80=9Cpure SR=E2=80=9D = solution (at least for SR-MPLS) can be provided along the following lines:<= u>

  1. Activate multi-topology IGP (e.g., MT-ISIS, RFC 5120)
  2. Configure a certain non-default topolo= gy on all the interfaces that you expect to use for CS-RS policies, and:=
    1. Allocate the required resources (BW etc.) for this topology on each lin= k where it is defined
    2. Request MT-ISIS to advertise Ad= j-SIDs for this topology (in addition to whatever is advertised for the def= ault topology), and take care that packets received with the labels allocat= ed for these adjacencies are forwarded using the topology-specific resources<= u>
  3. Report multi-topology configuration and Adj-SIDs to the SDN controller = and instruct it to build CS-SR Policies from Adj-SIDs belonging to the SC-S= R topology.

=C2=A0

Your feedback would be highly appreciated.=

=C2=A0

Regards,

Sasha

=C2=A0

From: Christian Sc= hmutzer (cschmutz) <cschmutz@cisco.com>
Sent: Tuesday, May 2, 2023 7:29 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: Christian Schmutzer (cschmutz) <cschmutz@cisco.com>; Alexander Vainshtein= <Ale= xander.Vainshtein@rbbn.com>; draft-schmutzer-spring-cs-sr= -policy.all@ietf.org; spring@ietf.org
Subject: [EXTERNAL] Re: A technical concern regarding draft-schmutze= r-spring-cs-sr-policy-00

=C2=A0

Hi Dongjie,=

=C2=A0

As long as traffic of a C= S-SR policy is within the =E2=80=9Cbandwidth contract=E2=80=9D established = during the CS-SR policy instantiation (or last update) I don=E2=80=99t see = any issue with resource competition.=C2=A0

=C2=A0

Cases where a CS-SR polic= y is =E2=80=9Cout of contract=E2=80=9D we tried to address so far with thos= e two sentences

=C2=A0

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

=C2=A0

I would propose to incorp= orate potential changes in the future, or do you see final text for these t= opics gating=C2=A0WG adoption call?

=C2=A0

regards

Christian=C2=A0=



On 28.04.2023, at 10:58, = Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

=C2=A0

Hi Christian,

=C2=A0

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

=C2=A0

I=E2=80=99ve gone through the text in section = 3.1, and think it describes useful approaches for providing bandwidth guara= ntee to CS policies. While I have one remaining question:=C2=A0

=C2=A0

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 s= hare the same set of resources, is it possible that in some cases the servi= ces 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.<= span style=3D"font-size:12pt;font-family:SimSun">

=C2=A0

Best regards,

Jie

=C2=A0

From:=C2=A0Christian Sch= mutzer (cschmutz) [= mailto:cschmutz@cisco.com]=C2=A0
Sent:=C2= =A0Thursday, April 27, 2023 6:37 PM
To:=C2= =A0Dongjie (Jimmy) <jie.dong@huawei.com>; Alexander Vainshtein <Alexander.Vains= htein@rbbn.com>
Cc:=C2= =A0Christian Schmutzer (cschmutz) <cschmutz@cisco.com>; draft-schmutzer-spring-cs-sr-policy.all@ietf.org; spring@ietf.org Subject:= =C2=A0Re: A technical concern regarding draft-schmutzer-spring-cs-sr= -policy-00<= /span>

=C2=A0

Dear WG,=C2=A0

=C2=A0

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

=C2=A0

Thanks in advance=C2=A0

Christian




On 15.02.2023, at 19:24, Christian Schmutzer (csch= mutz) <cschmutz@cisco.com> wrote:<= /span>

=C2=A0

Hi Jie and Sasha,=C2=A0

=C2=A0

We recently published a new version of the draft t= rying to address your concerns on assumptions and procedures for guaranteei= ng bandwidth for CS-SR policies in the following section=C2=A0https://datatracker.ietf= .org/doc/html/draft-schmutzer-spring-cs-sr-policy-01#name-ensuring-bandwidt= h-guarante

=C2=A0

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

=C2=A0

regards

Christian=C2=A0




On 26.07.2022, at 22:23, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

=C2=A0

Hi Sasha and Christian,

=C2=A0

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 s= et of resources.

=C2=A0

I agree with Sasha that requesting a dedicated= traffic class may not be easy. Sasha gave a mechanism based on the coexist= ence 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 assoc= iate 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.

=C2=A0

Best regards,

Jie

=C2=A0

From:=C2=A0Pce [mailto:pce-bounces@ietf.org]=C2=A0On Behalf Of=C2= =A0Alexander Vainshtein
Sent:=C2= =A0Tuesday, July 26, 2022 3:48 PM
To:=C2= =A0Christian Schmutzer (cschmutz) <cschmutz@cisco.com>
Cc:=C2= =A0draft-schmutzer-spring-cs= -sr-policy.all@ietf.org;=C2=A0spring@ietf.org; Rotem Cohen <= Rotem.Cohen@rbbn.com>; Nitsan Do= lev <Nitsan.Dolev@rbbn.com>;=C2=A0pce@ietf.org; Michael Gorokhovsky <Michael.Gorokhovsky@rbbn.com>
Subject:= =C2=A0Re: [Pce] A technical concern regarding draft-schmutzer-spring= -cs-sr-policy-00

=C2=A0

Christian,

Lots of thanks for your p= rompt 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).

=C2=A0

Regarding your explanatio= n, I believe that the key point is the sentence =E2=80=9Ceverything not = running over CS-SR has no bandwidth guarantee, is of lower priority and can= undergo packet drops during DiffServ PHB processing=E2=80=9D.=

=C2=A0

This statement is an=C2=A0a= ssumption=C2=A0that:

1.=C2=A0 Is critical for SR-CS = to deliver its promise=

2.=C2=A0 Is actually a requirem= ent (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.=C2=A0 Unless I am mistaken, = is not explicitly stated in the current version of the draft (or in any of = the associated drafts),

=C2=A0

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

=C2=A0

Please notice also that i= n the =C2=A0case of MPLS networks the same results can be achieved with MPL= S-TP running as =E2=80=9Cships in the night=E2=80=9D with SR-MPLS but witho= ut the overhead of deep label stacks required by SR-CS. This approach has been developed and deployed for quite some time now. IMH= O it would be interesting to compare these two approaches.

=C2=A0

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0=C2=A0Alexander.Vainshtein@rbbn.com

=C2=A0

From:=C2=A0Christian Sch= mutzer (cschmutz) <cschmutz@cisco.com>=C2=A0
Sent:=C2= =A0Monday, July 25, 2022 6:45 PM
To:=C2= =A0Alexander Vainshtein <Alexander.Vainshtei= n@rbbn.com>
Cc:=C2= =A0Christian Schmutzer (cschmutz) <cschmutz@cisco.com>;= =C2=A0draft-schmutzer-spring= -cs-sr-policy.all@ietf.org;=C2=A0spring@ietf.org; Rotem Cohen <= Rotem.Cohen@rbbn.com>; Nitsan Do= lev <Nitsan.Dolev@rbbn.com>;=C2=A0pce@ietf.org; Michael Gorokhovsky <Michael.Gorokhovsky@rbbn.com>
Subject:= =C2=A0[EXTERNAL] Re: A technical concern regarding draft-schmutzer-s= pring-cs-sr-policy-00<= /u>

=C2=A0

Hi Sasha,

=C2=A0

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.

=C2=A0

CS-SR policies don=E2=80= =99t require additional unprotected adj-SIDs. The unprotected adj-SID part = of the two adj-SIDs you mentioned typically being present per link in a net= work does suffice.=

=C2=A0

Further the draft does no= t 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=C2=A0bandwidth requested by all candidate-paths going via a link is kept below the reserv= able maximum bandwidth defined.

=C2=A0

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

=C2=A0

You are correct, mechanis= ms such as TI-LFA may lead to congestion, but the assumption is that everyt= hing not running over CS-SR, has no bandwidth guarantee, is of lower priori= ty and can undergo packet drops during DiffServ PHB processing.=

=C2=A0

There are many ways to fu= lfil those PHB processing requirements. One way is to mark CS-SR policy tra= ffic 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 nev= er be congested (i.e. the non CS-SR traffic is important but has very low v= olume and the queue=E2=80=99s bandwidth is over-provisioned to be enough fo= r CS-SR and non CS-SR traffic together)

=C2=A0

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

=C2=A0

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 on= ly.<= /p>

=C2=A0

Regards

Christian=C2=A0

=C2=A0

=C2=A0

On 24.07.2022, at 19:02, = Alexander Vainshtein <Alexander.Vainshtein@rbbn.com= > wrote:=

=C2=A0

Hi all,

I would like to clarify t= hat, from my POV, my technical concerns about=C2=A0draft= -schmutzer-pce-sr-cs-routing-policies=C2=A0presented in my=C2=A0email dated 11-Jul-22=C2=A0fully apply to this draft.

=C2=A0

Specifically, the authors= do not define any mechanisms that would prevent possible usage of unprotec= ted Adj-SIDs used in the configuration of the candidate paths of CR-CS poli= cies from being also used by such well-known and widely deployed mechanisms as TI-LFA and Segment Routing Mi= croloop Avoidance.=C2=A0 As a consequence, the =E2=80=9Cstrict BW guarantee= s=E2=80=9D =C2=A0that are expected of SR-CS policies would be violated ever= y time one of these mechanisms would result in some =E2=80=9Cregular=E2=80= =9D traffic being sent via the paths defined by such mechanisms.

=C2=A0

Even if such mechanisms w= ere defined in a future version of =C2=A0draft-schmutzer-spring-cs-sr-polic= y, a retrofit of existing implementations of TI-LFA and/or SR Microloop Avo= idance would be required.=

=C2=A0

I understand the motivati= on for CR-SC Policies, but I strongly suspect that=C2=A0SR cannot be used as = a replacement for MPLS-TP=C2=A0when it comes to BW guarantees.

=C2=A0

Regards,

Sasha

=C2=A0

Office: +972-39266302

Cell:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 +972-549266302

Email:=C2=A0=C2=A0=C2=A0Alexander.Vainshtein@rbbn.com

=C2=A0


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.

=C2=A0


Notice: This e-mail together with any attachments may contain information o= f Ribbon Communications Inc. and its Affiliates that is confidential and/or= proprietary for the sole use of the intended recipient. Any review, disclo= sure, 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 a= nd then delete all copies, including any attachments.<= /p>

=C2=A0



Disclaimer

The information contained in this communication from th= e sender is confidential. It is intended solely for use by the recipient an= d others authorized to receive it. If you are not the recipient, you are he= reby notified that any disclosure, copying, distribution or taking action i= n relation of the contents of this information is strictly prohibited and m= ay be unlawful.

This email has been scanned for viruses and malware,= and may have been automatically archived by Mimecast, a leader in email se= curity 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 organizatio= ns from malicious activity, human error and technology failure; and to lead= the movement toward building a more resilient world. To find out more, vis= it our website.

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000005f8b3405fe2c37b9--