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

Hi Ketan,
Thank you for your comments.

I plan to revise the draft and add a new section on deployment recommendations.

Anyway, I think that the choice between DOH and SRH TLV may be a more general decision that should be taken by SPRING and 6MAN. Indeed, the same concern involves all the telemetry techniques, e.g. for IOAM the same two mechanisms have been proposed: see draft-ietf-ippm-ioam-ipv6-options and draft-ali-spring-ioam-srv6

Regards,

Giuseppe

From: spring <spring-bounces@ietf.org> On Behalf Of Ketan Talaulikar
Sent: Friday, February 17, 2023 12:46 PM
To: Joel Halpern <jmh@joelhalpern.com>
Cc: SPRING WG List <spring@ietf.org>; 6man <ipv6@ietf.org>
Subject: Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

Hi Joel/All,

I share some of the questions and concerns of the chairs and other WG members.

Perhaps we need to give more time to the authors to add clarifying text to the draft (what has been said on the list).

I suggest a dedicated section towards the start of the document that *only* focuses on why this mechanism is needed in addition to RFC9343. It would be interesting if there is any analysis from the implementation/deployment of RFC9343 that has shown it to be not suitable for SRv6 deployments.

Thanks,
Ketan

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