Hi Jingrong, Thanks for your detailed comments. Please find responses inline.
> On Sep 29, 2022, at 5:53 AM, Xiejingrong (Jingrong) <xiejingr...@huawei.com> > wrote: > > 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. I agree with both of your characterizations but in either of the cases, the outer IPv6 packet in question is what we are dealing with in 6man and the source address of the packet would be the address of the node that initiated the packet with SRH. Please let me know if this clarifies the point. > > Section 3 "[RFC8986] defines the Segment List of the SRH as a contiguous > array" > ==>Segment List should be Segments List (Segment change to Segments). From what I see in the pseudo-code line S14 in Section 4.1, 4.13 and 4.15 of RFC8986 I only see "Segment List[Segments Left]”. Can you please let me know where you are getting the “Segments List” terminology? > ==>[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. Isn’t that simply SRv6 endpoint behavior? Can you please clarify what you are looking for here. > > 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". Yes. Good point. I think it might be better to change this to Segment List as defined in RFC8754. > > 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. I am not sure there is a condition for "no Routing header to be present" for this sentence to be true. i.e. this holds true either way. > > 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 ? This is a work item intended for the C-SID draft and not this draft. There is an ongoing poll (started by Joel) in spring to see how this will be handled by the CSID draft. > > 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 ? This is more intended for SR domain border routers to prevent leaks and for non-SR-aware domains that might decide to filter ingress traffic from this space. > > 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 ? My personal view is that the usage of this prefix should not be mandatory. Thanks Suresh _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
