Hi Jingrong, Thanks for getting back on my suggestions. Please find responses inline.
> On Oct 7, 2022, at 12:04 AM, Xiejingrong (Jingrong) <xiejingr...@huawei.com> > wrote: > > Hi Suresh, > Sorry for the late reply due to a long holiday. Please see inline below > marked with [XJR]. No worries. Hope you had some time to relax. > Thanks, > Jingrong. > > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krish...@gmail.com] > Sent: Friday, September 30, 2022 4:46 AM > To: Xiejingrong (Jingrong) <xiejingr...@huawei.com> > Cc: Jen Linkova <furr...@gmail.com>; 6man <i...@ietf.org>; spring@ietf.org; > 6man Chairs <6man-cha...@ietf.org>; draft-ietf-6man-sids.auth...@ietf.org; > spring-cha...@ietf.org > Subject: Re: 6MAN WGLC: draft-ietf-6man-sids > > 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. > [XJR] OK. Great. > >> >> 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? > [XJR] Sorry I was confused. You are correct on "Segment List" and "Segments > Left". Sounds good. > >> ==>[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. > [XJR] My concern is that, when an SRv6 source node ping (RFC9259 ICMPv6-based > ping) a C-SID List encoded in DA (without an SRH in the packet), the ICMPv6 > checksum may be incorrect along the path until it reach the final destination > 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". > > Yes. Good point. I think it might be better to change this to Segment List as > defined in RFC8754. > [XJR] OK. > >> >> 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. > [XJR] Yes I mean in the condition that "no Routing header present" in a > packet, the destination address of the packet is changed by a segment > endpoint. Such behavior may not aligned well with RFC8200 ? See also the ping > case I mentioned above. Yes. The intent of the text from Section 4 you quoted above is to state that CSID changes the destination address similarly to when an SRH is present. I see your case is covered by the text. Please let me know if there is some alternate text that would clarify this and I will gladly make that change. > >> >> 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. > [XJR] OK to talk about draft-zhou-spring in spring thread. Sounds good. > >> >> 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. > [XJR] Agree. I would suggest that the motivation of allocating address space > is stated somewhere. Excellent. > >> >> 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. > [XJR] OK and thank you for sharing your opinions. OK. Regards Suresh _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
