[Detnet] Re: New Version Notification for draft-varga-detnet-srv6-data-plane-03.txt

[[e-mail]]

Hi Bala'zs,


Thank you for the clarification.


I agree that for MPLS S-label it naturally has a local meaning, and we don't talk about upstream-assigned label mode. In this case the owner of S-label ensures its uniqueness among all flows. 


If follow this option, do we need some documents describe the advertisement of S-label? I don't think it is completely similar to VPN/PW label's advertisement, at least FEC is completely different. The cost of this option is to introduce flow's FIB state on the Redundancy node, and necessary advertisement of S-label, and cut off end-to-end DetNet path to serveral segments.


Another option is MPLS MNA, and the situation seems to improve in this optioin. No advertisement of S-label is required. The flow-id and sequence number are directly inserted in MNA. But, of course, the flow-id is better to have global meaning. Since it need not introduce flow's FIB state on the Redundancy node, it will not cut off end-to-end DetNet path to serveral segments.




The second option seems to have a lower cost, although both of them may work.


IPv6 may also apply option similar to MPLS MNA, i.e., no advertisement of "SID.arg -> flow" mapping relationship is required, and the flow-id and sequence number are directly inserted in an IPv6 extension header.

Local flow-id seems to have other security risks as well. For example, two Redundancy Node (e.g., Elm node A and Elm node B) may allocate the same S-label for different two flows, and in normal forwarding case there is no problem for elimination process at each Elm node, but in abnormal case, a packet that should be directed to Elm node A has been directed to Elm node B (e.g., during MPLS FIB entry state change), then one flow will disrupt the elimination process of another flow.


In summary, the cost of local flow-id:
1) Advertisement of flow-id is required between Redundancy nodes.
2) Flow's FIB state is required at Redundancy nodes.
3) Cut off end-to-end DetNet path and bring complex to EDP metadata encapsulation.


Regards,
PSF




Original


From: BalázsVargaA <[e-mail]>
To: 彭少富10053815;
Cc: [e-mail] <[e-mail]>;
Date: 2026年02月04日 21:09
Subject: RE: [Detnet] Re: New Version Notification for draft-varga-detnet-srv6-data-plane-03.txt



Hi Shaofu,
 
Many thanks for your clarification question.
 
The allocation characteristics of Flow-ID is independent from the DetNet
data plane encapsulation. Flow-IDs are allocated locally and this nature is
explicitly referred in the data plane documents, e.g., in RFC8964 in Section
‘4.2.2.  S-Labels’:
“ … S-Labels are local to each node,
   rather than being a global identifier within a domain, they must be
   advertised to their upstream DetNet service-aware peer nodes (i.e., a
   DetNet MPLS end system or a DetNet relay or edge node) and
   interpreted in the context of their received F-Label(s).”
 
Same characteristics applies for the SRv6 data plane encapsulation, where
Flow-ID is encoded in the ARG part of the Redundancy SID. It is defined in
your referred text.
 
Regarding your question, “why local”: allocating local values allow better
flexibility. An APP flow may have several Member flows along the PREOF-path.
 
Please note, that nothing prohibits You to use globally unique values in a given
network scenario, if there are no related concerns.
 
A possible Flow-ID allocation example for the Figure-3 network:
(Note: in this example a Flow-ID is 20 bits, “NNNN” refers to a 16 bit SeqNum)
- E5: Flow-ID = 00001x (local),
   results in following Redundancy SID value: 2001:db8:K:5:P:0000:1NNN:N000
   (packet routed based on 2001:db8:K:5/64 routing table entry pointing to node E5)
- R2: Flow-ID = 00002x
   results in following Redundancy SID value: 2001:db8:K:2:P:0000:2NNN:N000
   (packet routed based on 2001:db8:K:2/64 routing table entry pointing to node R2)
- E6: Flow-ID = 00002x
   results in following Redundancy SID value: 2001:db8:K:6:P:0000:2NNN:N000
   (packet routed based on 2001:db8:K:6/64 routing table entry pointing to node E6)
 
