[spring] 答复: DetNet data plane: some questions/comments about draft-geng-spring-sr-redundancy-protection

["Yangfan (IP Standard)" <[e-mail]>]

Hi Janos, Balazs and DetNet,
To Janos, thank you for clarifications on Segment Routing from DetNet’s perspective. I agree if SRv6 is going to be used for DetNet purpose, it should follow RFC8655. Actually I am not one of the authors of draft-geng-detnet-dp-solv-srv6, just personally interested in this topic. I was reminded during IETF 110 DetNet discussion, WG did talk about to how to continue the segment routing data plane. I think we can expect how it turns out.
To Balazs, personally I have no intention to define a new SR-MPLS data plane for DetNet in addition to MPLS for DetNet. Regarding how redundancy protection in SR follows RFC8964, we will think about it and come up with draft update. We can continue the discussion by then.
Thank you all again!

Best Regard,
Fan


发件人: Janos Farkas [mailto:[e-mail]]
发送时间: 2021年4月28日 3:54
收件人: Yangfan (IP Standard) <[e-mail]>
抄送: Balázs Varga A <balazs.a.varga=[e-mail]>; [e-mail]; spring <[e-mail]>
主题: RE: DetNet data plane: some questions/comments about draft-geng-spring-sr-redundancy-protection

Hi Fan,

Please find some comments related to the sub-layer violation in-line.

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.
[Janos Farkas]
Please note that draft-geng-detnet-dp-solv-srv6 is an individual contribution, not a specification = standard.

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.
[Janos Farkas]
I’m afraid it is problematic if the DetNet architecture (RFC 8655) is not followed by SRv6 for DetNet. If the SRv6 solution breaks the DetNet Service and the DetNet Forwarding sub-layers, then that is a violation of RFC 8655.
I understand that if SRv6 is intended to be use in other non-DetNet application areas, then no need to follow the DetNet architecture.
However, SRv6 for DetNet should follow the DetNet architecture.
Segment Routing is for the DetNet Forwarding sub-layer, i.e., to establish the Explicit Routes. This applies both data planes Segment Routing can be applied to, i.e., both to MPLS and IPv6.
As opposed, PREOF is at the DetNet Service sub-layer.
I think it would be good if SRv6 for DetNet would follow the DetNet architecture.

Best regards,
Janos


From: detnet <[e-mail]<mailto:[e-mail]>> On Behalf Of Yangfan (IP Standard)
Sent: Monday, April 26, 2021 4:10 PM
To: Balázs Varga A <balazs.a.varga=[e-mail]<mailto:balazs.a.varga=[e-mail]>>; [e-mail]<mailto:[e-mail]>; spring <[e-mail]<mailto:[e-mail]>>
Subject: [Detnet] 答复: DetNet data plane: some questions/comments about draft-geng-spring-sr-redundancy-protection

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:[e-mail]] 代表 Balázs Varga A
发送时间: 2021年4月23日 21:49
收件人: [e-mail]<mailto:[e-mail]>; spring <[e-mail]<mailto:[e-mail]>>
主题: [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