Hi Joel & Shuping， In the 2024 MPLS SDN Interoperability Test (EANTC), for the SRv6 use case titled "Link Slicing over SRv6" (use case 3.21), the document https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/07/<http://ai.h3c.com/redirect?target=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cheng-spring-srv6-encoding-network-sliceid%2F07%2F> was employed to complete the cross-vendor source address slicing integration.
As the solution based on this draft is gradually maturing, we hope to discuss and present it in the SPRING working group. Thank you. I would like to request 10 minutes to present the new version of draft-cheng-spring-srv6-encoding-network-sliceid-09. Please help to arrange it into the agenda of the spring session. Title: Encoding Network Slice Identification for SRv6 URL: https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceid-09 length: 10min Presenter: Gongliyan/Changwang Lin Best Regards, Changwang ----邮件原文---- 发件人：linchangwang <linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com>> 收件人：Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>,"draft-cheng-spring-srv6-encoding-network-slic...@ietf.org<mailto:draft-cheng-spring-srv6-encoding-network-slic...@ietf.org>" <draft-cheng-spring-srv6-encoding-network-slic...@ietf.org<mailto:draft-cheng-spring-srv6-encoding-network-slic...@ietf.org>> 抄 送: "spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" <spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>> 发送时间：2023-04-19 09:15:30 主题：RE: I-D Action:draft-cheng-spring-srv6-encoding-network-sliceid-06.txt Hi Joel, Thanks a lot for your valuable comments. We will take this into consideration of the next revision. Thanks, Changwang -----Original Message----- From: Joel Halpern [mailto:j...@joelhalpern.com] Sent: Tuesday, April 18, 2023 11:16 PM To: linchangwang (RD); draft-cheng-spring-srv6-encoding-network-slic...@ietf.org<mailto:draft-cheng-spring-srv6-encoding-network-slic...@ietf.org> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: Re: I-D Action: draft-cheng-spring-srv6-encoding-network-sliceid-06.txt Thank you for the clarification. If I am understanding you properly, if the source address is used to indicate this, it is simply a subset of the operators addresses space (presumably on a bit boundary for operational reasons). It is not a fixed length field in the upper bits of the source IP address field. That is compatible. I hope that we will see clarification the next time you update the draft. Yours, Joel On 4/18/2023 11:06 AM, linchangwang wrote: > Hi Joel M. Halpern, > > Thank you very much for your comments. > My responses are inline. [Changwang] > > >> -----Original Message----- >> >> From: Joel Halpern [mailto:j...@joelhalpern.com] >> >> Sent: Tuesday, April 18, 2023 10:28 PM >> >> To: >> draft-cheng-spring-srv6-encoding-network-slic...@ietf.org<mailto:draft-cheng-spring-srv6-encoding-network-slic...@ietf.org> >> >> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> >> >> Subject: Re: I-D Action: >> draft-cheng-spring-srv6-encoding-network-sliceid-06.txt > > As this is still an individual draft, you may consider these comments as > individual input. I believe if you move to advance this document, we > will face serious difficulties with the proposal as it is. > > Your draft proposes two places to put an indication that a slice ID is > in use, and then proposes to put the slice ID in the lower portion of > the source address field. While I foresee difficulties with the latter > aspect, that will be up to the working group. > > One proposal is to place the SPI (indicator the a Slice ID is in use) in > the Traffic class field. That will break the forwarding in any > non-upgraded router in the forwarding path. While there are use cases > for NRPs that require all routers in the path to be upgraded, there are > also use cases for slicing (and hence presumably for slice identifiers) > that do not have those requirements. > [Changwang] : The encoding of the SPI in the Traffic class field is governed > by local > policy and uniform within the SR domain. > Only for packets entering this SRv6 domain, when adding SRv6 encapsulation, > the SPI bit in Traffic class field of the source address of the newly added > IPv6 header needs to be set for network slicing service. > > Your second proposal is to place the SPI in the upper bits of the source > IPv6 address of the header. That will cause the source IP address to > not be a properly assigned IPv6 address. That will violate multiple > RFCs, and break necessary network functionality. > [Changwang] : > The description here is not very clear. The SPI bit is not defined in the > source address. > It is to plan an IPv6 source address network segment locally to indicate > that this network segment can carry slices in the lower part. > The IPv6 source address used as the network slice source address may > have the following format: > +--------------+-------------+-------------+--------+ > | SPI Prefix | Node ID | Padding | SLID | > +--------------+-------------+------------+---------+ > It is not to set the SPI bit to the high bit of the source address. > By planning a specific source address network segment, it indicates that the > lower 32 bits of this source address network segment carry network slice > identification. > The source address network segment is planned through configuration, ensuring > consistency throughout the entire SR network slice domain. > The definition of IPv6 addresses has not been changed, only an address > segment has been planned to carry slices. > > > >> Yours, >> Joel M. Halpern, speaking as an individual > > > Thanks, > Changwang > > > On 4/17/2023 9:41 PM, > internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Encoding Network Slice Identification for SRv6 >> Authors : Weiqiang Cheng >> Guangming Yang >> Changwang Lin >> Liyan Gong >> Shay Zadok >> Mingyu Wu >> Xuewei Wang >> Filename : 06.txt >> Pages : 8 >> Date : 2023-04-17 >> >> Abstract: >> This document describes a method to encode network slicing >> identifier within SRv6 domain. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceid-06 >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-encoding-network-sliceid-06 >> >> Internet-Drafts are also available by rsync at >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> I-D-Announce mailing list >> i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from New > H3C, which is > intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender > by phone or email immediately and delete it! Subject：RE: I-D Action:draft-cheng-spring-srv6-encoding-network-sliceid-06.txt Hi Joel, Thanks a lot for your valuable comments. We will take this into consideration of the next revision. Thanks, Changwang -----Original Message----- From: Joel Halpern [mailto:j...@joelhalpern.com] Sent: Tuesday, April 18, 2023 11:16 PM To: linchangwang (RD); draft-cheng-spring-srv6-encoding-network-slic...@ietf.org<mailto:draft-cheng-spring-srv6-encoding-network-slic...@ietf.org> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: Re: I-D Action: draft-cheng-spring-srv6-encoding-network-sliceid-06.txt Thank you for the clarification. If I am understanding you properly, if the source address is used to indicate this, it is simply a subset of the operators addresses space (presumably on a bit boundary for operational reasons). It is not a fixed length field in the upper bits of the source IP address field. That is compatible. I hope that we will see clarification the next time you update the draft. Yours, Joel On 4/18/2023 11:06 AM, linchangwang wrote: > Hi Joel M. Halpern, > > Thank you very much for your comments. > My responses are inline. [Changwang] > > >> -----Original Message----- >> >> From: Joel Halpern [mailto:j...@joelhalpern.com] >> >> Sent: Tuesday, April 18, 2023 10:28 PM >> >> To: >> draft-cheng-spring-srv6-encoding-network-slic...@ietf.org<mailto:draft-cheng-spring-srv6-encoding-network-slic...@ietf.org> >> >> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> >> >> Subject: Re: I-D Action: >> draft-cheng-spring-srv6-encoding-network-sliceid-06.txt > > As this is still an individual draft, you may consider these comments as > individual input. I believe if you move to advance this document, we > will face serious difficulties with the proposal as it is. > > Your draft proposes two places to put an indication that a slice ID is > in use, and then proposes to put the slice ID in the lower portion of > the source address field. While I foresee difficulties with the latter > aspect, that will be up to the working group. > > One proposal is to place the SPI (indicator the a Slice ID is in use) in > the Traffic class field. That will break the forwarding in any > non-upgraded router in the forwarding path. While there are use cases > for NRPs that require all routers in the path to be upgraded, there are > also use cases for slicing (and hence presumably for slice identifiers) > that do not have those requirements. > [Changwang] : The encoding of the SPI in the Traffic class field is governed > by local > policy and uniform within the SR domain. > Only for packets entering this SRv6 domain, when adding SRv6 encapsulation, > the SPI bit in Traffic class field of the source address of the newly added > IPv6 header needs to be set for network slicing service. > > Your second proposal is to place the SPI in the upper bits of the source > IPv6 address of the header. That will cause the source IP address to > not be a properly assigned IPv6 address. That will violate multiple > RFCs, and break necessary network functionality. > [Changwang] : > The description here is not very clear. The SPI bit is not defined in the > source address. > It is to plan an IPv6 source address network segment locally to indicate > that this network segment can carry slices in the lower part. > The IPv6 source address used as the network slice source address may > have the following format: > +--------------+-------------+-------------+--------+ > | SPI Prefix | Node ID | Padding | SLID | > +--------------+-------------+------------+---------+ > It is not to set the SPI bit to the high bit of the source address. > By planning a specific source address network segment, it indicates that the > lower 32 bits of this source address network segment carry network slice > identification. > The source address network segment is planned through configuration, ensuring > consistency throughout the entire SR network slice domain. > The definition of IPv6 addresses has not been changed, only an address > segment has been planned to carry slices. > > > >> Yours, >> Joel M. Halpern, speaking as an individual > > > Thanks, > Changwang > > > On 4/17/2023 9:41 PM, > internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Encoding Network Slice Identification for SRv6 >> Authors : Weiqiang Cheng >> Guangming Yang >> Changwang Lin >> Liyan Gong >> Shay Zadok >> Mingyu Wu >> Xuewei Wang >> Filename : 06.txt >> Pages : 8 >> Date : 2023-04-17 >> >> Abstract: >> This document describes a method to encode network slicing >> identifier within SRv6 domain. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-cheng-spring-srv6-encoding-network-sliceid/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-cheng-spring-srv6-encoding-network-sliceid-06 >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-srv6-encoding-network-sliceid-06 >> >> Internet-Drafts are also available by rsync at >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> I-D-Announce mailing list >> i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from New > H3C, which is > intended only for the person or entity whose address is listed above. Any use > of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender > by phone or email immediately and delete it!
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
