Re: [spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14

Rishabh Parekh <rishabhp@gmail.com> Fri, 16 June 2023 23:49 UTC

Return-Path: <rishabhp@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 6820FC151524; Fri, 16 Jun 2023 16:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 mQdmAVaUuq8u; Fri, 16 Jun 2023 16:48:59 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 81854C151070; Fri, 16 Jun 2023 16:48:59 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-9829a5ae978so181161366b.2; Fri, 16 Jun 2023 16:48:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686959337; x=1689551337; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y1bPkzdjpeGl5KVwC7MR/ddlm6uTDH4n/NhuDLB/htA=; b=HgwcOlS2NUVPmu7Kd63yRYUVzy8ClDLW52IrQbN2mf075Zd8H40YJNRduuAz6y9tkI 0lVRhlhSACJj/NRJu91NAC952D19nj6q+ySnO9Y7HJaM838w0yi4H0BqOcYB8DwYoSTY gUvtBziLTi45ZEysTdn7qxayCsf4NIQX6wxIq95VCIRzl0Arpd9naMyz646k5B1ZXZ/K sHWTiH28whxOmjDwZxudcfggoa0YrEN9g57CkKYhoxrmWK9cnqAxmiT7LXAODCeQ//R6 /xnijRZN2Eh3bbaIDyIzdWr5I5h/CBzcW/Ety0mCDzK3zG2vobJvv6V7aIT9ZV9HJMEm vTdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686959337; x=1689551337; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y1bPkzdjpeGl5KVwC7MR/ddlm6uTDH4n/NhuDLB/htA=; b=Ng+sst/s2LxV8+coWJ8SmpwAtw8anaJU8scstH3x2irL+PBgvFv81ym9V36vNnLAxL g8SEzkEsL1PzNrRLEWtL+qG26eBjXe8ZJrl48V/ao1/iuh4BQQzTdVgaNN2qoiT2tj+X drdAifVG6+W9BuT8DXxsXy0sYAFDmMvZUqI0pZlwkS11ykTuo6ivHcNIN5ohmMh+pFbl a3X4qKoeorpRULW66YhHBnpTvNphUZU1IONwG3ZXEg096EVQyCZu04uzM6g7NwHlMF8C Vb3vSSIcWbADgQMJX2C5ac7zQ4APb5UI3Ujb+X+jCioRV+cN8K4qpK3lDdW6boOAPGLc NgKA==
X-Gm-Message-State: AC+VfDwnV0N3FivbtyiPbaPV2ttKWuGIu3dCxYVlfWffYf1lwltZbYA4 svit55aKN8NvTSqjVxQbdZb682qI7CkFiidCTu4ic6hEZbA=
X-Google-Smtp-Source: ACHHUZ6UCxbK8c4YJS23Etwp2W+pVhVHSeUYgk3KVrHBB00DuVc8dc940gQvrgfEUuLqp1QB+lYGAX3Xext4OoOpKko=
X-Received: by 2002:a17:907:9621:b0:982:8a28:ba24 with SMTP id gb33-20020a170907962100b009828a28ba24mr3826192ejc.63.1686959336870; Fri, 16 Jun 2023 16:48:56 -0700 (PDT)
MIME-Version: 1.0
References: <168694754378.21290.8223368158925884115@ietfa.amsl.com>
In-Reply-To: <168694754378.21290.8223368158925884115@ietfa.amsl.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Fri, 16 Jun 2023 16:48:45 -0700
Message-ID: <CABjMoXYzvSSKOAw=O8hT=tbrp2jNTPVg34vm3vZpsjwEugsUGQ@mail.gmail.com>
To: Wesley Eddy <wes@mti-systems.com>
Cc: tsv-art@ietf.org, draft-ietf-spring-sr-replication-segment.all@ietf.org, last-call@ietf.org, spring@ietf.org
Content-Type: multipart/alternative; boundary="00000000000006562205fe47d454"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/dHkWPlmHxmR-hPJUeZc5pTYOvsY>
Subject: Re: [spring] Tsvart last call review of draft-ietf-spring-sr-replication-segment-14
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, 16 Jun 2023 23:49:03 -0000

Wesley,
Thanks for the review.

The Replication function is performed by nodes within an SR domain. The
trust model of SR with traffic filtering at SR domain boundaries applies to
this document and is covered by the first sentence referring to security
considerations of RFCs 8402, 8986 and 8754.

I will add some text addressing comment (2).

As Joel mentioned, pseudo-code uses a convention introduced in SRv6 RFC
8986. I will add a reference to 8986 in Section 2.2.1.

-Rishabh




On Fri, Jun 16, 2023 at 1:33 PM Wesley Eddy via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Wesley Eddy
> Review result: Almost Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> (1) Since this defines a behavior where one incoming packet can create N
> outgoing packets, I was surprised that there is nothing mentioned in the
> security considerations about how access to replication nodes and ingress
> for
> them should be protected in order to prevent abuse.
>
> (2) The intended use seems mainly to be where some outer control system is
> responsible for making sure that the replication operation will put packets
> onto distinct network paths, and not create congestion either locally or on
> some potential shared network segment downstream.  It might be more clearly
> stated that it's assumed that building a proper multicast tree, managing
> group
> membership, and performing multicast congestion control need to be
> performed
> elsewhere.
>
> (3) I didn't recognize the syntax or pseudocode conventions in section
> 2.2.1;
> maybe this is common or defined somewhere else that could be referenced to
> be
> clear?
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>