Joel,
1. Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field. To this I would say 100% yes – Section 2 of RFC8200 defines an address as “an IPv6-Layer identifier for an interface or a set of interfaces” and right above that it describes as an interface as “A node’s attachment to a link”. The definition of link above that also does not in any way help the case. When you place a list of SID’s in the DA of a field – you no longer have an address by these definitions – you have – something else. Yes – it can be clearly argued that the DA does not need to represent the ultimate destination – but it is hard to get away from the fact that this does change the definition as per the terminology section, since the address is no longer representative of an interface that represents a node’s attachment to a link – be it virtual or otherewise. 1. Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane. I am at a loss to see how this cannot be seen as a modification of the data plane. You are taking an ingress packet – modifying the DA based either on whats in the DA itself (which is a more clear cut case – since you are using the address to modify itself – and it is in no way in line with what is described in point 1) or in the case of when an SRH packet is applied – deriving the DA in part from the what is contained in the SRH and in part from what is configured on the device. As such the SRH itself does not “list one or more intermediate nodes to be visted”, that is derived information and I would argue outside of the spec. This is particularly relevant considering that the packets do not contain SID length and multiple SID lengths are possible, as such deriving this information is a flexible behavior inside the data plane that is modified by configuration. As I stated in another email – irrespective of how complex the pseudocode gets – and if you are deriving the information from the SRH or from the DA itself – the ultimate consequence of the behavior can still be summarized as da[location_size] << sid_size. If you copy that information out of the routing header in an obfuscated way or not – that does not change the outcome – and in fact I would argue that any statements that because you can copy parts of the DA out of the SRH and some how do this via a less efficient method to achieve the same result – do not solve the issue of if this is a modification – all they do is create a situation where to avoid a claim of of data plane modification, pseudocode is proposed that is unlikely to ever be seen in a real implementation because of efficiency reasons, and hence we are in all likelihood accepting standardization of a method that we know may well be violated in every implementation – for the sake of making a claim of lack of violation of another standard. This doesn’t sit well. Thanks Andrew From: spring <spring-boun...@ietf.org> on behalf of "Joel M. Halpern" <j...@joelhalpern.com> Date: Wednesday, 13 October 2021 at 06:53 To: "i...@ietf.org" <i...@ietf.org> Cc: "spring@ietf.org" <spring@ietf.org> Subject: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression The SPRING working group is in the midst of an adoption call on https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression>. The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be modified in SPRING unless the chairs and ADs responsible for that data plane and / or architecture agree. To complete the context, as my SPRING co-chairs are co-authors on the document in question, they have recused themselves from decisional activities regarding the document. Therefore, this message is coming just from my as the responsible SPRING co-chair managing this adoption call. As you have seen, multiple questions have been raised about the relationship of the document to the IPv6 defined data plane and architecture (particularly RFC 4291 and 8200). In particular the questions seem to revolve around what the document describes as the NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 standards. (For those seeking more context without reading the full document, a paraphrase and simplification of the NEXT-C_SID flavor is provided as a postscript.) I raised the question of concurrence as required by the SPRING charter with the Internet ADs and SPRING chairs. They quite reasonably asked me to write a note to 6man explaining the concerns as clearly as a can, so that they can then determine how to proceed. The questions that prompted my inquiry are: 1) Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field. 2) Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane. On a related note, the document in question also defines two other flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID flavor operation, so seems to be affected by the same question. From my own reading, it appears that the REPLACE-C-SID flavor does not raise issues requiring 6man leadership concurrence. Yours, Joel M. Halpern for the SPRING working group PS: Clearly, understanding the question requires some understanding of what the NEXT-C_SID flavor does. This explanation is a simplification for length and context. Really, the best place to understand it is the draft. However, to give you enough information to let you decide whether you care, I will try to provide a fair summary. My apologies in advance to the authors for necessary liberties for length. Also, discussion of the draft contents (as distinct from the interaction with the IPv6 data plane and architecture) belongs on the SPRING list, and should not clutter up 6man. SIDs are the identifiers used in segment routing. In SRv6, as document in the current RFCs, these are 128 bits. As defined in the relevant RFCs, SIDs which identify endpoints to which packets are directed are identified by endpoint SIDs. These can have behaviors (decapsulate and forward is one example). They can have flavors such as where the SRH is removed. The topic under discussion is means to compress these SIDs in the packets on the wire. The document under discussion provides three flavors of compression. The fundamental mechanism of the draft is to use a single SRH entry as a container for multiple SIDs. In the NEXT-C_SID mechanism, when it is first encountered the entire container is copied into the desination address of the IPv6 packet. The container has a common routing prefix used for all the NEXT-C-SID SIDs. It is followed by a sequence of compressed SIDs of a configured length. One could configure 16, 24, or 32 bits. Or whatever length. The routing advertisements are arranged so that the IPv6 packet is directed to the node represented by the first compressed SID on the basis of longest prefix match matching the combination of the common routing prefix and that compressed SID. When the packet arrives at that node, it looks up the configured portion, the compressed SID, and determines the behavior and flavor. In the case of the NEXT-C-SID flavor, the resulting operation is to shift the entire remaining contents of the IPv6 address (the bits past the first compressed sid) so as to over-write the first compressed SID. 0 bits are shifted into the low order positions. If the result is a non-zero new first compressed SID, then the packets is forwarded and the process repeats. When all that is left are 0s, if there is an SRH, it is consulted to find the next SRH entry, which is, per normal SRv6 processing, put into the IPv6 DA. Note that in the common case where the SIDS needed all fit in to a single container, the analysis also assumes the use of the reduced encapsulation options which omits the SRH that is not needed as it would have no entries. This the packet contains a normal IPv6 header, with a sequence of compressed SIDs (what one might or might not call a source route) in the IPv6 destination address field. PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented the work, please, send clarifications or corrections. Again, the best source of information is the draft itself. I was asked to provide extra context in this email. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
