[spring] Spring-Teas NRP inconsistency: draft-ietf-teas-nrp-scalability

Joel Halpern <jmh@joelhalpern.com> Wed, 29 May 2024 14:16 UTC

Return-Path: <jmh@joelhalpern.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 36E91C14F5EA; Wed, 29 May 2024 07:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 (1024-bit key) header.d=joelhalpern.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 VP9nZxunCx1C; Wed, 29 May 2024 07:16:00 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 17756C14E515; Wed, 29 May 2024 07:15:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4VqBHz5X6nz1prLS; Wed, 29 May 2024 07:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1716992159; bh=JPGoLZ2adGTmOfFZd6xACXMhyRmownTsUM8dhf3nJy0=; h=Date:To:Cc:From:Subject:From; b=Nn/DF4VTz7dIk5PExmXRy0SjC+oSuudSZWiP/jS1wZDgl3ntcyHFQPrjh/15C8Rbs 8Q+z8mGgHJrzWU6hlMxWuFNCUjp0iftV3t+8YFfwVJ+93tx0aNc+h/LOwsTXgyC6cC 53JHdrm82UxOPwmStWiAX8Y40+86ef6kfZUw8rCU=
X-Quarantine-ID: <bwPE4RWS77fR>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.22.41] (unknown [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4VqBHz2Pg2z1pKfL; Wed, 29 May 2024 07:15:59 -0700 (PDT)
Message-ID: <6741f832-1491-492b-8fc8-c884f674ca9f@joelhalpern.com>
Date: Wed, 29 May 2024 10:15:58 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "teas@ietf.org" <teas@ietf.org>
From: Joel Halpern <jmh@joelhalpern.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: KACEJVCWF3COUODLBKXBDMP5EBQAV7BN
X-Message-ID-Hash: KACEJVCWF3COUODLBKXBDMP5EBQAV7BN
X-MailFrom: jmh@joelhalpern.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: SPRING WG List <spring@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Spring-Teas NRP inconsistency: draft-ietf-teas-nrp-scalability
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/weDyVOuC5Vh1_3GRKvhI3nAcmk0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Looking at drafts, I noticed that draft-ietf-teas-nrp-scalability says 
that one is required (? expected? needs to?) use an NRP separate from 
the path control information.

However, the Spring adopted draft 
draft-ietf-spring-resource-aware-segments puts the NRP selection in the 
segment identifier(s).

If you tried to do both, you would have two conflicting representations 
for the NRP to be used in the same packet.  That seems problematic.

We need to somehow resolve this.

Yours,

Joel