Hi All, Looking at the last comments, I think that the draft can be revised by adding a new section on deployment recommendations. As already noted and specified in RFC 9343, the use of DOH + SRH is equivalent to SRH TLV but this approach requires two extension headers and it can have well-known operational implications, as further described in RFC 9098 and draft-ietf-6man-eh-limits. For this reason, the draft would recommend to integrate Alternate-Marking into SRH. This can mitigate the issues. In addition, it is reasonable and consistent to carry an information related to the SRv6 path inside the SRH. Since it is desired to have only one solution, in case of SRH there would be a single way to apply Alternate-Marking through SRH TLV. For all the other cases with IPv6 data plane the use of the HbH and DOH can be the only option to carry the Alternate-Marking data fields. The rule of DOH + RH must remain valid in RFC9343 because there is no guarantee that another RH has its own TLV as for SRH.
Regards, Giuseppe -----Original Message----- From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Aijun Wang Sent: Wednesday, February 15, 2023 7:25 AM To: 'Joel Halpern' <j...@joelhalpern.com>; 'SPRING WG List' <spring@ietf.org> Cc: '6man' <i...@ietf.org> Subject: Re: [IPv6] [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Hi, All: Support its adoption. But I have also the similar concerns about the comparative solutions for the general IPv6 and the specified SRv6 scenario. As said by Giuseppe during the adoption call, "DOH Option TLV+SRH" is same as the "SRH+SRH Option TLV" that defined in this document. Then I suggest that we select just one to accomplish the task. Putting the newly defined TLV into SRH to accomplish the task is more straightforward than the DOH+SRH based solution(RFC9343), then I recommend this document update RFC9343, eliminate the rule that defined in https://www.rfc-editor.org/rfc/rfc9343.html#section-4: "Destination Option preceding a Routing Header => every destination node in the route list" Also DELETE the rule that defined in https://www.rfc-editor.org/rfc/rfc8200#section-4.1 (Extension Header Order) for "Destination Option header(note 1)" note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. After the above updates, I think the community will be less confusion about the usage of DOH. That is to say, in future, the Option TLV that needs to be parsed along the nodes that listed in the routing header, should be included within the routing header itself. Best Regards Aijun Wang China Telecom -----Original Message----- From: spring-boun...@ietf.org <spring-boun...@ietf.org> On Behalf Of Joel Halpern Sent: Thursday, February 2, 2023 8:44 AM To: SPRING WG List <spring@ietf.org> Cc: 6man <i...@ietf.org> Subject: [spring] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method This call is for the draft at: https://datatracker.ietf.org/doc/draft-fz-spring-srv6-alt-mark This email starts the WG adoption call for the subject draft (as requested by the authors, with apologies from the WG chairs for how long it has taken to kick this out.) This call will run through the end of the day on Feb 16. Pleaes read the whole email as there are a few points, and it is not that long. Please comment on whether you think this topic is something you think the spring WG should work, whether you think this draft is a good starting point for such work, any issues or concerns you have, and whether you would be willing to help be contributing and / or reviewing the work if the WG does choose to work on it. 6man is copied for their information, as this is different from but related to an extension header proposal in front of 6man. Authors and named contributors, please confirm to the list that all known, relevant, IPR has been disclosed. If it has note, please remedy this gap. The spring chairs have noted one aspect of this draft that caught our eye, and we would appreciate WG members who comment on the adoption to consider, and if possible opine, on this. As we read this draft, as distinct from the related 6man extension header work, this causes the recorded altmarks to only be updated at routers identified in the SRH segment list. (We presume this would include all identified points in a compressed container.) We could not tell from the document what the value was for this as distinct from getting the measurements at all routers. Do WG members understand and agree that it does have value? As a lesser point, we consider that one quote in the draft is misleading and will likely need to be reworded in the near future. The draft say "SRH TLV can also be used to encode the AltMark Data Fields for SRv6 and to monitor every node along the SR path." It is unclear if these was intended to mean all routers (most of which would not see this TLV) or if it was intended to refer to only those routers identified in the SRH, in which case we presume it will be reworded. Thank you, Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
