Re: [spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14

[Rishabh Parekh]

Wesley,
Thanks for the review.

The Replication function is performed by nodes within an SR domain. The
trust model of SR with traffic filtering at SR domain boundaries applies to
this document and is covered by the first sentence referring to security
considerations of RFCs 8402, 8986 and 8754.

I will add some text addressing comment (2).

As Joel mentioned, pseudo-code uses a convention introduced in SRv6 RFC
8986. I will add a reference to 8986 in Section 2.2.1.

-Rishabh




On Fri, Jun 16, 2023 at 1:33 PM Wesley Eddy via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Wesley Eddy
> Review result: Almost Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-...@ietf.org if you reply to or forward this review.
>
> (1) Since this defines a behavior where one incoming packet can create N
> outgoing packets, I was surprised that there is nothing mentioned in the
> security considerations about how access to replication nodes and ingress
> for
> them should be protected in order to prevent abuse.
>
> (2) The intended use seems mainly to be where some outer control system is
> responsible for making sure that the replication operation will put packets
> onto distinct network paths, and not create congestion either locally or on
> some potential shared network segment downstream.  It might be more clearly
> stated that it's assumed that building a proper multicast tree, managing
> group
> membership, and performing multicast congestion control need to be
> performed
> elsewhere.
>
> (3) I didn't recognize the syntax or pseudocode conventions in section
> 2.2.1;
> maybe this is common or defined somewhere else that could be referenced to
> be
> clear?
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [Last-Call] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14

[Joel Halpern]

I will leave it to the authors and shepherd to respond, including 
whether to add a reference for the pseudo-code in 2.2.1.


Just to save one piece of effort, the pseudo-code technique used here 
was introduced in RFC 8986, and is used in almost all the SRv6 related 
drafts / RFCs.  While I am not a fan of the particular formalism, it is 
what SRv6 uses, and so we all live with it.


Yours,

Joel

On 6/16/2023 4:32 PM, Wesley Eddy via Datatracker wrote:

Reviewer: Wesley Eddy
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

(1) Since this defines a behavior where one incoming packet can create N
outgoing packets, I was surprised that there is nothing mentioned in the
security considerations about how access to replication nodes and ingress for
them should be protected in order to prevent abuse.

(2) The intended use seems mainly to be where some outer control system is
responsible for making sure that the replication operation will put packets
onto distinct network paths, and not create congestion either locally or on
some potential shared network segment downstream.  It might be more clearly
stated that it's assumed that building a proper multicast tree, managing group
membership, and performing multicast congestion control need to be performed
elsewhere.

(3) I didn't recognize the syntax or pseudocode conventions in section 2.2.1;
maybe this is common or defined somewhere else that could be referenced to be
clear?




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

[spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14

[Wesley Eddy via Datatracker]

Reviewer: Wesley Eddy
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-...@ietf.org if you reply to or forward this review.

(1) Since this defines a behavior where one incoming packet can create N
outgoing packets, I was surprised that there is nothing mentioned in the
security considerations about how access to replication nodes and ingress for
them should be protected in order to prevent abuse.

(2) The intended use seems mainly to be where some outer control system is
responsible for making sure that the replication operation will put packets
onto distinct network paths, and not create congestion either locally or on
some potential shared network segment downstream.  It might be more clearly
stated that it's assumed that building a proper multicast tree, managing group
membership, and performing multicast congestion control need to be performed
elsewhere.

(3) I didn't recognize the syntax or pseudocode conventions in section 2.2.1;
maybe this is common or defined somewhere else that could be referenced to be
clear?


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Gyan Mishra]

Hi Sasha

An alternative to ISIS MT as you described a non default topology “NRP”,
 but now instead we can use SR Algo sub topology that would have its own
prefix SIDs range and no need for Adj SID  as it’s a sub topology or
network slice or link coloring, discrete color of the physical underlay
topology “NRP” with it would have its own resources allocated from the
underlay.

Here we could as well use resource SIDs as described by Jie for resource
allocation and report the sub topology graph and bandwidth demands CIR /
PIR for bursts to the PCE / SDN controller as part of the CS-SR topology.

As described by Christian we can also continue to leverage QOS dual leaky
bucket CIR / PIR Bc Be and place the transport flows in SP LLQ high
priority queue that is PHB scheduled first over WRR queues.

>From what I recall with transport network modernization for CES TDM
services that MPLS-TP which is just a modified MPLS data plane did not take
off in the industry as it supported only Co-routed LSPs and not
unidirectional LSPs.  That was a major problem.  RFC 7551 RSVP-TE extension
for bidirectional Co-routed path allowed for existing unidirectional LSPS
with Co-routed LSPs over the same MPLS data plane.  Problem solved.  This
allowed for a converged IP/MPLS Optical transport core to now be able to
carry legacy TDM CES traffic and IP / Optical layer convergence leading to
Routed Optical Networks with coherent optics over IP/MPLS with RSVP-TE
extension RFC 7551 for Co-routed paths.

So now with this draft we are making the case to provide the same or better
statelessly over SR transport with CS-SR policy and it’s possible
 feasibility.

As you had mentioned issue with MSD which I agree is an issue, however with
SR-MPLS, MSD issues can be circumvented with PCE / BGP-LS signaling via IGP
the SID depth and maximum SID list as well most operators run Jumbo frames
9216.   MSD issues can be easily circumvented.

With SR as it’s stateless what RSVP-TE provides with stateful bandwidth
management PCALC bandwidth admission control with auto bandwidth, setup and
hold priorities to give high bucket priority to CES TDM, cannot be
translated to SR technology which is a gap.  Agreed.

So how do we make the case for SR for transport networks and fill the
bandwidth management gap.

The workaround is the paradigm shift from distributed to centralized model
with PCE / SDN controller requirement for any SR deployment and now being
able to get the similar bandwidth management congestion control
capabilities leveraging SR-PM, PT and other SR enhancements, so now we can
get the same bandwidth call admission control granularity as traditionally
done with stateful RSVP-TE but now realizing it over SR via CS-SR.

Kind Regards

Gyan

On Thu, Jun 15, 2023 at 9:55 AM Alexander Vainshtein <
alexander.vainsht...@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 mechanisms that prevent non-CS traffic from stealing resources from
> 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 “pure SR” solution (at least for 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 take 
> care
>   that packets received with the labels allocated for these adjacencies 
> 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 belonging
>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@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 “bandwidth contract”
> established during the