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? - 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? - 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. Regards, Greg On Wed, Feb 1, 2023 at 4:44 PM Joel Halpern <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 > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
