Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[Erik Kline <[e-mail]>]

[replying on this thread as is has more folks cc'd]

Joel,

First: thank you to everyone who has commented, clarified, sat for
meetings, and reviewed and edited text, often repeatedly.  It is very much
appreciated.

This reply is on behalf of the 6MAN chairs and INT ADs.

-- Erik, Éric, Bob, Ole

[1] Does the placement of a list of SIDs in the IPv6 DA field change the
IPv6 architectural description of that field?

It is understood that from the perspective of an IPv6 transit node the DA
field remains a valid DA, and from the perspective of an SR-aware node the
DA remains a SID of the LOC:FUNC:ARG form of RFC 8986.  On the surface,
then, these would not appear to represent any change to the IPv6 data plane
from currently published specifications.  However, this new category of
address seems as though it can in fact go against current specifications in
certain circumstances.

SIDs of the RFC 8754 and RFC 8986 form can reasonably be expected to obey
general unicast semantics: RFC 8986 section 4.1.1 permits Endpoint handling
of any inner payload type that is “allowed by local configuration” and even
explicitly gives the example of “an operator might permit pinging of SIDs.”
 In the case of ICMPv6 Echo Replies specifically RFC 4443 section 4.2
places requirements on the source address of the reply: it MUST be a
unicast address and MUST be the same as the DA if the DA was unicast
otherwise another unicast SA is chosen if the DA was an anycast or
multicast address.

In the SR C-SID topology A--B--C--D, sending a ping from A to D, could in
theory be done two ways: (1) ping D via SR policy B,C or (2) ping
LOC:FUNC:B:C:D (the SID of B with a set of CSIDs as the argument). In the
first case the ping is sent to the final destination D, via an SR path. In
the second case, the ping is sent to the final destination LOC:FUNC:B:C:D.
The IPv6 destination address as observed on the wire between A and B
(LOC:FUNC:B:C:D) and on reception at D (D::) will be the same in both
cases.  In the first case, the ICMP checksum based on address D is valid
and an ICMP reply will be sent from D to A.  In the second case though, the
ICMP echo request packet will have an invalid ICMP checksum and will be
dropped.

Can an IPv6 destination address when it's a C-SID (an “End with Next SID
arguments”) behave like a normal IPv6 end-point? Based on this, we may have
some new category of addresses and we feel the characteristics of SRv6
C-SID addresses should be more clearly defined.  We think that any
architectural issues can be resolved with such a document as outlined in
[A] below.

[2] Does the operation of shifting information around in the IPv6
destination address field represent a modification or extension of the IPv6
data plane?

The use of a SID with an ARG with a series of C-SIDs to generate the next
SID (a.k.a. “shifting”) form of compression (NEXT-C-SID) has an additional
deviation from the expected behavior of unicast addresses in the IPv6 data
plane, primarily by introducing a mechanism that achieves the objectives of
an SRH without requiring the presence of an SRH (section 4.1 of RFC 8754)
or without requiring the existence of Segment List in an attached SRH
(reduced SRH per section 4.1.1 of RFC 8754).

With existing SIDs, with REPLACE-C-SID behavior, and with NEXT-C-SID
behavior with a complete SRH, an ICMP error packet generated in response
to, for example, a traceroute packet with an attached SR policy can
trivially be correlated by the error receiver if the invoking packet
payload contains a sufficient portion of the SRH (section 5.4 of RFC 8754).

In the case of C-SIDs, the original sender can correlate the ICMP error by
doing a lookup in the segment prefix list of the SRH or in the DA and
finding the last SID representing the final destination as the final
destination is guaranteed to always be present even in the absence of SRH.
The behavior required of the original sender needs to be described in the
C-SID draft.

Beyond the concerns and questions raised in this response so far, within an
SR domain or set of cooperating SR domains, where restrictions on behavior
can be clearly defined and documented, these changes are limited to the
SRv6 data plane.

To summarize: we do not object to C-SID behavior work continuing in SPRING,
we simply need a clarifying document described in [A].

---

Next steps for consideration:

[A] A separate 6MAN document to clarify and categorize SRv6 SIDs is
needed.  We are happy to work to find authors for this document.

The document should explain SIDs’ deviation from RFC 4291 (probably
likening them to other addresses within prefixes handled by some virtual
network function, like NAT64 prefixes, and clarify that they are not
assigned to an interface) and capture many of the observations like those
in Brian Carpenter’s recent email [BC].  We think the document should also
clarify when a SID can appear in the Source Address field vs. when it can
only appear in the Destination Address field, and whether such a
distinction should exist. It should describe the behaviour of IPv6
addresses in the case of C-SIDs (SIDs “End with Next SID args”). The
document should also make it clear which parts are documenting existing
behavior of RFC 8754 and RFC 8986 SIDs -- therefore not really up for
extended debate -- and hopefully lay the framework for understanding any
future categories of SIDs (like whatever is coming at us next after C-SIDs)
that are in development.

This proposed “SRv6 SID Addressing Clarifications” 6MAN document should be
a normative reference for final C-SID publication.

[B] We think there are also operational considerations that warrant
attention prior to standardization.  Primarily we are concerned that there
is no analog to the SRH. SegmentsLeft field, i.e., no “compressed segments
left” field. The definition of the SRH.SegmentsLeft field points to the
definition from RFC 8200 section 4.4, which says it’s the “number of
explicitly listed intermediate nodes still to be visited before reaching
the final destination.”  Previously, there was a 1:1 mapping between this
text and the list of IPv6 addresses in the SegmentList array.  This
definition should be reviewed and updated for the compressed information
case.

Relatedly, the semantic intent might be restored by adding some indication
in the SRH of the size and number of the compressed SIDs.  We suspect this
would aid the usefulness of analysis of a packet capture: a captured packet
in tcpdump/wireshark could be dissected to show helpful information without
additional control plane knowledge.  Otherwise some means of injecting
control plane information into network diagnostics would be needed.

[C] We also suggest that, as SID/C-SID behaviors could be confused with
existing unicast/anycast address behaviour, it might be worth considering
isolating SIDs to a dedicated prefix.  RFC 4291 and other documents (e.g.,
RFCs 6052, 7343, ...) put addresses with different properties into defined
prefixes, and SIDs/C-SIDs could be similarly compartmentalized into a
well-defined prefix (e.g., a /16 to be requested of the IANA).  If no
dedicated prefix is used then the rationale should be documented (probably
in the same document mentioned in [A]).

[BC] https://mailarchive.ietf.org/arch/msg/ipv6/37bH3Ag7jaNgKwnZY_mKIxWRwdM/