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

Suresh Krishnan <suresh.krishnan@gmail.com> Thu, 29 September 2022 20:46 UTC

Return-Path: <suresh.krishnan@gmail.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 5034BC1526F6; Thu, 29 Sep 2022 13:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 310iao5vbYYX; Thu, 29 Sep 2022 13:46:24 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A269C14F726; Thu, 29 Sep 2022 13:46:24 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id j10so1549240qtv.4; Thu, 29 Sep 2022 13:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date; bh=qxQFBgFxzAHvo+1MD2+8+LLzvmthWXhhX1ls0Phu0jI=; b=ETmOFpNSnuEqSBxNTuSZceQLG04en1F71neBLdDUvjPbQANElgN6RSAB0/33qmxb04 W0fpga2wqaPoHIjFmag7QxITKYlpW2HeLSb1oLbpBSt2sNgnx/Kz3LlkVVs5NqFlAyNH RhPE10mkf3iMEO+Vwm/yCLULAZ3qf+ixpDqLstqfK2SqY8UEJTzwf5rg4mLSjIT96Eft zjEWYuEdYIqKxeGksxjVutQpN8T9Zn89E5YLcD4qm6JKKSmSRtPbw3kUpVbmjR4wCk1B hjzkPg0Z4EMzN5jqRVrs6UVf6sS2Vy2KwYYlWsaPMp8Hk8nSXo2TvqazzCKLiq0Bosgm rMnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=qxQFBgFxzAHvo+1MD2+8+LLzvmthWXhhX1ls0Phu0jI=; b=Leqoulh11aaqOiyVfCrDw4adSzLj7cDmXoY/FsewRIcFltPuRJidlZboJd4/BCjPN0 MKhD92qg9LApDDwxZyQK8u+eFRnPi9sd0H6MfyekqquYV9axmSkk8VviO6Cl9Oca5VlH 5C3bkqpUm9x+cK8EjjXOS4gab1o0PWVMI5/lIdGSL4HNRXWsdwSewgdPL6HyT7Qzxhsf z207IobOFF0UCwRnSPm+/A9fyUX4H7rSho1jnDfI3XvE+kFBKpr7nUheh3wsXsF6jy7U Ym955mIOuf/neKRgf1ppwF3wsceCfnoEIXhFy1ooDjOVPcrU2enTSqZCcfaIOpWdY727 fuXg==
X-Gm-Message-State: ACrzQf2e0s/vx7kD2/h7UxDB3UwrKwPIp+/DLN6kRq8ey8zZofyDThO+ p1YoParnpZe/BRX8eNXlnzo/UPXK6AU=
X-Google-Smtp-Source: AMsMyM6NQTFDiY0b9rPKnurRMVwNGh6Tm8JHnx/BdPJgtfDnGethXUi2V/VydL7a+SixE7w69yxalQ==
X-Received: by 2002:ac8:58cf:0:b0:35c:c69b:4aa1 with SMTP id u15-20020ac858cf000000b0035cc69b4aa1mr4082178qta.355.1664484383082; Thu, 29 Sep 2022 13:46:23 -0700 (PDT)
Received: from smtpclient.apple (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id x22-20020a05620a0b5600b006ce7cd81359sm326434qkg.110.2022.09.29.13.46.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Sep 2022 13:46:21 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
From: Suresh Krishnan <suresh.krishnan@gmail.com>
In-Reply-To: <214efd0db6bc42b5be2fab5dde87d33b@huawei.com>
Date: Thu, 29 Sep 2022 16:46:20 -0400
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <89BBD3F7-D8C3-45D9-B60A-57CCC01214EE@gmail.com>
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <214efd0db6bc42b5be2fab5dde87d33b@huawei.com>
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/n8BXZu7Gu2zPNIiNYNnlaUCpFtc>
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: Thu, 29 Sep 2022 20:46:28 -0000

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.

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