Subject: [spring] Re: Fwd: I-D Action: draft-ietf-spring-resource-aware-segments-09.txt
From: "Dongjie (Jimmy)" <[email-masked]>
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG <[email-masked]>
Date: Wed, 8 May 2024 14:34:10 +0000
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>

Hi Robert,

Please see further inline with [Jie#2]:

From: Robert Raszuk <[email-masked]>
Sent: Wednesday, May 8, 2024 5:16 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: SPRING WG <[email-masked]>
Subject: Re: [spring] Fwd: I-D Action: draft-ietf-spring-resource-aware-segments-09.txt

Hi Jie,

> [Jie] The forwarding plane need to support some mechanism for the partitioning of network resources,

Is this hard partitioning (waste of resources if not used) or soft one (resource sharing) across a number of different resource aware SIDs ?

[Jie#2] IMO both can be supported, it depends on the forwarding plane mechanism chosen.

> [Jie] If there are non-SR transit nodes in the network, they just support best-effort forwarding,

So I think the draft should make it cristal clear that this only makes sense in hop by hop SR paths.

[Jie#2] It is natural that end-to-end guarantee can only be achieved with all nodes supporting the enhanced feature. But we can add some text to clarify this.

> [Jie] This document defines the resource-aware SID mechanism and the data plane behavior

Well honestly I am afraid it does not. For example what I find missing is description of coexistence with current QoS mechanisms based on diffserv model.

[Jie#2] The DIffserv QoS model can be used together with the resource-aware SID mechanism in a hierarchical manner. The resource-aware SID identifies a subset of resources used for packet processing, and the DSCP (or TC in MPLS) can be used to provide differentiate treatment for packets with the same resource-aware SID. We can add some text to explain this usage in the draft.

Hope this helps.

Best regards,
Jie

Thx,
R.

On Wed, May 8, 2024 at 4:15 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks for your review and comments, please see some replies inline:

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 7, 2024 4:06 PM
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Fwd: I-D Action: draft-ietf-spring-resource-aware-segments-09.txt

Dear Authors & Contributors of draft-ietf-spring-resource-aware-segments,

I have few questions in respect to your proposal:

#1 - If you say that DiffServ mechanism is not sufficient to handle data plane processing across the nodes are you envisioning that new forwarding hardware will be needed (or upgrade to the existing one if programmable) to take into forwarding decision resource aware SIDs ?

[Jie] The forwarding plane need to support some mechanism for the partitioning of network resources, and associate different subset of the resources with resource-aware SIDs. This can be done either by hardware upgrade (e.g. FlexE), or it can be achieved by firmware or software upgrade (e.g. associate dedicated sub-interfaces/queues with resource-aware SIDs).

#2 - As you know SR is not required at non SR capable nodes and SR segment can often span multiple nodes. How are you going to protect your resources in non SR transit nodes ?

[Jie] If there are non-SR transit nodes in the network, they just support best-effort forwarding, in this case resource cannot be guaranteed. If the transit nodes are SR capable, and they also support resource-aware segments, resource can be guaranteed.

#3 - Document says that signalling resource aware SIDs and resources associated with it is out of scope, how are you planning to propagate resource utilization at least between segment nodes and controller (PCE) ?

[Jie] This document defines the resource-aware SID mechanism and the data plane behavior, the control plane mechanisms are specified in other accompanying drafts. For example, the resource information and the associated SR SIDs can be distributed to the controller using BGP-LS.

Best regards,
Jie

Many thx,
Robert

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, May 7, 2024 at 5:11 AM
Subject: I-D Action: draft-ietf-spring-resource-aware-segments-09.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

Internet-Draft draft-ietf-spring-resource-aware-segments-09.txt is now
available. It is a work item of the Source Packet Routing in Networking
(SPRING) WG of the IETF.

   Title:   Introducing Resource Awareness to SR Segments
   Authors: Jie Dong
            Takuya Miyasaka
            Yongqing Zhu
            Fengwei Qin
            Zhenqiang Li
   Name:    draft-ietf-spring-resource-aware-segments-09.txt
   Pages:   13
   Dates:   2024-05-06

Abstract:

   This document describes the mechanism to associate network resources
   to Segment Routing Identifiers (SIDs).  Such SIDs are referred to as
   resource-aware SIDs in this document.  The resource-aware SIDs retain
   their original forwarding semantics, but with the additional
   semantics to identify the set of network resources available for the
   packet processing and forwarding action.  The resource-aware SIDs can
   therefore be used to build SR paths or virtual networks with a set of
   reserved network resources.  The proposed mechanism is applicable to
   both segment routing with MPLS data plane (SR-MPLS) and segment
   routing with IPv6 data plane (SRv6).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-resource-aware-segments/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-resource-aware-segments-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

_______________________________________________
I-D-Announce mailing list -- [email-masked]<mailto:[email-masked]>
To unsubscribe send an email to [email-masked]<mailto:[email-masked]>