[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

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
Precedence: list

Hi,

"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
etc.

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.

Regards,
Mark.

[spring] draft-ietf-spring-srv6-network-programmi… Mark Smith