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

[[e-mail]]

Hi Giuseppe,

Please see inline [Bruno]



Orange Restricted
From: spring <[e-mail]> On Behalf Of Giuseppe Fioccola
Sent: Thursday, February 9, 2023 12:34 PM
To: Greg Mirsky <[e-mail]>; Joel Halpern <[e-mail]>
Cc: SPRING WG List <[e-mail]>; 6man <[e-mail]>
Subject: Re: [spring] [IPv6] WG Adoption call for Segment Routing Header encapsulation for Alternate Marking Method

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.

[Bruno] True, but very possibly, the addition of TLV(s) in the SRH could also have "operational implications". E.g. the forwarding performance/packet drops could be affected; (unfortunately) SRv6 MSD Types are silent on the impact of TLV even though, realistic, this probably have an impact on some implementations... Would you have some data comparing the path with two extensions headers versus the path with TLV in SRH? If some could be shared in the draft this would probably be useful for the discussion.

Thanks,
Regards,
--Bruno

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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fz-spring-srv6-alt-mark&data=05%7C01%7Cbruno.decraene%40orange.com%7Ca890e71bc04a4812fe0c08db0a919f04%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638115392789738107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t%2FKvDV1%2FlKS%2FqaV6fajcN7UP15pJg8ZygUx4P7u0T1k%3D&reserved=0>

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<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=05%7C01%7Cbruno.decraene%40orange.com%7Ca890e71bc04a4812fe0c08db0a919f04%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638115392789738107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2F4q4quOPGzcTWX1N8BUpzL7Z8zHFtlvjdBJzsObLH%2B0%3D&reserved=0>
--------------------------------------------------------------------

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.