After reading the document, I think this is worth to do, and the idea is valid in the case that IGP is not used, therefore I support the adoption. However, IMHO, the logic of the text may need some enhancement, I feel difficult in reading it, but this may be my problem.
Like Joel and others mentioned, it is important that this method is used within a TRUSTED domain. I would not say a single SRv6 domain, it depends on deployment actually, but please add some text to make sure that this mechanism is used within a trusted domain only. Some comments from Abstract to section 3. Abstract: In SRv6 network, locators need to be assigned to each SRv6 Endpoint, and segments are created based on locators. 1. s/SRv6 Endpoint/SRv6 Endpoint node? 1. Segments are NOT created BASED ON locators. Do you mean the Segment IDs are allocated from a address space of locator? This document describes the method of assigning locators to SRv6 Endpoints through DHCPv6. 1. s/the method/a method 2. s/Endpoints/endpoint nodes. If we confirm that endpoint nodes are correct, then you may need to replace all of them in the document. $2 Introduction Segment Routing (SR) allows a headend node to steer a packet flow along any path. Per-path states of Intermediate nodes are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. 1. What is ‘a packet flow’? 2. s/Intermediate/intermediate. Please avoid use ‘thanks to source routing’, it seems inappropriate to use ‘thanks to’ in a std draft, LOL. 3. The headend node steers a flow into an SR Policy. Steers ‘a flow’ into ‘an SR policy’ ? it seems weird. Please rephrase the logic. 1. ‘The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.’ Here, packets are used instead of a flow. 2. The logic of this paragraph seems not so clear, suggest to rephrase this paragraph. Also, this is quite irrelevant with the mechanism proposed in the draft, it might be ok to make it simple. s/As the identity of the endpoint/As an identity of the endpoint $3 Scenario for Locator Telecom provider use IP Metro network and Backbone network to realize the interconnection between access users in different regions. 1. Telecom providers or A telecom provider uses. However, I recommend to rephrase the sentence. Users in different regions are connected via X network and Y network? In the IP backbone network, deploy the network PE (PE-N) for access users in different regions and the cloud PE (PE-C) for the cloud. 1. Something wrong in this sentence, who deploys the network? Or do you mean network PEs are deployed for X, and cloud PEs are deployed for Y? or? 1. Terms like Network PE and Cloud PE should be defined before using. 1. IMHO, the logic of this section should be reorganized. Thanks, Li Cheng From: spring <spring-boun...@ietf.org> On Behalf Of Weiqiang Cheng Sent: Wednesday, July 19, 2023 10:12 AM To: Chongfeng Xie <chongfeng....@foxmail.com>; spring <spring@ietf.org> Cc: spring-chairs <spring-cha...@ietf.org> Subject: Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp Hi Chongfeng, Thanks a lot for your comments. My response can be found in line below, starting with the text [Weiqiang]. B.R. Weiqiang Cheng From: Chongfeng Xie<mailto:chongfeng....@foxmail.com> Date: 2023-07-17 14:34 To: spring<mailto:spring@ietf.org> CC: spring-chairs<mailto:spring-cha...@ietf.org> Subject: Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp Hi Weiqiang and other authors, I have reviewed the draft and have the following two comments: 1) In some cases, the CPE box of the current network is not a single device. It may be a combination of two levels of devices, for instances, one is an optical access gateway that supports IPv6 access, and the next level is a WiFi Router deployed by users to increase indoor coverage. They both support IPv6 functionality. Do you plan to consider this situation in the future draft? [Weiqiang] This draft primarily focuses on the SRv6 network within the operator's domain and does not currently address user-owned WiFi routers. We will make sure to explicitly mention this in the document to ensure readers understand the scope. 2) It seems technically feasible for CPE to access the BRAS of MAN through 4/5G, but it rarely be deployed in this way in practice, so I propose 4G/5G can be erased in section 3. [Weiqiang] Regarding the CPE accessing BRAS through 4G/5G networks, it is primarily aimed at the Fixed-Mobile Convergence (FMC) scenario. As far as I know, this scenario has been defined in BBF and implemented by some operators already. We will make the wording clearer in the draft to ensure accuracy. Best regards Chongfeng ________________________________ xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn> From: Weiqiang Cheng<mailto:chengweiqi...@chinamobile.com> Date: 2023-07-14 14:22 To: wangaijun<mailto:wangai...@tsinghua.org.cn>; aretana.ietf<mailto:aretana.i...@gmail.com>; spring<mailto:spring@ietf.org> CC: draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org<mailto:draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org>; spring-chairs<mailto:spring-cha...@ietf.org> Subject: Re: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp Hi Aijun, Thank you very much for your comments. We will add some text to describe that the CPE utilizes locators obtained through DHCP to provide differentiated services. Best Regards Weiqiang Cheng 发件人： Aijun Wang<mailto:wangai...@tsinghua.org.cn> 发送时间： 2023-07-14 11:19 收件人： 'Alvaro Retana'<mailto:aretana.i...@gmail.com>; spring@ietf.org<mailto:spring@ietf.org> 抄送： draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org<mailto:draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 主题： 答复: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp Support its adoption. It will be more convincible to add some descriptions in the document that the CPE itself needs to obtain different IPv6 address that can differentiate the services that it can provide. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: spring-boun...@ietf.org<mailto:spring-boun...@ietf.org> [mailto:spring-boun...@ietf.org] 代表 Alvaro Retana 发送时间: 2023年7月5日 20:00 收件人: spring@ietf.org<mailto:spring@ietf.org> 抄送: draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org<mailto:draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 主题: [spring] spring WG Adoption Call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp Dear WG: This message starts a two-week adoption call for draft-cheng-dhc-distribute-srv6-locator-by-dhcp, ending on July/19. It "describes the method of assigning locators to SRv6 Endpoints through DHCPv6". https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/ Please review the draft and consider whether you support its adoption by the WG. Please share any thoughts with the list to indicate support or opposition -- this is not a vote. If you are willing to provide a more in-depth review, please state it explicitly to give the chairs an indication of the energy level in the working group willing to work on the document. WG adoption is the start of the process. The fundamental question is whether you agree the proposal is worth the WG's time to work on and whether this draft represents a good starting point. The chairs are particularly interested in hearing the opinion of people who are not authors of the document. Thanks! Alvaro (for the Chairs) _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
