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? 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." "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." 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." Could You please clarify? Thanks & Cheers Bala'zs
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
