Hey all, thank you for your work on this topic. I am Etienne Zink from the University of Tübingen. I am a colleague of Fabian Ihle (who also commented on the draft) and also working in the resilience project that includes a PREOF prototype. I read your draft and think that the general concept is clear and understandable.
Compared to the DetNet drafts I have the following comments/questions: "Redundancy Protection": For me this sounds like protecting the redundancy and not using redundant paths for service protection. "i.e., multiple copies of the data packets are sent on different paths to provide protection." (Abstract) -> in the remainder it is stated that the paths need to be disjoint. Maybe this should be included in the abstract as well. "This mechanism is commonly referred to as Live-Live as data traffic is forwarded on the protection paths simultaneously." And "Redundancy protection provides ultra reliable protection to many services, for example Cloud VR/Game, IPTV service and other type of video services, high value private line service etc." (1. Introduction) -> I think the draft would benefit if why a "Live-Live" approach is taken would be stated earlier in the introduction. Further, you could state the reduced end-to-end latency and jitter that the Live-Live approach introduces. "Figure 1 shows an example of redundancy protection used in an SRv6 domain." (3. Redundancy Protection in Segment Routing Scenario) -> DetNet RFC 8655 Figure 1. shows a scenario with multiple replications and eliminations. In this draft, only the appendix shows that this could also be done with Redundancy Protection. But for me personally, the appendix is bonus. I think the draft would benefit if the applicability of combining multiple replications after each other would be explicitly stated in the main document. Further, it needs to be clarified how the protection has to be applied. Currently, each Rep node adds its own SN. But probably successive Rep nodes should continue using the one that is already present? "This packet meta data is included on each of the replicas at the redudancy node." (3. Redundancy Protection in Segment Routing Scenario) -> In DetNet the SN needs to be added at or near the sender. Why does Redundancy Protection use a different approach? As mentioned in my 4th comment, this could cause problems with successive Rep nodes. "Flow-ID (FID): defines which flow the packet belongs to" (4.1. Redundancy Segment Endpoint Behavior) -> I think this suggests that each member flow has the same FID. But the example in "4.2.1. H.Encaps.R: SR Headend with Redundancy" shows that each member flow can have a different FID (Flow-ID1 vs Flow-ID2). It should be clarified, whether member flows have to have the same FID or if FIDs can differ between member flows. "Sequence Number (SN)" (4.1. Redundancy Segment Endpoint Behavior) -> It only mentions the sizes of DetNet MPLS data plane. Does this suggest using the same sizes in Redundancy Protection? Or can the SN have an arbitrary size that is configured by a controller? "Member flow" (4.2.1. H.Encaps.R: SR Headend with Redundancy) -> This concept is borrowed from DetNet but never officially introduced in this draft. I think the draft would benefit by either linking to the concept in the respective RFC or shortly state what a member flow (and maybe compound flow) is. "S05. <N/A>" (4.2.3. H.Encaps.R.L2: H.Encaps.R Applied to Received L2 Frames) -> Is it intentional <N/A>? "Unlike the flow identification, which remains constant for a given flow […]" (5. Meta Data to Support Redundancy Protection) -> See my 6th comment: This contradicts the example in "4.2.1. H.Encaps.R: SR Headend with Redundancy". Best, Etienne -- Mr. Etienne Zink University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Room: B303, Sand 13, 72076 Tuebingen, Germany Phone: +49 7071 29-70545 E-Mail: [email protected] <mailto:[email protected]> LinkedIn: www.linkedin.com/in/etienne-zink <http://www.linkedin.com/in/etienne-zink> Website: http://kn.cs.uni-tuebingen.de <http://kn.cs.uni-tuebingen.de/>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
