Re: [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

Hi Joel,

I support adoption of this document. I also feel that the motivation of why
use SRH AltMark TLV needs to be made explicit early on in the document.

Thanks!
Dhruv

On Thu, Feb 2, 2023 at 6:14 AM Joel Halpern <jmh@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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>