Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

[Suresh Krishnan <[e-mail]>]

Hi Jingrong,
  Thanks for getting back on my suggestions. Please find responses inline.


> On Oct 7, 2022, at 12:04 AM, Xiejingrong (Jingrong) <[e-mail]> 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:[e-mail]] 
> Sent: Friday, September 30, 2022 4:46 AM
> To: Xiejingrong (Jingrong) <[e-mail]>
> Cc: Jen Linkova <[e-mail]>; 6man <[e-mail]>; [e-mail]; 6man Chairs <[e-mail]>; [e-mail]; [e-mail]
> 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) <[e-mail]> 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