Hi Greg, It is a good suggestion. A new section with recommendations and deployment considerations would help. We can surely add it in the next revision.
Regards, Giuseppe From: Greg Mirsky <gregimir...@gmail.com> Sent: Friday, February 10, 2023 6:10 PM To: Giuseppe Fioccola <giuseppe.fiocc...@huawei.com> Cc: Joel Halpern <j...@joelhalpern.com>; SPRING WG List <spring@ietf.org>; 6man <i...@ietf.org> Subject: Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Hi Giuseppe, would you propose a text that can guide developers and operators through the implementation and deployment of the Alternate Marking in IPv6 and SRv6 scenarios? Perhaps as Operational Considerations? Thank you for pointing out two IOAM specifications. I agree with you that our discussion and arguments apply to IOAM in IPv6 and SRv6 work. Regards, Greg On Fri, Feb 10, 2023 at 12:45 AM Giuseppe Fioccola <giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com>> wrote: Hi Greg, I think that this draft for SRv6 can recommend to integrate AltMark into SRH, since this can mitigate the issues. But the choice between DOH and SRH TLV should be a more general decision taken by the WGs. Indeed, the same question involves all the on-path telemetry techniques, e.g. for IOAM there would be the same two mechanisms as well: see draft-ietf-ippm-ioam-ipv6-options and draft-ali-spring-ioam-srv6. Regards, Giuseppe From: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> Sent: Friday, February 10, 2023 2:11 AM To: Giuseppe Fioccola <giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com>> Cc: Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; 6man <i...@ietf.org<mailto:i...@ietf.org>> Subject: Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Hi Giuseppe, thank you for your thoughtful responses. I have one more question to what you've said in the conclusion: So, if accepted, in case of SRH there would be a single way to apply Alternate-Marking through SRH TLV, while for all the other cases with IPv6 data plane the use of the HbH and DOH is the only choice to carry the Alternate-Marking data fields. Do you propose that in an SRv6 environment, RFC 9343 must not be used? If that is the case, I think that the draft must clearly state that and describe how it updates RFC 9343. If I misunderstood you, then I cannot see how to avoid the situation of both methods (RFC 9343 and the draft under consideration) being supported and used in the SRv6 network. Two mechanisms, in my opinion, create unnecessary problems for vendors and operators. Regards, Greg On Thu, Feb 9, 2023 at 3:34 AM Giuseppe Fioccola <giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com>> wrote: Hi Greg, Thank you for your comments. Please find my replies inline tagged as [GF]. Regards, Giuseppe From: ipv6 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> On Behalf Of Greg Mirsky Sent: Thursday, February 9, 2023 3:41 AM To: Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; 6man <i...@ietf.org<mailto:i...@ietf.org>> Subject: Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method Dear Authors, et al, I read the draft and have several questions: * It seems like the main motivation for this document is enabling the Alternate Marking method of collecting the operational state information, and on-path performance measurements in an SRv6 domain exclusively at SR segment endpoint nodes excluding transit nodes. Is that correct? [GF]: It is supposed that all the transit routers are not required to handle the SRH TLV. But this may also depend on the implementation, and if a transit router reads the SRH TLV, the measurement can also be done on that node. * As I understand it, processing of the Alternate Marking is not critical, i.e., a node may not process the marking information and forward the marked packet. Do you agree? [GF]: Yes, it is one of the main advantages of the Alternate-Marking Method * Now, if both my assumptions above are correct, then I imagine that the Alternate Marking method can be used exclusively on SR segment endpoint nodes if only these nodes and not transit nodes are configured accordingly. I agree that using SRH for the Alternate Marking on-path telemetry may provide some improvement in processing marked packets compared to marking per RFC 9343, I am concerned by the additional complexity of implementing and supporting two methods since both can be used in an SRv6 domain. I believe that it is better to have one solution and there's one defined in RFC 9343 already. [GF]: In theory, the use of DOH + SRH, as specified in RFC 9343, is equivalent to SRH TLV. But, the approach with DOH + SRH requires two extension headers and this can have operational implications, as described in RFC 9098 and draft-ietf-6man-eh-limits. I agree that the final goal is to have only one solution. So, if accepted, in case of SRH there would be a single way to apply Alternate-Marking through SRH TLV, while for all the other cases with IPv6 data plane the use of the HbH and DOH is the only choice to carry the Alternate-Marking data fields. Regards, Greg On Wed, Feb 1, 2023 at 4:44 PM Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> wrote: 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto: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
