RE: Re:Fw:New Version Notification for draft-xiao-6man-srv6-checksum-00.txt

Hi Xiao,
You misunderstood me. I did not mean "one more 128-bit IPv6 address is inserted". I did not ask to insert anything additional.
I did mean that the last SID (whatever it may be, including End.DX6 SID) should be always uncompressed.
It is enough to keep RFC 8200 as it is.

The last SID is typically a service SID that should be 128bits anyway
Because function should be long (24-32bits) and argument is present.
It is not compressable anyway.
It is not a big restriction to standardize that it MUST not be compressed.

Moreover, by the Flag, you are asking the same: the last SID is uncompressed.

Eduard
-----Original Message-----
From: xiao.min2@zte.com.cn [mailto:xiao.min2@zte.com.cn] 
Sent: Monday, May 23, 2022 3:53 AM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: ipv6@ietf.org
Subject: Re:Fw:New Version Notification for draft-xiao-6man-srv6-checksum-00.txt

Hi Eduard,

Please see inline...

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：VasilenkoEduard
收件人：肖敏10093570;
抄送人：ipv6@ietf.org;
日 期 ：2022年05月20日 18:35
主 题 ：RE: Re:Fw:New Version Notification for draft-xiao-6man-srv6-checksum-00.txt
Hi Xiao,
Could we change the solution to this way:
"if SRH is present then the last SID should be always 128bits"
Then no need to standardize anything new (no need for a flag).
[XM]>>> No, I don't think we can do just that way. For example, when we want to Ping a compressed End.DX6 SID, if one more 128-bit IPv6 address is inserted as the last SID, then the End.DX6 processing defined in RFC 8986 would be broken.

RFC 8200 is already talking about how to calculate checksum in this situation.
Eduard
-----Original Message-----
From: xiao.min2@zte.com.cn [mailto:xiao.min2@zte.com.cn]
Sent: Friday, May 20, 2022 3:33 AM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: ipv6@ietf.org
Subject: Re:Fw:New Version Notification for draft-xiao-6man-srv6-checksum-00.txt
Hi Eduard,
Thanks for your review and good questions/comments.
Please see inline my responses with [XM]>>>.
Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：VasilenkoEduard
收件人：肖敏10093570;ipv6@ietf.org;
日 期 ：2022年05月19日 16:00
主 题 ：RE: Fw:New Version Notification for draft-xiao-6man-srv6-checksum-00.txt
Hi Authors,
The essence of the solution is to demand that "the last element of the SRH MUST be set to an IPv6 address (all 128 bits) of the final destination".
Then it would be possible to calculate the upper layer protocols checksum "as before" (by RFC 8200 that already request to include routing header entry[0] instead of the DA).
[XM]>>> Yes, absolutely correct.
1. I do not see the need for the flag. If entry[0] is always 128bits then no problem executing RFC 8200 as it is.
[XM]>>> Yes, you're right. If there is no compressed SIDs introduced, no need for the flag.
2. It is a restriction imposed upon SRv6 architecture. The new policy is proposed: "the last SRH entry is always 128bit long (non-compressed)"
I support it - the last entry in the SRH should have a function (1M services = 20bits has been already stressed for pseudowires at some deployments) and an argument for the service. Hence, not compressible anyway.
But such things are better to discuss in SPRING.
[XM]>>> The restriction defined in this document won't affect data traffic that just traverses SRv6 domain, what it affects are mostly(if not all) packets originated from an SRv6 router.
3. You did mention in the problem statement that "NEXT-C-SID doesn't contain Routing header, more than one C-SIDs are included in IPv6 Destination Address".
Then your solution does not work. Such C-SID could not be 128bits long. Hence, it could make a big debate in SPRING.
Do you propose a flag to avoid a solution for "NEXT-C-SID" case?
Is your solution relevant only for "REPLACE-C-SID flavor"?
[XM]>>> No, the solution defined in this document resolves both "NEXT-C-SID" and "REPLACE-C-SID" cases. In section 3.2 it says "if   the IPv6 packet doesn't contain an SRH while the Destination Address field contains more than one compressed SID, an SRH MUST be added with C-flag set and Segment List[0] set to a 128-bit IPv6 address of the final destination."
4. I do not understand the need for this draft because SRv6 is a tunneling protocol (IPv6 inside IPv6 by RFC 2473).
Do we need to check at intermediate nodes the checksum for the inner IPv6 packet?
As I understand, SRv6 PE does not check checksum for the inner IPv6 packet when attaching an additional IPv6 header.
Why the current practice is bad?
[XM]>>> As I said above, this solution won't affect data traffic that just traverses SRv6 domain, what it affects are mostly(if not all) packets originated from an SRv6 router, e.g., ICMPv6 packets.
Eduard
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of xiao.min2@zte.com.cn
Sent: Thursday, May 19, 2022 4:47 AM
To: ipv6@ietf.org
Subject: Fw:New Version Notification for draft-xiao-6man-srv6-checksum-00.txt
Hi all,
A new -00 individual draft has just been posted, the motivation is to provide a unified mechanism for SRv6 upper-layer checksum computation, whether SRv6 SIDs or SRv6 compressed SIDs are used.
Appreciate your review and comments.
Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：internet-drafts@ietf.org
收件人：Chongfeng Xie;刘尧00165286;肖敏10093570;刘尧00165286;
日 期 ：2022年05月19日 09:38
主 题 ：New Version Notification for draft-xiao-6man-srv6-checksum-00.txt
A new version of I-D, draft-xiao-6man-srv6-checksum-00.txt
has been successfully submitted by Xiao Min and posted to the IETF repository.
Name:        draft-xiao-6man-srv6-checksum
Revision:    00
Title:        SRv6 Upper-Layer Checksum
Document date:    2022-05-18
Group:        Individual Submission
Pages:        8
URL:            https://www.ietf.org/archive/id/draft-xiao-6man-srv6-checksum-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xiao-6man-srv6-checksum/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xiao-6man-srv6-checksum
Abstract:
This document provides a unified mechanism that makes the upper-layer checksum computation rule defined in IPv6 Specification applicable, whether SRv6 SIDs or SRv6 compressed SIDs are used.
The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------