Hi working group: I have a few comments/questions on the draft (Marked with ==> in the beginning of a line).
Section 1 "SR source nodes initiate packets with a segment identifier in the Destination Address of the IPv6 header". ==>SR source node may be a host originating a packet ... ==>SR source node may be a border router of an SRv6 domain encapsulating a received packet and transform it an SRv6 packet ... ==>Therefore I would suggest this sentence to be more aligned with RFC8402/8754/8986. Section 3 "[RFC8986] defines the Segment List of the SRH as a contiguous array" ==>Segment List should be Segments List (Segment change to Segments). ==>[RFC8986] does not defines the Segments Left of SRH, but refer it to RFC8200, which defines the Segments Left of any kind of RH. Section 3 "One of the key questions to address is how these SRv6 SID appearing as IPv6 Destination Addresses are perceived and treated by transit nodes". ==>I am wondering that if this is also a question need to consider: how a packet with the SRv6 SID appearing as IPv6 DA may be treated by an SRv6 endpoint node or even SRv6 source node. Section 4 "The C-SID document describes how to use a single entry in the SRH list as a container for multiple SIDs ..." ==>The term "SRH list" is not appeared in the document, or other SRv6 RFCs 8402/8754/8986. I am assuming it is "SID List". Section 4 "The destination address field of the packet changes at a segment endpoint in a way similar to how the address changes as the result of processing a segment in the SRH". ==>Assuming this sentence is describing the change of destination address of a packet without an SRH at segment endpoint, there is a question: ==>RFC8200 says in the end of section 3, explaining the meaning of Destination address of an IPv6 header: "128-bit address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing header is present). See [RFC4291] and Section 4.4." ==>Does this document need to clarify on this ? That is to say, when there is no Routing Header present, but the destination address of a packet is changed by a segment endpoint. Section 4.1 "This draft needs to provide an updated definition for the SegmentsLeft field of the SRH" ==>SegmentsLeft should change to Segments Left. ==>Since Segments Left defined in RFC8200 is to be updated, should this document be standard track and marked with updating RFC8200 ? ==>Also since segments left is to be updated, should these also be considered: https://www.rfc-editor.org/errata/eid7081 and draft-zhou-spring-srh-le-change ? Section 5 " it might be prudent to allocate some address space that explicitly signals that ..." ==>Considering that, SRv6 node may be a router or a host, and signals may be more preferred for router but less preferred for host. Does this need to be clarified ? Section 6 "IANA is requested to assign a /16 address block" ==>Is this a determined proposal to use a /16 address block from "Reserved by IETF" range of IPv6 address space ? Will such a usage be mandatory or optional for compressed-SRv6 only or even for all SRv6 ? Thanks Jingrong 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments may contain confidential information from HUAWEI, 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! -----Original Message----- From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Jen Linkova Sent: Saturday, September 17, 2022 4:00 PM To: 6man <i...@ietf.org>; spring@ietf.org Cc: 6man Chairs <6man-cha...@ietf.org>; draft-ietf-6man-sids.auth...@ietf.org; spring-cha...@ietf.org Subject: 6MAN WGLC: draft-ietf-6man-sids Hello, This email starts the 6man Working Group Last Call for the "Segment Identifiers in SRv6" draft (https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids). The WGLC ends on Tue, Oct 4, 23:59:59 UTC. As the document is closely related to the work in the SPRING WG, we'd like the SPRING WG to review the document and discuss the following questions: - the action items required from SPRING (Section 4.1 and 4.2 of the draft, https://datatracker.ietf.org/doc/html/draft-ietf-6man-sids-01#section-4) [*]. Would it make sense to merge those open issues with the 'Open Issues' section of the SPRING document? - whether the document needs more guidance regarding routability of /16 or such requirements shall belong to some other document? In particular, shall we specify that it MUST NOT be in the DFZ? Or setting 'Globally Reachable = false' in the registry should be sufficient? The current idea is that the prefix needs to fail closed and not be routable by default. [*] The draft currently refers to the individual submission instead of https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ - the link will be updated in the next revision. Please review the draft and send your comments to the list/ -- SY, Jen Linkova aka Furry -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
