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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
