[spring] draft-ietf-spring-srv6-network-programming-10 - "3.1. SID Format" should be more prescriptive

Mark Smith <markzzzsmith@gmail.com> Wed, 26 February 2020 22:48 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 24F093A09AA; Wed, 26 Feb 2020 14:48:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Status: No, score=-0.599 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jeRyeRFwuLHh; Wed, 26 Feb 2020 14:48:12 -0800 (PST)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C093A09B0; Wed, 26 Feb 2020 14:48:12 -0800 (PST)
Received: by mail-pl1-x632.google.com with SMTP id y1so283584plp.7; Wed, 26 Feb 2020 14:48:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uApiUJpalcjlDFPrH5kB5UF2sxy7EuE0yUzPbXw5VnM=; b=CAFLnx6cn7M94OWu55oJMeueozT6nEjOnijlnR8BOebRZiJuNMDLdKl4CvQKgBqoxM hEJTSZ8pYUFOrdkDlplXx3XJS9vdN7GD3M2sQ9uyzbXGXzaemUdTqljodoSyuc0NjPP8 rV13eJP1f7Fv+bXBlnOmOv7jFoRJ9GrJLDj+EAMH5DtVOkvNU8eDHRP0m5PC+wFC9DDM Yx3k6P3/MZFaowC1V9gLKAGXd4rVT39ERv3x5yFx9zlyJZSocFaqnJKuas6sUPHbAavp +evlRHCnk4k/5kBFuye4tIyXMhwXevQ+hk2kfb13qcLeMY6xiDGKCESrC8xv7jOexqyH Id+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uApiUJpalcjlDFPrH5kB5UF2sxy7EuE0yUzPbXw5VnM=; b=qHB/pSxVnKFTsDZaeBlPTId5qBM9QEsSYuEdNVALhWbwy8EuSx/HdRyClfx27QrbR/ auIE1iSbqwcyukH6WMaa/Pr+pjMb06Ums92lUApPO8VTY4EKT1vTwTna4P2GdDXp5kSH 66X34kusEDqQqQLRgnh/axT556GNvSAOE5+xhWpW58qoSlU9LHhTg1Edjl2M9hN14xFi u0AEsLs01QtpSMjHBiuH7F30/PJSkGc4b8QFJcVB/VpqC6lr/Nr6jqFzSlNAe6zylo2g aaysmSKlMeIp3XyevUpQGd9Mv2dU6eE4h1MXBfTK7mGmZRTDo3i4ZWsqlqB5rhfD9TbD 6Emg==
X-Gm-Message-State: APjAAAU0uadeFu1xp/sBRLdjhaxs3TA0kv/MFzZrLQNORqoBJQW4MilO y/Krb4kSMYh0yOTOUkREsxMRXYVgCEGO51dsGOMGHweC
X-Google-Smtp-Source: APXvYqxZ2Vy8lYiEGCqQed6G9FRuyyjE02X0QlTAaVS1FY0+tzIn5A5w8awsnzfHs2zqq0C6y8L0OzAHsCI7J+LxnN8=
X-Received: by 2002:a17:90a:7303:: with SMTP id m3mr1502057pjk.62.1582757291170; Wed, 26 Feb 2020 14:48:11 -0800 (PST)
MIME-Version: 1.0
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 27 Feb 2020 09:47:45 +1100
Message-ID: <CAO42Z2x_sewSpOVorAD0FyJ9vM5c5tJNze+SJdwKY8vW-YtNgw@mail.gmail.com>
To: SPRING WG <spring@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k>
Subject: [spring] draft-ietf-spring-srv6-network-programming-10 - "3.1. SID Format" should be more prescriptive
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 26 Feb 2020 22:48:13 -0000


"3.1.  SID Format" presents the structure of SIDs as fairly arbitrary
and up to the operator to choose:

"This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128 then
   the reminder of the SID MUST be zero.

   A locator may be represented as B:N where B is the SRv6 SID block
   (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the
   identifier of the parent node instantiating the SID."

In abstract, for a 128 bit SID by itself, this would probably be fine.

However, as 128 bit SIDs eventually become commonly (always?) used as
IPv6 addresses in the forwarding plane and other places, I think it is
important that this section makes clear that there are also IPv6
addressing constraints on the SID formats and values.

A bit of a contrived example, however, somebody may start with a LOC
and FUNC of all zeros, and an ARG of 1 for convenience. That would
result in a SID of ::1, valid according to the above text, however is
also the loopback IPv6 address, which will not work in an IPv6 network
forwarding plane, and already has a function of looping packets back
to within the local sending node.

These IPv6 addressing constraints would be that SID structures and
values need to fit within the existing unicast address spaces (and
multicast if there are multicast SIDs?), not be from within a reserved
unicast IPv6 prefix unless appropriate, follow the structure of the
chosen address space (i.e. GUA, ULA or Link-Local prefix, subnet and
IID fields), and not used reserved IID values, as some of them already
have functional meaning, such as Mobile IPv6 Home-Agents anycast.

The text could be some general advice identifying these constraints,
as people who are planning IPv6 addressing should already be aware of
these IPv6 address planning constraints. Alternatively it could be
very explicit, providing references to e.g. RFC 4291, IANA registries

I think general advice would do, although explicit references might be
useful to reinforce that picking SID structure and values is also
picking IPv6 prefixes and addresses.

I can come up with some text and the references based on which
direction people think is best.