# Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-srv6-srh-compression-18
# line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-srv6-srh-compression-18.txt #GENERIC COMMENTS #================ # This document is an intense read. It took time to process and get familiar with the documented procedures and concepts. During my review process i had the unique experience to review the document through the looking glass as a person "new to C-SID details". This is important as that gave me a greenfield understanding of the documented C-SID details. # terminology: the codepoint registrations use "CSID" in the flavor name but everywhere in the draft "C-SID" is used. Is that by intention? # The documented interpretation of the terms "flavor" and "behavior" appears to be unusual. In RFC 8986, behaviors such as End, End.X, etc., are defined, and flavors like PSP, USP, and USD provide additional information on how to process those behaviors. Specifically, Section 4.16 of RFC 8986 describes flavors as variants: "The Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP) of the SRH, and Ultimate Segment Decapsulation (USD) flavors are variants of the End, End.X, and End.T behaviors. The End, End.X, and End.T behaviors can support these flavors either individually or in combinations." RFC 8986 suggests that the End, End.X, and End.T behaviors can be combined with flavors. This document defines new flavors that appear to exhibit different characteristics from what RFC 8986 considers to be a flavor. For example, the End behavior can be combined with the PSP and USP flavors, whereas the End behavior with the NEXT-C-SID together with REPLACE-C-SID flavors cannot be combined. This difference causes confusion regarding the understanding and distinction between "behavior" and "flavor" and needs clarification. # The draft specifies that C-SIDs should be used as the destination address of an IPv6 packet, with or without an SRH. However, it does not provide guidance on whether using a C-SID construct or container as a source address is valid, invalid, or forbidden. # This document contains valuable operational C-SID guidelines scattered throughout its sections, which may make it challenging for operators to locate relevant recommendations. Collecting all SRv6 C-SID guidelines, recommendations, and considerations into a single "Operational Considerations" section or, alternatively, into a separate SRv6OPS document would be a reasonable approach. # section "7. Inter-Domain Compression" describes a procedure to swap Locator-Blocks. This seems rather different from procedures about NEXT-C-SID and REPLACE-C-SID and is maybe better discussed in its own separate document. #DETAILED COMMENTS #================= 150 The Segment Routing (SR) architecture [RFC8402] describes two data 151 plane instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6 152 (SRv6). GV> RFC8402 talks about the instantiation of SR *on* MPLS/IPv6 *data-plane*, and not *over*. A more accurate text blob, using RFC8402 text would be: " The Segment Routing (SR) architecture [RFC8402] describes two data plane instantiations of SR: SR applied to the MPLS-architecture (SR-MPLS) and SR applied to the IPv6-architecture (SRv6). " 154 SRv6 Network Programming [RFC8986] defines a framework to build a 155 network program with topological and service segments (also referred 156 to by their Segment Identifier (SID)) carried in a Segment Routing 157 Header (SRH) [RFC8754]. GV> This statement is not fully accurate. RFC8986 also describe Reduced SRH where a SID is carried outside the SRH to reduce the size of the SRH. 159 Some SRv6 applications such as strict path traffic engineering may 160 require long segment lists. Compressing the encoding of these long 161 segment lists in the packet header can significantly reduce the 162 header size. This document specifies new flavors to the SR segment 163 endpoint behaviors defined in [RFC8986] that enable a compressed 164 encoding of the SRv6 segment list. GV> This document seems to define additional behaviors, not only new flavors of existing behaviors. For example END.PS and END.XPS appear to be new behaviors, not new flavors of behaviors defined in RFC8986. 183 * Locator-Node: The least significant bits of a SID locator that 184 identify the SR segment endpoint node instantiating the SID. The 185 Locator-Node is referred to as "N" in Section 3.1 of [RFC8986]. GV> section 3.1 describe "N" as the "N is the identifier of the parent node instantiating the SID". Is this difference in terminology "endpoint" vs "parent node" by intent? 187 * Compressed-SID (C-SID): A compressed encoding of a SID. The C-SID 188 includes the Locator-Node and Function bits of the SID being 189 compressed. GV> I wonder if this is accurate. When a CSID is a global node-level identifier, the function bits are set to zero and are therefore omitted. Similarly, when the CSID is a local identifier without an associated global node-level CSID, the Locator Node bits are also zero and omitted. 191 * C-SID container: A 128-bit container holding a list of one or more 192 C-SIDs. GV> This may need some additional clarification for an accurate description. rfc8402 describe a SRv6 segment as an IPv6 address, in addition RFC8754 describe a segment within the SRH as an 128-bit IPv6 address. The above CSID container says its simply a 128-bit thing. A more accurate description would be: " * C-SID container: A 128-bit IPv6 address that functions as a container holding a list of one or more C-SIDs. " 194 * C-SID sequence: A group of one or more consecutive SID list 195 entries carrying the common Locator-Block and at least one C-SID 196 container. GV> Note that the verb "carry" is not entirely clear in above context. " * C-SID sequence: A group of one or more consecutive SID list entries encoding the common Locator-Block and at least one C-SID container. " 187 * Compressed-SID (C-SID): A compressed encoding of a SID. The C-SID 188 includes the Locator-Node and Function bits of the SID being 189 compressed. GV> a *compressed* SID list can contain *uncompressed* SIDs 245 The compressed segment list encoding is fully compatible with and 246 builds upon the mechanisms specified in [RFC8754] and [RFC8986]. The 247 compressed encoding leverages a SID list compression logic on the SR 248 source node (Section 6) in combination with new flavors of the base 249 SRv6 segment endpoint behaviors that process the compressed SID list 250 (Section 4). GV> In the draft -18 there are 56 instances of the term "SR source node" without an explicit definition of "what is" a SR source node from a C-SID perspective. This should be clarified and defined in terminology section 2 GV> What about an editorial rewrite to make the text more accurate: "Building upon and fully compatible with the mechanisms specified in [RFC8754] and [RFC8986], the compressed segment list encoding leverages SID list compression logic at the SR source node (see Section 6) in combination with both new and existing flavors of the base SRv6 segment endpoint behaviors that process the compressed SID list (see Section 4)." 252 A segment list can be encoded in the packet header using any 253 combination of compressed and uncompressed sequences. The C-SID GV> Line194 in terminology section introduce C-SID sequence. How does C-SID sequence correlate with uncompressed sequence? Could uncompressed sequence description be added in the terminology section? 252 A segment list can be encoded in the packet header using any 253 combination of compressed and uncompressed sequences. The C-SID 254 sequences leverage the flavors defined in this document, while the 255 uncompressed sequences use behaviors and flavors defined in other 256 documents, such as [RFC8986]. An SR source node constructs and 257 compresses the SID list depending on the SIDs instantiated on each SR 258 segment endpoint node that the packet should traverse, as well as its 259 own compression capabilities. GV> There is an inconsistency. In the text is mentioned "leverage the flavors defined in this document", however in section 4.1 can be found: " When a C-SID sequence comprises at least two C-SIDs, the last C-SID in the sequence is not required to have the NEXT-C-SID flavor. ***It can be bound to any behavior and flavor(s)*** " GV> s/packet should traverse/packet intended to traverse/ 274 behaviors of [RFC8986]. A counterpart NEXT-C-SID flavor is not 275 defined for these SIDs because they can be included within a C-SID 276 sequence that uses the NEXT-C-SID flavor without any modification of 277 the procedure defined in [RFC8986]. GV> What does "they can be included within a C-SID sequence" exactly mean? Can this be explained how this is intended to function? 297 SRv6 is intended for use in a variety of networks that require 298 different prefix lengths and SID numbering spaces. Each of the two 299 flavors introduced in this document comes with its own 300 recommendations for Locator-Block and C-SID length, as specified in 301 Section 4.1 and Section 4.2. These flavors are best suited for 302 different environments, depending on the requirements of the network. 303 For instance, larger C-SID lengths may be more suitable for networks 304 requiring ample SID numbering space, while smaller C-SID lengths are 305 better for compression efficiency. GV> This text suggests that these REPLACE and NEXT flavors are best suited in different environments. GV> next, the text describes that larger ands smaller C-SID lengths. What seems missing is the correlation of REPLACE and NEXT with the larger or smaller C-SID length in the example. 311 Both C-SID flavors can coexist in the same SR domain, on the same SR 312 segment endpoint node, and even in the same segment list. However, 313 operators should generally avoid instantiating SIDs of different 314 C-SID flavors within the same routing domain since these SIDs have 315 different length and allocation recommendations. In a multi-domain 316 deployment, different flavors may be used in different routing 317 domains of the SR domain. GV> Should there be text saying that the two flavors should not share the same sid block? 336 A C-SID sequence using the NEXT-C-SID flavor comprises one or more 337 C-SID containers. Each C-SID container is a fully formed 128-bit SID 338 structured as shown in Figure 1. It carries a Locator-Block followed 339 by a series of C-SIDs. The Locator-Node and Function of the C-SID GV> The C-SID container is used within a SRH. The SRH is an ordered list of SRv6 segments (SRv6 segment is an IPv6 address according RFC8402 section 2. Terminology "SRv6 SID: an IPv6 address explicitly associated with the segment"). What about following text: "Each C-SID container is a fully formed 128-bit IPv6 address functioning as a container holding a list of one or more C-SIDs and is structured as shown in Figure 1." 334 4.1. NEXT-C-SID Flavor 335 336 A C-SID sequence using the NEXT-C-SID flavor comprises one or more 337 C-SID containers. Each C-SID container is a fully formed 128-bit SID 338 structured as shown in Figure 1. GV> what does *using* the NEXT-C-SID flavor exactly describe? Only made of? That contains some? 339 by a series of C-SIDs. The Locator-Node and Function of the C-SID 340 container are those of the first C-SID, and its Argument is the 341 contiguous series of subsequent C-SIDs. GV> Could a first C-SID be END.X instead of a Locator-Node? (when for example LFA is used and the intent is to steer traffic out of a specific interface) 351 When a C-SID sequence comprises at least two C-SIDs, the last C-SID 352 in the sequence is not required to have the NEXT-C-SID flavor. It 353 can be bound to any behavior and flavor(s), including the REPLACE- 354 C-SID flavor, as long as the updated destination address resulting 355 from the processing of the previous C-SID in the sequence is a valid 356 form for that last SID. Line S12 of the first pseudocode in 357 Section 6.2 provides sufficient conditions to ensure this property. GV> This paragraph sound like it needs clarifications. * is it a generic C-SID sequence or a "A C-SID sequence using the NEXT-C-SID flavor"? * "the last C-SID" or "the last SID"? (Depends on the exact definition of "C-SID sequence"). * What does "any behavior" exactly describe? Confusing. Does it mean really any behavior (meaning regular SID is ok) or any C-SID behavior (which C-SID behavior or is this flavors)? 370 Figure 2 illustrates a compressed SID list as could be produced by an 371 SR source node steering a packet into an SR policy SID list of eight 372 NEXT-C-SID flavor SIDs. GV> The term "SR policy SID list" is used as a term well known to a reader. Can a reference/definition be added to what a SR policy SID list exactly represents? 380 significant bits to zero. With reduced SRH, the SR source node sets 381 the IPv6 Destination Address (DA) with the value of the first C-SID 382 container and the first (and only) element of the SRH Segment List 383 with the value of the second C-SID container. GV> For completeness the example could be given with two entries in the SRH for the full SRH and with 1 entry in SRH as already explained in the text. The current text is slightly unclear that when the SRH is not reduced, that both C-SID containers are caried in the SRH. GV> Maybe on the phrase "With reduced SRH..." is not needed here. This section discusses the NEXT-C-SID flavor. Not sure what value the reduced SRH text adds to NEXT-C-SID section. 415 An implementation MUST support a 32-bit Locator-Block length (LBL) 416 and a 16-bit C-SID length (LNFL) for NEXT-C-SID flavor SIDs, and may 417 support any other Locator-Block and C-SID length. GV> What about formal text to indicate that when a container is not used at full capacity, that the unused least significant bits MUST be set to zero? 419 A deployment should use a consistent Locator-Block length and C-SID 420 length for all SIDs of the SR domain. Heterogeneous lengths, while 421 possible, may impact the compression efficiency. GV> valuable operational guidance. is there a reason why the 'should' is not a normative 'SHOULD' from operational perspective? (see generic comment about operational guidance) 436 At high level, for any SID with the NEXT-C-SID flavor, the SR segment 437 endpoint node determines the next SID of the SID list as follows. If 438 the Argument value of the active SID is non-zero, the SR segment 439 endpoint node constructs the next SID from the active SID by copying 440 the entire SID Argument value to the bits that immediately follow the 441 Locator-Block, thus overwriting the active SID Locator-Node and 442 Function with those of the next C-SID, and filling the least 443 significant LNFL bits of the Argument with zeros. GV> The operation to fill the least significant bits with zeros when using NEXT-C-SID seems a mandated formal normative operation. Is there a formal procedure outlined in this document for that operation? 578 4.1.5. End.B6.Encaps.Red with NEXT-C-SID 579 580 When processing an IPv6 packet that matches a FIB entry locally 581 instantiated as an End.B6.Encaps.Red SID with the NEXT-C-SID flavor, 582 the procedure described in Section 4.14 of [RFC8986] is executed with 583 the same modifications as in Section 4.1.4 of this document. GV> This seems Unclear. There is no pseudo code in 4.14 of RFC8986 so it's unclear what modifications are to be applied and to what. Possible improvement to add accuracy of the expected pseudocode: " This is an optimization of End.B6.Encaps with NEXT-C-SID. When processing an IPv6 packet that matches a FIB entry locally instantiated as an End.B6.Encaps.Red SID with the NEXT-C-SID flavor, the procedure described in Section 4.14 of [RFC8986] is executed with the pseudo-code resulting from the modifications described in 4.1.4 of this document. " 626 current C-SID container. The Argument value is initially 0. When 627 more segments are present in the segment list, the C-SID sequence 628 continues with one or more C-SID containers in packed format carrying 629 the subsequent C-SIDs in the sequence. GV> In this REPLACE-C-SID section the C-SID container is described as a "packed format carrying the subsequent C-SIDs in the sequence". While not wrong, it is language that deviates from NEXT-C-SID where terminology as "a series of C-SIDs" is used or by using the "compressed". Maybe the language to describe the series of C-SID within the Argument could be aligned for clarity? 677 compressed SID list of three C-SID containers. The first C-SID 678 container is in fully formed 128-bit SID format. It carries a GV> more accurate is to say "the first C-SID container is in fully formed 128-bit SID format resembling an IPv6 address [draft-ietf-6man-sids-06]." 684 full capacity, it sets the 64 least significant bits to zero. With 685 reduced SRH, the SR source node sets the IPv6 DA with the value of 686 the first C-SID container, sets the first element in the SRH Segment 687 List with the value of the third C-SID container, and sets the second 688 element of the SRH Segment List with the value of the second C-SID 689 container (the elements in the SRH Segment List appear in reversed 690 order of their processing, as specified in Section 4.1 of [RFC8754]). GV> the reference to section 4.1 of RFC8754 is missing in section 4.1. of this document. It helps in providing accuracy. Maybe this artifact should be provided for NEXT-C-SID also in the provided example. 739 available for the C-SID and Argument. A Locator-Block length of 48, 740 56, 64, 72, or 80 bits is recommended for easier reading in 741 operation. GV> would a formal "RECOMMENDED" be justified for this for operational purpose? 743 This document defines the REPLACE-C-SID flavor for 16-bit and 32-bit 744 C-SID lengths (LNFL). An implementation MUST support a 32-bit C-SID 745 length for REPLACE-C-SID flavor SIDs. GV> NEXT-C-SID MUST support 16-bit C-SID and REPLACE-C-SID MUST support a 32-bit C-SID? Seems odd from interop perspective between both "flavors" 751 The Argument length (AL) for REPLACE-C-SID flavor SIDs is equal to 752 128-LBL-LNFL. The index value is encoded in the least significant X 753 bits of the Argument, where X is computed as ceiling(log_2(128/ 754 LNFL)). GV> Are there any REPLACE-C-SID conserns wrt Arguments and RFC9252 and [draft-ietf-bess-bgp-srv6-args]? 935 4.2.5. End.B6.Encaps.Red with REPLACE-C-SID 936 937 When processing an IPv6 packet that matches a FIB entry locally 938 instantiated as an End.B6.Encaps.Red SID with the REPLACE-C-SID 939 flavor, the procedure described in Section 4.14 of [RFC8986] is 940 executed with the same modifications as in Section 4.2.4 of this 941 document. GV> This seems Unclear. There is no pseudo code in 4.14 of RFC8986 so it's unclear what modifications are to be applied and to what. Similar update desired as mentioned for NEXT-C-SID section 4.1.5 984 For any End.DT2M SID with the REPLACE-C-SID flavor, the value of 985 Arg.FE2 is 16-bit long. The SR segment endpoint node obtains the 986 value Arg.FE2 from the 16 most significant bits of DA.Argument if 987 DA.Arg.Index is zero, or from the 16 least significant bits of the 988 next position in the current C-SID container (Segment List[Segments 989 Left][DA.Arg.Index-1]) otherwise (DA.Arg.Index is non-zero). GV> What is unclear to me is whether the introduction of arguments is transparent with regards to 9252 whether the specific case of DT2M works with draft-ietf-bess-bgp-srv6-args. Can this be verified? 1048 A node can have multiple global C-SIDs under the same Locator-Block 1049 (e.g., one per IGP flexible algorithm ([RFC9350])). Multiple nodes 1050 may share the same global C-SID (e.g., anycast). GV> Not sure i understand this comment about IGP flex algo. Is it not the SRv6 Locator that is associated with a specific algorithm and not the explicit C-SID itself? 1088 Given the previous Locator-Block and C-SID length recommendations, 1089 the following GIB/LIB usage is recommended: GV> would "RECOMMENDED" normative language be correct from operational perspective? 1091 * NEXT-C-SID: 1092 1093 - GIB: End 1094 1095 - LIB: End.X, End.T, End.DT4/6/46/2U/2M, End.DX4/6/2/2V 1096 (including large-scale pseudowire), End.B6.Encaps, 1097 End.B6.Encaps.Red, End.BM GV> End.DT4/6/46/2U/2M and End.DX4/6/2/2V with NEXT C-SID do not exist and should not be listed above. GV> Also .PS and .XPS are not mentioned above 1099 * REPLACE-C-SID: 1100 1101 - GIB: End, End.X, End.T, End.DT4/6/46/2U/2M, End.DX4/6/2/2V, 1102 End.B6.Encaps, End.B6.Encaps.Red, End.BM 1103 1104 - LIB: End.DX2/2V for large-scale pseudowire GV> .PS and .XPS are not mentioned 1241 If an SR source node chooses to compress the SID list, one method is 1242 described below for illustrative purposes. Any other method 1243 producing a compressed SID list of equal or shorter length than the 1244 uncompressed SID list is ***compliant***. GV> Could we try to avoid the word 'compliant'? Compliance to what? My assumption is that the only criteria is that the compressed sid list results in the exact same path than the uncompressed sid list. 1256 S01. Initialize a C-SID container equal to the first SID in the 1257 series, and initialize the remaining capacity of the C-SID 1258 container to the AL of that SID 1259 S02. For each subsequent SID in the series { 1260 S03. If the current SID Locator-Block matches that of the C-SID 1261 container and the current SID LNFL is lower than or equal to 1262 the remaining capacity of the C-SID container { 1263 S04. Copy the current SID Locator-Node and Function to the most 1264 significant remaining Argument bits of the C-SID container 1265 and decrement the remaining capacity by LNFL 1266 S05. } Else { 1267 S06. Push the C-SID container onto the compressed SID list 1268 S07. Initialize a new C-SID container equal to the current SID in 1269 the series, and initialize the remaining capacity of the 1270 C-SID container to the AL of that SID 1271 S08. } // End If 1272 S09. } // End For 1273 S10. If at least one SID remains in the uncompressed SID list 1274 (following the series of compressible NEXT-C-SID flavor SIDs){ 1275 S11. Set S to the next SID in the uncompressed SID list 1276 S12. If S is advertised with a SID structure, and the Locator-Block 1277 of S matches that of the C-SID container, and the sum of the 1278 Locator-Node, Function, and Argument length of S is lower 1279 than or equal to the remaining capacity of the C-SID 1280 container { 1281 S13. Copy the Locator-Node, Function, and Argument of S to the 1282 most significant remaining Argument bits of the C-SID 1283 container 1284 S14. } // End If 1285 S15. } // End If 1286 S16. Push the C-SID container onto the compressed SID list GV> I think there is a logical fault in the provided pseudocode, specifically in steps S12 to S14. The issue lies in not updating the remaining capacity of the C-SID container after copying the Locator-Node, Function, and Argument of SID S into it. This omission can lead to incorrect calculations of available space in the container for subsequent SIDs. 1288 * When the compression method encounters a series of REPLACE-C-SID 1289 flavor SIDs of the same C-SID length in the uncompressed SID list, 1290 it compresses the series as per the following high-level pseudo 1291 code. A compression checking function ComCheck(F, S) is defined 1292 to check if two SIDs F and S share the same SID structure and 1293 Locator-Block value, and if S has either no Argument or an 1294 Argument with value 0. If the check passes, then ComCheck(F,S) 1295 returns true. 1297 S01. Initialize the first C-SID container in full SID format equal to 1298 the first SID in the series 1299 S02. Initialize the second C-SID container in packed format if there 1300 are more than one SIDs, and initialize the remaining capacity 1301 of the C-SID container to 128 bits 1302 S03. For each subsequent SID in the uncompressed SID list { 1303 S04. Set S to the current SID in the uncompressed SID list 1304 S05. If ComCheck(First SID, S) { 1305 S06. If the LNFL of S is lower than or equal to 1306 the remaining capacity of the C-SID container { 1307 S07. Copy the Locator-Node and Function of S to the least 1308 significant remaining bits of the C-SID container 1309 and decrement the remaining capacity by LNFL // Note 1310 S08. } Else { 1311 S09. Push the C-SID container onto the compressed SID list 1312 S10. Initialize a new C-SID container in packed format with all 1313 bits set to 0 1314 S11 Copy the Locator-Node and Function of S to the least 1315 significant remaining bits of the C-SID container 1316 and decrement the remaining capacity by LNFL // Note 1317 S12. } 1318 S13. If S is not a REPLACE-C-SID flavor SID, then break 1319 S14. } Else { 1320 S15. Break 1321 S16. } // End If 1322 S17. } // End For 1323 S18. Push the C-SID container (if it is not empty) onto the 1324 compressed SID list GV> Confusion Between C-SID Containers: The pseudocode initializes two C-SID containers but does not clearly distinguish between them during processing. * S01: Initializes the first C-SID container in full SID format equal to the first SID in the series. * S02: Initializes the second C-SID container in packed format if there are more than one SIDs, with a remaining capacity of 128 bits. During the loop (steps S03 to S17), it is unclear which C-SID container is being referenced when copying data and updating capacity. GV> Incomplete Processing of the First SID * The first SID is initialized in the full_sid_container but is not pushed onto the compressed SID list until the end. * If the series contains only one SID, the full_sid_container may not be added to the compressed SID list. 1450 7. Inter-Domain Compression 1451 1452 Some SRv6 traffic may need to cross multiple routing domains, such as 1453 different Autonomous Systems (ASes) or different routing areas within 1454 an SR domain. Different routing domains may use different addressing 1455 schema and Locator-Blocks. 1456 1457 A property of a C-SID sequence is that all C-SIDs in the sequence 1458 share the same Locator-Block. Therefore, a segment list that spans 1459 across multiple routing domains using different Locator-Blocks may 1460 need a separate C-SID sequence for each domain. GV> interdomain SRv6 and SID compression seems a fine stand alone topic. Is this something that the WG absolutely wants to see included? It seems to propose from a high level perspective NAT66 for SRv6 locators/locator-blocks? GV> What does "optional" exactly mean in this context? does it mean that .PS and .XPS support is not required? how is that different from lets say End.BM with NEXT-C-SID if there is no End-BM supported by the SRv6 endpoint router? GV> i did not further review this complete section 7. as it is unclear if this fits into this document 1576 This document does not require any new extensions to routing 1577 protocols. GV> This seems misleading. There are extensions needed due to new code-points that need to be supported for the NEXT-C-SID and REPLACE-C-SID flavors/behaviors 1584 * IS-IS [RFC9352] 1585 1586 * OSPFv3 [RFC9513] 1587 1588 * BGP [RFC9252], [RFC9514], [I-D.ietf-idr-sr-policy-safi] 1589 1590 * BGP-LS [I-D.ietf-idr-bgp-ls-sr-policy] 1591 1592 * PCEP [I-D.ietf-pce-segment-routing-ipv6] GV> There is opportunity for additional guidance. Let us look for example to ISIS and we see that RFC9352 has a table "10. Advertising Endpoint Behaviors". Is this information complete for all the new behaviors and endpoints outlined in this document? Similar observation with all the other control plane protocols. GV> I did not further review this section as i am unclear about the scope intended by the WG desires to include and document. 1599 Signaling the SRv6 SID Structure is REQUIRED for all the SIDs 1600 introduced in this document. It is used by an SR source node to 1601 compress a SID list as described in Section 6. GV> in section 6.1 from this document we find: " When compressing a SID list, the SR source node MUST treat an invalid SID structure as unknown. A SID with an unknown SID structure is incompressible. " This means when SRv6 SID Structure info is not advertised, that the SID structure is unknown and the SID will not be not compressed. In other words, when the headend node is to perform compression, then the SRv6 Structure is REQUIRED. Sending SRv6 SID Structure is optional according draft-ietf-idr-sr-policy-safi 1662 When pinging a SID of this document, with or without intermediate 1663 segments, the SR source node MUST construct the IPv6 packet as 1664 described in Section 6, including computing the ICMPv6 checksum as 1665 described in Section 6.5. GV> Does the document and authors assume that each and every behavior/flavor NEXT-C-SID/REPLACE-C-SID can be pinged? 1667 In particular, when pinging a SID of this document without 1668 intermediate segments, the SR source node places the SID with 1669 Argument value 0 in the destination address of the ICMPv6 echo 1670 request and computes the ICMPv6 checksum using this SID as the 1671 destination address in the IPv6 pseudo-header. The Argument value 0 1672 allows the SID SR segment endpoint node (Section 4) to identify 1673 itself as the ultimate destination of the packet and process the 1674 ICMPv6 payload. GV> This section is in the paragraph that follows in the document described as "the simplified SR source node processing". What is simplified compared to which more complex behavior? 2145 12. Security Considerations 2159 This document introduces two new flavors for some of the SR segment 2160 endpoint behaviors defined in [RFC8986] and a method by which an SR 2161 source node may leverage the SIDs of these flavors to produce a 2162 compressed segment list encoding. GV> In the beginning of this review the subtle difference between behavior and flavor is discussed. This document seems to add some behavior properties to some new flavors. Also, new explicit behaviors/flavors are defined: For example, END.PS and END.XPS appear to be new behaviors, not new flavors of behaviors defined in RFC8986. 2185 This document defines a new method of encoding the SIDs inside a SID 2186 list at the SR source node and decoding them at the SR segment 2187 endpoint node, but it does not change how the SID list itself is 2188 encoded in the IPv6 packet nor the semantic of any segment that it 2189 comprises. Therefore, this document is subject to the same security 2190 considerations that are discussed in [RFC8402], [RFC8754], and 2191 [RFC8986]. GV> This document is about C-SIDs and this security paragraph talks about SIDs. How is this paragraph impacting C-SIDs? 2193 13. IANA Considerations GV> to be processed later when the above commends have been handled/reviewed 2567 Appendix A. Complete pseudocodes GV> to be processed later when other commends have been handled/reviewed Kind Regards, G/ _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
