Hi Cheng, Thanks a lot for your comments. Please find responses inline. > On Sep 29, 2022, at 11:49 PM, Chengli <c...@huawei.com> wrote: > > Thanks for Joel's reminder. My comments are below. > > 1. Document is informational, it may be incorrect. Standard tracks?
This was a point of discussion earlier but since the proposed change to SRH behavior was filed as an errata on RFC8754 there was no need for this to be Standards track. > 2. Avoid reference in Abstract. OK. > > 3. I-D.filsfilscheng-spring-srv6-srh-compression needs to be updated to > I-D.ietf-spring-srv6-srh-compression] Yes. I updated these in my working copy based on earlier comments. > > 4. Section 3.1. of [RFC8986] describes the format of an SRv6 SID as > composed of three parts LOC:FUNCT:ARG, where a locator (LOC) is > encoded in the L most significant bits of the SID, followed by F bits > of function (FUNCT) and A bits of arguments (ARG). > > more text is needed to specify that a SID is NOT a 128-bit value, but a > prefix with different mask. > > "A SID is a value where the length may be shorter than 128, and the rest bits > are padding as 0. Therefore, A SID is needed to be identified by the SID > value with it's structure instead of SID value only". After some discussions with Adrian upthread this is what the text looks like in my working copy. Does this work for you? " Section 3.1. of [RFC8986] describes the format of an SRv6 SID as containing three parts LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). If L+F+A < 128, the ARG is followed by enough zero bits to fill the 128 bit SID." > > > 5. Section 5 contained SRv6 domain? Single SRv6 domain or other words? Not sure what action is required here. Section 5 talks about SR domains in general. Can you please clarify if you want any changes here? > > 6. Section 5. Allocation of new address space. > > We know that a lot of networks have deployed SRv6 using their own GUA address > planning. If a new address space is allocated, then this MUST NOT be > mandatory in deployment, and it MUST be optional, otherwise unneeded > readdressing is needed, which is unacceptable for operators. > > Also, what kinds of address should be allocated? Should operators register > for it ?should be clarified in the draft I think. > > But considering we have clarified what is SRv6 SID, and why it has it's own > structure, the goal of the draft has been reached. We may not need to > allocate any specific address block for it further. The problem is what we > understand the SRv6 SID is, it does not affect the deployment at all. If > the problem has been solved, no need to introduce more complexities into SRv6 > deployment. No one will go to register for the prefix I guess because they > can use their own address to deploy SRv6 correctly. I agree. I also do not believe the use of this prefix needs to be mandatory and that the usage of this prefix need to be registered anywhere. Please let me know if there is such an implication in the draft or if you want to propose some text additions. Regards Suresh _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
