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

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Fri, 07 October 2022 04:04 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50359C159A25; Thu, 6 Oct 2022 21:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ary_TNzKzfob; Thu, 6 Oct 2022 21:04:51 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6898C14CF10; Thu, 6 Oct 2022 21:04:50 -0700 (PDT)
Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MkF62392Nz67bjw; Fri, 7 Oct 2022 12:03:22 +0800 (CST)
Received: from kwepemi500003.china.huawei.com (7.221.188.51) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 7 Oct 2022 06:04:48 +0200
Received: from kwepemi500004.china.huawei.com (7.221.188.17) by kwepemi500003.china.huawei.com (7.221.188.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 7 Oct 2022 12:04:46 +0800
Received: from kwepemi500004.china.huawei.com ([7.221.188.17]) by kwepemi500004.china.huawei.com ([7.221.188.17]) with mapi id 15.01.2375.031; Fri, 7 Oct 2022 12:04:46 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: Suresh Krishnan <suresh.krishnan@gmail.com>
CC: Jen Linkova <furry13@gmail.com>, 6man <ipv6@ietf.org>, "spring@ietf.org" <spring@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, "draft-ietf-6man-sids.authors@ietf.org" <draft-ietf-6man-sids.authors@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Thread-Topic: 6MAN WGLC: draft-ietf-6man-sids
Thread-Index: AQHYymu9RfEd/flgwE+Ro7fV0qG0/a32PGzggAAxrgCAC/AV0A==
Date: Fri, 07 Oct 2022 04:04:46 +0000
Message-ID: <ca7da054cf474bc4b071d1a5e1bb833b@huawei.com>
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <214efd0db6bc42b5be2fab5dde87d33b@huawei.com> <89BBD3F7-D8C3-45D9-B60A-57CCC01214EE@gmail.com>
In-Reply-To: <89BBD3F7-D8C3-45D9-B60A-57CCC01214EE@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.185.88]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/FHUEeG4jZv3x5LnKCZPeXzkbt0I>
Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2022 04:04:55 -0000

Hi Suresh,
  Sorry for the late reply due to a long holiday. Please see inline below marked with [XJR]. 
Thanks,
Jingrong.

-----Original Message-----
From: Suresh Krishnan [mailto:suresh.krishnan@gmail.com] 
Sent: Friday, September 30, 2022 4:46 AM
To: Xiejingrong (Jingrong) <xiejingrong@huawei.com>
Cc: Jen Linkova <furry13@gmail.com>; 6man <ipv6@ietf.org>; spring@ietf.org; 6man Chairs <6man-chairs@ietf.org>; draft-ietf-6man-sids.authors@ietf.org; spring-chairs@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) <xiejingrong@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. 

> 
> 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". 

> ==>[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.

> 
> 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. 

> 
> 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.

> 
> 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. 

Thanks
Suresh