Hi Bala’zs, Thank you very much for your review and the valuable comments. Please find the reply inline started with Fan1>>. Cheers, Fan
发件人: detnet [mailto:[email protected]] 代表 Balázs Varga A 发送时间: 2021年4月23日 21:49 收件人: [email protected]; spring <[email protected]> 主题: [Detnet] DetNet data plane: some questions/comments about draft-geng-spring-sr-redundancy-protection Hi, I have reviewed the draft from DetNet perspective and I have some questions/comments: 1, (Sub-)layer violation: The draft is referring DetNet documents (RFC8655, RFC8964) and explicitly the PREOF functionality. There seems to be a (sub-)layer violation caused by this draft. In DetNet PREOF belongs to the DetNet service sub-layer. DetNet forwarding sub-layer uses LSPs to forward the DetNet packet and any method can be used for establishing that LSP (including segment routing). This draft seems to move the PREOF functionalities to the forwarding sub-layer, what contradicts the DetNet architecture. PREOF intentionally terminates the forwarding sub-layer. For example using SR the label stack differs per member flows. What is the rationale to duplicate PREOF functionalities? Have I missed something? Fan1>>: I would like to clarify it with SR-MPLS and SRv6 separately. As for SR-MPLS part, there is no intention to violate RFC8964. The authors will double check with the specifications in RFC8964 and try to keep consistent. Detailed modification is provided in the second question. As for SRv6 part, we follow the specifications from draft-geng-detnet-dp-solv-srv6. No explicit service and forwarding sub-layer divisions exist in SRv6. Packet replication and elimination is indicated by SID functions and arguments. The forwarding sub-layer is fulfilled by the SID locators in segment list. Since draft-geng-detnet-dp-solv-srv6 is under progress, the authors will try to align the drafts with each other. 2, Contradicting packet replication rules Definition of replication entity contradicts RFC8964. Is it intentional? RFC8964 states that S-Label of outgoing member flows are defined by downstream receiver and may differ. "Note that S-Labels provide identification at the downstream DetNet service sub-layer receiver, not the sender." Fan1>> Agree. Since it relates to controller plane, we didn’t explicitly specify it in this draft. If necessary, we can add some explanations too. "In some PREOF topologies, the node performing replication ... may need to send different S-Label values for the different member flows for the same DetNet service." Whereas draft-geng-spring-sr-redundancy-protection states it differently: "Same S-Label is configured per outgoing member flow and encapsulated in every packet of flow." Fan1>> again, it is not intentional to have different specifications. I roughly updated section 4.1.1 Redundancy Segment in SR over MPLS with following texts, expected to be precise later. “In the case of SR over MPLS, IETF Deterministic Networking working group has defined the packet replication/Elimination/Ordering functions in MPLS data plane [RFC8964]. The support of redundancy protection in SR over MPLS data plane will keep consistent with the PREOF functions defined in [RFC8964]. To leverage more Segment Routing's capability, redundancy protection also provides additional means. The brief process includes: Explicit configuration (e.g. PCEP, YANG, etc.) is provisioned by the controller plane to specify the packet replication function on redundancy node. (specification of redundancy segment will be added later) The packets of a flow is replicated to multiple replicas and sent over different forwarding sub-layer LSPs. Each replicas may carry unique service label (S-Label) to identify per outgoing member flow. DetNet Control Word (d-CW) provides the space to encapsulate sequence number in SR over MPLS. Same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet. The length and value of sequence number defined in [RFC8964] are valid for redundancy protection in SR over MPLS. Note that a 0-bit length of Sequence Number field in d-CW would never be used in redundancy protection as it indicates that there is no sequence number.” 3, Limited to P2P connectivity (excluding DetNet (P2MP) scenarios?) Have You intentionally excluded using redundancy policy for DetNet scenarios? P2MP DetNet flows seem to be not supported. Last segment was defined as merging segment. "In redundancy policy, Redundancy Segment MUST be specified, and the last segment of each ordered list of segments MUST be Merging Segment." Fan1>> I must admit redundancy policy is more fit for SRv6 data plane. Whether to use it in SR-MPLS needs more thoughts. What is why I add the sentence with the underline mark in the text above. I think redundancy protection should obey the rules defined in RFC8964, but it can also be enhanced with SR capabilities. I’m afraid it is actually not the gap between redundancy protection and DetNet PRF/PEF, but the one between DetNet MPLS and DetNet SR-MPLS. The authors are appreciated more discussion and comments here. P2MP traffic is not excluded in redundancy protection. It doesn’t make any difference for replication and elimination, so it is not explicitly specified. We can add some text about it. I also mention this point in another thread discussed in SPRING ML. Could You please clarify? Thanks & Cheers Bala'zs
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
