[spring] John Scudder's Discuss on draft-ietf-spring-nsh-sr-12: (with DISCUSS and COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Tue, 25 April 2023 16:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF1AC14CE51; Tue, 25 Apr 2023 09:18:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-nsh-sr@ietf.org, spring-chairs@ietf.org, spring@ietf.org, bruno.decraene@orange.com, bruno.decraene@orange.com
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <168243949296.6004.17049168939225129111@ietfa.amsl.com>
Date: Tue, 25 Apr 2023 09:18:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ttvxAO-l4v8UoTugw2Ja-p9c4cU>
Subject: [spring] John Scudder's Discuss on draft-ietf-spring-nsh-sr-12: (with DISCUSS and COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 25 Apr 2023 16:18:13 -0000

John Scudder has entered the following ballot position for
draft-ietf-spring-nsh-sr-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this clean, easy-to-review document.

I do have one point I'd like to flag. I'm making this a DISCUSS to ensure the
IESG has a chance to discuss the point raised, and intend to clear after the
telechat.

In his review
(https://datatracker.ietf.org/doc/review-ietf-spring-nsh-sr-11-rtgdir-lc-bryant-2022-05-28/)
Stewart Bryant makes a good point:

```
There is one point that the IESG should ponder. The authors have asked for a IP
type assignment. This is a limited registry that needs to last the lifetime of
the IP protocol suite. NSH started its life 9 years ago and has been a standard
for 4 years and in all this time has not needed such as allocation. Neither
SRv6 nor NSH are petite or lightweight protocols. So I wonder if the
identification of NSH should happen at the IP layer as proposed, or whether an
intermediate multiplexing layer such as UDP should be used? The extra
processing for UDP is one test and the extra MTU is 8 octets. The decision for
the IESG is whether in their view the extent of deployment and the gain in
performance is such that they should authorise the allocation of the IP type.
```

AFAICT the argument against using a UDP encap is "it's more overhead" (which is
true, but I think Stewart's point is that the UDP overhead is pretty small as a
fraction of the SRv6 and NSH overheads). Anyway, it seems like it would be good
to at least consider this question.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Related to the DISCUSS question, it seems as though a few words would be in
order, early in the document, about the encapsulation. I do see (now that Jim
pointed it out to me OOB :-) that Section 11.1 requests an IP protocol number
from IANA, and the rest is arguably "obvious". Nonetheless, it seems worth a
few sentences.

Obviously, if Stewart's suggestion to move to a UDP encap were used, that would
also call for a few sentences to describe it.