Hi WG, I've reviewed this document and think it is ready for WG adoption. The proposed mechanism is mostly suitable for SRv6 networks, where usually the measurement on only the segment endpoints is needed, thus the overhead on the transit nodes can be reduced.
Best regards, Jie > -----Original Message----- > From: ipv6 [mailto:ipv6-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: [IPv6] 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 > > -------------------------------------------------------------------- > 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
