Hi，
Please see inline,
Thanks,
Zheng
From: Robert Raszuk
Date: 2025-07-05 04:26
To: 阮征(联通集团本部)
CC: spring; spring-chairs
Subject: [spring] Re: seek opinions on the draft
【本邮件为外部邮件，请注意核实发件人身份，并谨慎处理邮件内容中的链接及附件】
Hello,
Apologies for the delay in replying ...
comment #1 - You say "We need a new SID" - well please kindly confirm if by
this you really mean to say "We need a new behaviour"
--Perhaps the relevant descriptions in my draft have caused you a
misunderstanding. Our original intention was to define a new behaviour. Since
this kind of behaviour is also associated with an interface and has some
similarities with End.X , so it was named End.X.PFC. This naming method might
have led to your misunderstanding.
question 1 - If this is what you are after it is not reflected in your draft.
Because currently in your draft you are actually defining a new flavor and
trying to stitch it to existing behaviours.
--We will consider modifying the relevant descriptions in the draft later to
avoid such misunderstandings.
comment #2 - You are proposing 4 new behaviors effectively by adding new flavor
to combination of End.X behavior with existing flavors:
| TBA | TBA | End.X.PFC | [This ID] |
| TBA | TBA | End.X.PFC with PSP | [This ID] |
| TBA | TBA | End.X.PFC with USP | [This ID] |
| TBA | TBA | End.X.PFC with PSP & USP | [This ID |
question 2a - Why USD flavour is excluded ?
--We will consider adding it in the future and carry out further detailed
design.
question 2b - Why End behaviour is excluded and you are only extending End.X ?
--This behaviour is mainly associated with a interface, so the End behaviour
was not taken into consideration.
comment #3 - You have defined upper-layer header processing ... well to the
best of my knowledge End.X behaviour does not process upper layer headers.
Quote from your draft which today defines flavours only for End.X:
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. If(Destination MAC==01-80-C2-00-00-01)
S04. Interface J will perform flow control actions based on the
content in the Priority - Flow Control (PFC) frames.
S05. } Else {
S06. Process as per Section 4.1.1 defined in [RFC8986]
S07. }
--In Section 4.2 of RFC 8986, there is a description that says, "When
processing the Upper-Layer header of a packet matching a FIB (Forwarding
Information Base) entry locally instantiated as an End.X SID, process the
packet as per Section 4.1.1."
Based on this, I think that in some scenarios, End.X can process the upper
layer header.
comment #4 - In pseudocode definition and in your text you are treating "J" as
interface ... well this is in RFC8986 a group of interfaces - subtle but very
important difference for scalability
--I think this expression can be applied to the behaviour we have defined, such
as a eth-trunk interface .
comment #5 - In your example from section 3 you say:
"The segment list is {R1.End.X.PFC, R2.End, R3.End.X.PFC},"
question 3: Are you sure R2 should advertise End SID and not End.X SID ? What
happens if not all ingress interfaces on R3 (assuming more then one is
connected to R2) support PFC ?
--In this example, our assumption is that all the interfaces of R1 and R3
support PFC (in actual projects, we also plan to use such devices as boundary
devices).
If, according to your assumption, some interfaces do not support PFC and
traffic is forwarded to those interfaces, then the mechanism will fail. So in
that case, the End.X SID of R2 needs to be included.
To summarize if we keep adding flavors like proposed in your draft we will very
soon explode 32K of behaviours and flavors combinations.
So instead perhaps it makes sense to simply add a new SID behaviour say End.PFC
which would be used as adj-sid to meet your requirement of quote:
--I think this is exactly what I meant.
"Based on the original End.X SID, it incorporates additional meanings to
facilitate the identification of
interfaces in the network that possess the capability to handle PFC packets."
What I was sort of questioning in my original note was however if you could
avoid all the hassle and simply put PFC indicator as Adj-SID function or even
function argument if hardware could handle it ?
--It seems that defining a new behaviour is a relatively appropriate solution
at present. It can not only identify the PFC-capable interfaces, but also
announce it to the remote devices and the controller for the creation of
reverse tunnels.
Thx a lot,
Robert
On Fri, Jun 27, 2025 at 4:12 AM 阮征(联通集团本部) <[email protected]> wrote:
Hi，
Please see inline，
Thanks，
Zheng
[email protected]
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 阮征(联通集团本部) <[email protected]> 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 阮征(联通集团本部) <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
