Hi,

Please see inline,
 
Thanks,

Zheng


rua...@chinaunicom.cn
 
From: Robert Raszuk
Date: 2025-06-26 18:18
To: 阮征(联通集团本部)
CC: spring; spring-chairs
Subject: [spring] Re: seek opinions on the draft
【本邮件为外部邮件,请注意核实发件人身份,并谨慎处理邮件内容中的链接及附件】
Hi,

  (1) We need a new SID to advertise to the network or controller which 
interfaces in the current network have PFC processing capabilities (not all 
devices and interfaces support PFC),

Why not use adj SID and add this as a part of the function ? 

---In my view, this new SID is essentially an adjacency SID with special 
functionalities. Regarding your proposal to "add this as a part of the 
function", I haven't fully grasped your key point. Are you suggesting extending 
other fields of adj SID,such as Flavor? Could you elaborate on your suggestion 
in more detail?

Thx,
R.


On Thu, Jun 26, 2025 at 3:45 AM 阮征(联通集团本部) <rua...@chinaunicom.cn> wrote:
Hi Robert,

Thank you for your valuable comments,

Please see inline,

Thanks,

Zheng
 
From: Robert Raszuk
Date: 2025-06-24 18:45
To: 阮征(联通集团本部)
CC: spring; spring-chairs
Subject: [spring] Re: seek opinions on the draft
【本邮件为外部邮件,请注意核实发件人身份,并谨慎处理邮件内容中的链接及附件】
Hi,

Pretty interesting idea however I have few basic questions: 

a)  Why do you define a new SID type instead of using existing node or adj SID 
and putting flow control as a SID function ? The entire idea of network 
programming is not about adding more and more SID types ... it is about 
inventing and adding network functions. 

 There are two reasons for defining a new SID function:

  (1) We need a new SID to advertise to the network or controller which 
interfaces in the current network have PFC processing capabilities (not all 
devices and interfaces support PFC), and use this SID to guide the controller 
and remote devices to establish reverse tunnels for carrying PFC backpressure 
frames. However,existing SIDs do not have this functionality.
  (2) When a device receives a packet with this SID as the destination IPv6 
address, it needs to perform special actions that are fundamentally different 
from the functions of existing SIDs.

b) If this is for WAN how do you assure all nodes on the path between src and 
dst support PFC ? I assume by WAN you mean number of transit ASNs with 
different IGPs and no BGP-LS NNI running. Or do you mean that such WAN would 
always be under the same administrative domain ? 

Not all nodes need to support PFC. It only requires deploying SRv6 tunnels 
between PFC-capable nodes to carry backpressure signals. I believe the current 
scope of this technology should be within a single AS, and perhaps MAN 
scenarios are more applicable than WAN scenarios. Cross-AS scenarios are much 
more complex, which we can consider in the future, subject to the community's 
support for this solution.

c) I recommend you add some OAM enhancements to indicate with ping/traceroute 
that such support is there. Moreover I also would like to see reporting of the 
state of the buffers with any already defined inband OAM SR mechanism. 

We will consider adding OAM functionality to indicate the reachability of this 
SID. In my original concept, buffer status is monitored by the device itself, 
and when the buffer exceeds a set threshold, a backpressure signal is sent 
upstream. Your idea is to use in-band OAM to carry buffer status information, 
allowing upstream routers to proactively take flow control actions based on 
this information, right? This is a highly insightful suggestion.


d) Your proposal requires a lot of queues and buffers to be available on each 
transit node. That's pretty expensive and sometimes harmful for real time data 
where microseconds or less matters. Have you done any comparison or educated 
simulations how would it compare with end-to-end ECN say using DCTCP ? Wouldn't 
end to end not be more efficient if we are talking about few WAN nodes under 
same administration ? 

Latency-sensitive services can continue to adopt traditional deployment 
schemes, while loss-sensitive services or elephant flows prone to causing 
network congestion can deploy this solution. In my view, end-to-end ECN and the 
technology I proposed are technologies of different dimensions, and they are 
not in a competitive relationship. These two technologies can be deployed 
simultaneously to achieve higher data transmission efficiency.


Thx a lot,
Robert







On Tue, Jun 24, 2025 at 6:13 AM 阮征(联通集团本部) <rua...@chinaunicom.cn> wrote:
Hello everyone, 

We have just submitted a new draft titled "Priority-based Flow Control SID in 
SRv6". The concept of this draft originates from cross-DC communication 
scenarios, aiming to achieve end-to-end flow control through coordination 
between WAN and data center networks by enhancing flow control capabilities of 
selected WAN devices, thereby reducing network packet loss.

This document proposes a new End.X.PFC SID to identify network interfaces with 
PFC capabilities, enabling backpressure frames to be transmitted across hops 
via SRv6 tunnels.

This technology can be leveraged to mitigate congestion and packet loss caused 
by micro-burst traffic in the network, with enhanced effectiveness in specific 
scenarios such as RDMA over WAN and elephant flow environments.

Please review the draft in the following link:

https://datatracker.ietf.org/doc/draft-ruan-spring-priority-flow-control-sid/

Welcome any feedback and comments.

Best Regards

Ruanzheng on behalf of co-authors

_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
_______________________________________________
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org

Reply via email to