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

[Giuseppe Fioccola <[e-mail]>]

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 <[e-mail]>
Sent: Friday, February 10, 2023 2:11 AM
To: Giuseppe Fioccola <[e-mail]>
Cc: Joel Halpern <[e-mail]>; SPRING WG List <[e-mail]>; 6man <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,
Thank you for your comments.
Please find my replies inline tagged as [GF].

Regards,

Giuseppe


From: ipv6 <[e-mail]<mailto:[e-mail]>> On Behalf Of Greg Mirsky
Sent: Thursday, February 9, 2023 3:41 AM
To: Joel Halpern <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG List <[e-mail]<mailto:[e-mail]>>; 6man <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------