Hi Robert,

Please see further inline with [Jie#2]:

From: Robert Raszuk <[email protected]>
Sent: Wednesday, May 8, 2024 5:16 PM
To: Dongjie (Jimmy) <[email protected]>
Cc: SPRING WG <[email protected]>
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 protected]<mailto:[email protected]>> wrote:
Hi Robert,

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

From: Robert Raszuk [mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, May 7, 2024 4:06 PM
To: SPRING WG <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>>
Date: Tue, May 7, 2024 at 5:11 AM
Subject: I-D Action: draft-ietf-spring-resource-aware-segments-09.txt
To: <[email protected]<mailto:[email protected]>>
Cc: <[email protected]<mailto:[email protected]>>


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 protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to