Thanks & Cheers
Bala’zs
 
 
 

From: [e-mail] <[e-mail]> 
 Sent: Tuesday, February 3, 2026 3:33 AM
 To: Balázs Varga A <[e-mail]>
 Cc: [e-mail]
 Subject: Re: [Detnet] Re: New Version Notification for draft-varga-detnet-srv6-data-plane-03.txt


 
 
Hi Bala'zs,
 
Thanks for sharing this document.
 
After reading the document, I still have quesitons about the setting of flow-id and don't understand how it works.
 
There is some text in the document as below:
"
Flow-IDs MUST be allocated by the entity that controls the service sub-layer receiving node's Flow-ID space.  Because Flow-IDs are local to each node rather than being a global identifier within a domain, they MUST be advertised to their upstream DetNet service-aware peer nodes (i.e., a DetNet SRv6 End System or a DetNet Relay or Edge Node).
"
 
My quesiton is: why is flow-id designed to be local rather than global? Seems it brings unnecessary complex about flow-id advertisement, inconsistency of identifying the same APP flow.
 
Can you give some illustrations on how to set flow-id based on the example topology (fig 3 of draft-ietf-spring-sr-redundancy-protection-05) ? 
 
Regards,
PSF
 

Original

From: BalázsVargaA <balazs.a.varga=[e-mail]>



To: DetNet WG <[e-mail]>;



Date: 2026年02月03日 01:31



Subject: [Detnet] Re: New Version Notification for draft-varga-detnet-srv6-data-plane-03.txt




Hi,
 
 Changes in the new version of the "Deterministic Networking SRv6 Data Plane" draft
 https://datatracker.ietf.org/doc/draft-varga-detnet-srv6-data-plane/
 was made in order to be fully in-line with the Spring WG Redundancy Protection draft
 
 The technical contents of the draft is quite stable, thanks for all the feedbacks during
 its discussions.
 
 Please, provide your review if you have any questions/comments/possible improvements.
 Supportive feedbacks are also welcome.
 
 Thanks & Cheers
 Bala'zs
 
 Ps: the Spring WG Redundancy Protection draft is available here:
 https://datatracker.ietf.org/doc/draft-ietf-spring-sr-redundancy-protection/
 
 -----Original Message-----
 From: [e-mail] <[e-mail]> 
 Sent: Sunday, February 1, 2026 1:46 PM
 To: Balázs Varga A <[e-mail]>; Ferenc Fejes <[e-mail]> 
 Subject: New Version Notification for draft-varga-detnet-srv6-data-plane-03.txt
 
 A new version of Internet-Draft draft-varga-detnet-srv6-data-plane-03.txt has been successfully submitted by Balazs Varga and posted to the IETF repository.
 
 Name:     draft-varga-detnet-srv6-data-plane
 Revision: 03
 Title:    Deterministic Networking SRv6 Data Plane
 Date:     2026-02-01
 Group:    Individual Submission
 Pages:    17
 URL:      https://www.ietf.org/archive/id/draft-varga-detnet-srv6-data-plane-03.txt
 Status:   https://datatracker.ietf.org/doc/draft-varga-detnet-srv6-data-plane/
 HTMLized: https://datatracker.ietf.org/doc/html/draft-varga-detnet-srv6-data-plane
 Diff:     https://author-tools.ietf.org/iddiff?url2=draft-varga-detnet-srv6-data-plane-03
 
 Abstract:
 
    This document specifies the Deterministic Networking (DetNet) data
    plane when operating over an IPv6/SRv6 Packet Switched Network.  It
    leverages existing IPv6 encapsulations and behaviors.  It uses the
    Redundancy SIDs in DetNet scenarios and optionally the Traffic
    Engineering mechanisms provided by SRv6.  This document builds on the
    DetNet architecture and data plane framework.
 
 
 
 The IETF Secretariat
 
 
 _______________________________________________
 detnet mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]