[Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-bgp-srv6-args-04]
Hi Authors, # The review includes mostly editorial suggestions and observations that arose during a thorough examination of the document. Many thanks for writing up a solid document. # Please find my review notes below. Before proceeding further requesting an IETF Last-Call and consequently with the IESG, I would appreciate it if you could consider these. # Many thanks for the shepherd writeup from Jeffrey # line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-bgp-srv6-args-04.txt #GENERIC COMMENTS #================ ## I found that this document was not a-walk-in-the-park to digest. It has many abbreviations detailed procedures included. ## A terminology section may help a little, at least for trying to make reading the draft a less herculean effort. It is not easy to dig through the text while doing a treasure hunt at the same time for some used abbreviation terminology. ## RFC9602 suggests usage from IANA IPv6 Special-Purpose Address Registry the Address Block 5f00::/16 for SRv6 SIDs. In this document the classic IPv6 documentation address space used in the examples. It may be worth considering using for example 5f00:d0c::/32 instead? ## Argument Length is not abbreviated as AL on first usage, but on 2nd usage ## The following detailed comments section primarily consists of text refinements aimed at improving readability. In certain sections, BCP 14 keywords have been introduced to enhance clarity and alignment with standard terminology, while trying to preserve the intent of the original text. #DETAILED COMMENTS #================= 84 For some of the EVPN services, [RFC8986] introduced the End.DT2M SRv6 85 Endpoint Behavior that takes arguments (i.e., Arg.FE2). [RFC9252] 86 specified the encoding and procedures for signaling of the SRv6 SID 87 and its argument via EVPN Route Type 3 and EVPN Route Type 1 88 respectively. During the implementation and interoperability 89 testing, it was identified that the specifications in [RFC9252] were 90 not detailed adequately. GV> " For certain EVPN services, [RFC8986] introduced the End.DT2M SRv6 Endpoint Behavior, which utilizes arguments (i.e., Arg.FE2). [RFC9252] subsequently specified the encoding and signaling procedures for the SRv6 SID and its associated argument via EVPN Route Type 3 and EVPN Route Type 1, respectively. However, during implementation and interoperability testing, it was observed that the specifications outlined in [RFC9252] lacked sufficient detail, leading to ambiguities in interpretation and implementation. " 92 This document updates [RFC9252] to provide the necessary details and 93 clarifications related to the signaling of SRv6 Service SIDs 94 corresponding to SRv6 Endpoint Behaviors that use arguments. While 95 the document refers more specifically to the signaling of the 96 End.DT2M SRv6 Endpoint Behavior via EVPN Route Types 1 and 3, the 97 procedures can be applied to the signaling of other similar endpoint 98 behaviors with arguments that may be signaled via BGP. GV> " This document updates [RFC9252] by providing additional details and clarifications regarding the signaling of SRv6 Service SIDs associated with SRv6 Endpoint Behaviors that utilize arguments. While the focus is primarily on the signaling of the End.DT2M SRv6 Endpoint Behavior via EVPN Route Types 1 and 3, the procedures described herein are also applicable to other similar endpoint behaviors with arguments that may be signaled using BGP. " 100 [RFC9252] section 6.3 specifies the use of a bitwise logical-OR 101 operation between the SID with ARG signaled via Route Type 1 and the 102 SID with LOC:FUNC parts signaled via Route Type 3 to form the SRv6 103 Service SID to be used in the data path. However, this assumes that 104 the same uniform SID structure is used and signaled for all SIDs 105 advertised via Route Type 3 and the Route Type 1. Such an assumption 106 may not always be correct and the procedures in this document remove 107 this restriction. GV> " Section 6.3 of [RFC9252] specifies that the SRv6 Service SID used in the data plane is derived by applying a bitwise logical-OR operation between the SID with ARG signaled via Route Type 1 and the SID with LOC:FUNC components signaled via Route Type 3. However, this approach assumes a uniform SID structure across all SIDs advertised via Route Types 1 and 3. This assumption is not universally valid, and the procedures in this document remove this restriction, ensuring greater flexibility in SRv6 SID signaling. " 109 The description and the examples in this document do not use the 110 Transposition Scheme. Hence, the Transposition Offset (TPOS-O) and 111 Transposition Length (TPOS-L) are both shown to be 0 and the various 112 MPLS label fields into which the FUNC or ARG portions may be 113 transposed into are also not described. The same examples could use 114 the Transposition Scheme. This document does not introduce any 115 change with respect to the use of the Transposition Scheme in the 116 signaling of EVPN Routes and implementations need to follow the 117 procedures and recommendations related to the Transposition Scheme as 118 specified in [RFC9252]. GV> " The descriptions and examples presented in this document do not utilize the Transposition Scheme. Consequently, the Transposition Offset (TPOS-O) and Transposition Length (TPOS-L) are set to zero, and references to MPLS label fields where the FUNC or ARG portions may be transposed are omitted. However, the same examples could be applied with the Transposition Scheme. This document does not introduce any modifications to the use of the Transposition Scheme in the signaling of EVPN Routes. Implementations are expected to adhere to the procedures and recommendations specified in [RFC9252] concerning the Transposition Scheme. " 130 As defined in [RFC8986], an SRv6 SID consists of three parts: Locator 131 (LOC), Function (FUNC), and Argument (ARG). SRv6 SIDs corresponding 132 to SRv6 Endpoint Behaviors that do not support argument do not have 133 the ARG part, hence all the bits after FUNC MUST be zero and have 134 zero argument length. GV> " As specified in [RFC8986], an SRv6 SID comprises three components: Locator (LOC), Function (FUNC), and Argument (ARG). For SRv6 SIDs associated with SRv6 Endpoint Behaviors that do not support argument, the ARG component is not present. Consequently, all bits following the FUNC field MUST be set to zero, and the argument length MUST be zero. " 136 Certain SRv6 Endpoint Behaviors (e.g., End.DT2M), support arguments. 137 As indicated in section 3.2.1 of [RFC9252], the SRv6 SID Structure 138 sub-sub-TLV MUST be signaled along with SRv6 SID corresponding to 139 behaviors that support argument to enable the receiving router to 140 perform consistency checking for the argument and to perform correct 141 encoding of ARG value within the SRv6 SID. GV> " Certain SRv6 Endpoint Behaviors (e.g., End.DT2M) support arguments. As specified in Section 3.2.1 of [RFC9252], the SRv6 SID Structure sub-sub-TLV MUST be included when signaling an SRv6 SID corresponding to an endpoint behavior that supports argument. This ensures that the receiving router can perform consistency verification of the argument and correctly encode the ARG value within the SRv6 SID. " 143 While for some use cases, the SRv6 SID can be signaled as 144 LOC:FUNC:ARG all encoded within the SID, there are use cases where 145 the SRv6 SID (i.e., LOC:FUNC part) is signaled without the ARG via 146 one advertisement and its ARG value is signaled via another 147 advertisement or learnt via some other mechanism. It is the SRv6 148 Source Node that needs to encode the ARG after the LOC:FUNC part to 149 form the complete SRv6 SID (LOC:FUNC:ARG) that can be used in the 150 data path and encoded in either the packet's IPv6 destination address 151 or as a segment in the Segment Routing Header (SRH) [RFC8754], as 152 required. GV> " In certain use cases, the SRv6 SID can be signaled as a complete structure, with the LOC:FUNC:ARG components fully encoded within the SID. However, there are scenarios where the SRv6 SID, consisting only of the LOC:FUNC portion, is signaled in one advertisement, while the ARG value is either signaled through a separate advertisement or learned via an alternative mechanism. It is the responsibility of the SRv6 Source Node to append the ARG component to the LOC:FUNC portion, thereby constructing the complete SRv6 SID (LOC:FUNC:ARG). This fully-formed SID can then be utilized in the data plane, either as the IPv6 destination address of a packet or as a segment within the Segment Routing Header (SRH) [RFC8754], as required. " 154 Since arguments may be optional, the SRv6 Endpoint Node that owns the 155 SID indicates the SRv6 SID Structure along with the advertisement of 156 the LOC:FUNC part of the SRv6 SID to indicate its support for ARGs 157 for that specific SID. Using a zero Argument Length (AL) indicates 158 that the node does not accept ARG for the given SRv6 SID. Using a 159 non-zero AL indicates the size of the ARG that is supported by the 160 node along with the Locator Block Length (LBL), Locator Node Length 161 (LNL), and Function Length (FL) indicating the offset at which the 162 node expects the ARG value to be encoded. GV> " Since arguments may be optional, the SRv6 Endpoint Node that owns the SID MUST advertise the SRv6 SID Structure along with the LOC:FUNC portion of the SRv6 SID to indicate whether arguments are supported for that specific SID. A zero Argument Length (AL) value indicates that the node does not accept an argument for the given SRv6 SID. Conversely, a non-zero AL value specifies the size of the supported argument, along with the Locator Block Length (LBL), Locator Node Length (LNL), and Function Length (FL) parameters, which define the offset at which the node expects the ARG value to be encoded. " 164 The advertisement of the ARG value may be done by the same node that 165 owns the SRv6 SID and is doing the advertisement of the LOC:FUNC 166 parts of that SID, or it may be done by some other node/mechanism. 167 The advertisement of the ARG value needs to indicate the size of the 168 ARG along with the value and the associated SRv6 Endpoint Behavior of 169 the SID. There also needs to be some mechanism to associate the 170 advertisement of the ARG with the SID(s) for which that ARG may be 171 used. GV> " The advertisement of the ARG value may be performed either by the node that owns the SRv6 SID and is advertising the LOC:FUNC portion of that SID, or by another node/mechanism. The advertisement of the ARG value MUST specify the size of the argument, its value, and the associated SRv6 Endpoint Behavior of the SID. Additionally, there MUST be a mechanism to associate the ARG advertisement with the corresponding SID(s) for which the argument is applicable. " 175 As specified in [RFC9252], the LOC:FUNC part of the SRv6 SID with 176 End.DT2M behavior is signaled via EVPN Route Type 3 (Inclusive 177 Multicast Ethernet Tag Route) while the ESI Filtering ARG (the 178 Arg.FE2 notation introduced in [RFC8986]) part of the SRv6 SID is 179 signaled via EVPN Route Type 1 (Ethernet A-D per ES Route). The 180 subsections below specify the signaling and processing in more detail 181 as compared to [RFC9252]. GV> " As specified in [RFC9252], the LOC:FUNC portion of the SRv6 SID with End.DT2M behavior is signaled via EVPN Route Type 3 (Inclusive Multicast Ethernet Tag Route), while the ESI Filtering ARG (denoted as Arg.FE2 in [RFC8986]) is signaled via EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet Segment (A-D per ES) Route). The following subsections provide a more detailed specification of the signaling and processing mechanisms compared to [RFC9252]. " 183 ESI Filtering is a split-horizon method that is used for Multi-Homing 184 [RFC7432] or E-Tree procedures [RFC8317]. ESI Filtering is not used 185 where there is no E-Tree leaf Broadcast, Unknown Unicast, or 186 Multicast (BUM) traffic, no multi-homing, no split-horizon method 187 used, or where "local-bias" method (refer [RFC8365]) is used. In 188 this document we generically refer to "ESI Filtering" as the 189 procedure carried out by the disposition PE to avoid forwarding BUM 190 traffic to local Ethernet Segments or local leaf attachment circuits, 191 based on the presence of the ESI Filtering ARG. GV> " ESI Filtering is a split-horizon mechanism used for Multi-Homing [RFC7432] or E-Tree procedures [RFC8317]. ESI Filtering is not applicable in scenarios where: * No E-Tree leaf Broadcast, Unknown Unicast, or Multicast (BUM) traffic exists, * No multi-homing is present, * No split-horizon mechanism is required, or * The local-bias method (as specified in [RFC8365]) is employed. In this document, "ESI Filtering" is used as a general reference to the procedure performed by the disposition PE node to prevent forwarding of BUM traffic to local Ethernet Segments or local leaf attachment circuits, based on the presence of the ESI Filtering ARG. " 193 The detailed descriptions in the sections below also apply to the 194 flavors of End.DT2M behavior for SRv6 SID list compression 195 [I-D.ietf-spring-srv6-srh-compression]. In a deployment with a mix 196 of compressed and uncompressed SIDs, the behaviors advertised in the 197 Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1) and 198 the Inclusive Multicast Ethernet Tag Routes (EVPN Route Type 3) MAY 199 be of a mix of compressed and uncompressed End.DT2M behaviors. This 200 works as long as the checks for argument length consistency between 201 the EVPN Route Type 1 and 3, as described in the following sub- 202 sections, are satisfied. GV> " The signaling and processing descriptions outlined in the following sections also apply to End.DT2M behavior flavors designed for SRv6 SID list compression [I-D.ietf-spring-srv6-srh-compression]. In deployments where a mix of compressed and uncompressed SIDs is present, the behaviors advertised in the Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1) and Inclusive Multicast Ethernet Tag Routes (EVPN Route Type 3) MAY consist of a combination of compressed and uncompressed End.DT2M behaviors. This approach remains valid provided that the argument length consistency checks between EVPN Route Type 1 and Route Type 3, as described in the following subsections, are satisfied. " 204 3.1. Advertisement of Ethernet A-D per ES Route 205 206 Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1) 207 defined in [RFC7432] are used to achieve split-horizon filtering and 208 fast convergence, in case of multi-homing. A-D per ES routes are 209 also used to enable egress filtering of BUM traffic originated from a 210 Leaf, as specified in [RFC8317]. GV> " Ethernet Auto-Discovery (A-D) per ES Routes (EVPN Route Type 1), as defined in [RFC7432], are utilized to enable split-horizon filtering and fast convergence in multi-homing scenarios. Additionally, A-D per ES Routes facilitate egress filtering of BUM traffic originating from a Leaf, as specified in [RFC8317]. " 212 When ESI Filtering is not in use, there is no ESI Filtering ARG to be 213 conveyed. However, the advertisement of this route SHOULD include 214 the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an 215 SRv6 Service SID with the value ::0 in the SRv6 SID Information sub- 216 TLV with the SRv6 Endpoint Behavior set to End.DT2M for backward 217 compatibility and consistency with [RFC9252]. Since the End.DT2M 218 behavior supports the use of ARG, an SRv6 SID Structure sub-sub-TLV 219 MUST be included, and as no ARG value needs to be signaled, the AL 220 MUST be set to 0. GV> " When ESI Filtering is not in use, no ESI Filtering ARG is required to be conveyed. However, for backward compatibility and consistency with [RFC9252], the advertisement of this route SHOULD include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV carrying an SRv6 Service SID set to ::0 in the SRv6 SID Information sub-TLV, with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure sub-sub-TLV MUST be included. As no ARG value is required to be signaled in this case, the Argument Length (AL) MUST be set to 0. " 235 When ESI Filtering is in use, the advertisement of this route MUST 236 include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV 237 carrying the SRv6 Service SID containing the ESI Filtering ARG value 238 in the SRv6 SID Information sub-TLV (when not using the Transposition 239 Scheme) with the SRv6 Endpoint Behavior set to End.DT2M. Since the 240 End.DT2M behavior supports the use of ARG, an SRv6 SID Structure sub- 241 sub-TLV MUST be included. Also, as there is a non-zero ARG value 242 being signaled, the AL MUST be set to the size of the ARG and the 243 size SHOULD be a multiple of 8. The SRv6 SID Structure sub-sub-TLV 244 has the LBL, LNL, and FL set with values that indicate the offset at 245 which the ARG value is encoded in the 128-bit SID. GV> " When ESI Filtering is in use, the advertisement of this route MUST include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV, carrying the SRv6 Service SID that contains the ESI Filtering ARG value within the SRv6 SID Information sub-TLV (when not using the Transposition Scheme), with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure sub-sub-TLV MUST be included. Additionally, as a non-zero ARG value is being signaled, the Argument Length (AL) MUST be set to the size of the ARG, and the size SHOULD be a multiple of 8. The SRv6 SID Structure sub-sub-TLV MUST set the Locator Block Length (LBL), Locator Node Length (LNL), and Function Length (FL) fields with values that indicate the offset at which the ARG value is encoded within the 128-bit SRv6 SID. " 247 Following is an example representation of the BGP Prefix-SID 248 Attribute encoding in this case for a 16-bit argument value 'aaaa': GV> " The following is an example representation of the BGP Prefix-SID Attribute encoding in this scenario for a 16-bit argument value of 'aaaa': " 260 In the above examples, it would have been possible to set the LBL, 261 LNL, and FL values to 0 and to set the SID value as either ::0 or 262 aaaa::. However, such an encoding would not be backwards compatible 263 with [RFC9252] as described further in Section 4 and hence it is 264 REQUIRED that the LBL, LNL, and FL values be set as indicated via the 265 SID Structure for the End.DT2M SRv6 Service SIDs. GV> " In the examples above, it would have been possible to set the LBL, LNL, and FL values to 0 and to encode the SRv6 SID as either ::0 or aaaa::. However, such an encoding would not be backward compatible with [RFC9252], as further detailed in Section 4. Therefore, it is REQUIRED that the LBL, LNL, and FL values be set in accordance with the SID Structure for End.DT2M SRv6 Service SIDs, ensuring compliance with the existing specifications. " 267 3.2. Advertisement of Inclusive Multicast Ethernet Tag Route 268 269 Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3) defined in 270 [RFC7432] is used to advertise multicast traffic reachability 271 information through MP-BGP to all other PEs in a given EVPN instance. 272 When using the SRv6 transport, the advertisement of this route MUST 273 include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV to 274 indicate the use of SRv6. GV> " The Inclusive Multicast Ethernet Tag Route (EVPN Route Type 3), as defined in [RFC7432], is used to advertise multicast traffic reachability information via MP-BGP to all other PE routers within a given EVPN instance. When utilizing SRv6 transport, the advertisement of this route MUST include the BGP Prefix-SID Attribute with an SRv6 L2 Service TLV to indicate the use of SRv6. " 276 Irrespective of whether ESI Filtering is in use, an SRv6 Service SID 277 with the LOC:FUNC part alone is carried in the SRv6 SID Information 278 sub-TLV (when not using the Transposition Scheme) with the SRv6 279 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior 280 supports the use of ARG, an SRv6 SID Structure sub-sub-TLV MUST be 281 included. The LBL, LNL, and FL MUST be set to indicate the structure 282 of the Service SID being signaled. GV> " Regardless of whether ESI Filtering is in use, the SRv6 Service SID MUST include only the LOC:FUNC portion within the SRv6 SID Information sub-TLV (when not utilizing the Transposition Scheme), with the SRv6 Endpoint Behavior set to End.DT2M. Since the End.DT2M behavior supports the use of an ARG, an SRv6 SID Structure sub-sub-TLV MUST be included. The LBL, LNL, and FL fields MUST be set to indicate the structure of the SRv6 Service SID being advertised. " 284 When ESI Filtering is not in use, no ARG is expected to be received 285 by the router along with the signaled Service SID and hence the AL 286 MUST be set to 0. GV> " When ESI Filtering is not in use, no ARG is expected to be received by the router along with the advertised SRv6 Service SID. Therefore, the AL MUST be set to 0. " 301 When ESI Filtering is in use, an ARG is expected to be received by 302 the router along with the signaled Service SID and hence the AL MUST 303 be set to the size of the ARG supported by the advertising router for 304 the specific Service SID. The AL is unique per End.DT2M behavior 305 signaled by the egress PE and, therefore, the egress PE MUST use the 306 same AL for all the local Ethernet Segments with Attachment Circuits 307 in the same Broadcast Domain. GV> " When ESI Filtering is in use, the router MUST receive an ARG along with the signaled SRv6 Service SID. Consequently, the AL MUST be set to the size of the ARG supported by the advertising router for the specific SRv6 Service SID. The AL value is unique per End.DT2M behavior signaled by the egress PE. Therefore, the egress PE MUST use the same AL for all local Ethernet Segments with Attachment Circuits within the same Broadcast Domain. " 309 Following is an example representation of the BGP Prefix-SID 310 Attribute encoding in this case for a 16-bit argument: GV> " The following is an example representation of the BGP Prefix-SID Attribute encoding for this scenario with a 16-bit argument: " 322 When ESI Filtering is in use, the advertising router MUST ensure that 323 the size of argument (i.e., AL) signaled in the Route Type 3 and its 324 corresponding Route Type 1 are equal. GV> " When ESI Filtering is in use, the advertising router MUST ensure that the AL signaled in the EVPN Route Type 3 is equal to the AL signaled in the corresponding EVPN Route Type 1. " 328 An ingress PE receives the LOC:FUNC parts of the SRv6 Service SID to 329 be used for Broadcast, Unknown Unicast, or Multicast (BUM) traffic 330 along with the EVPN Route Type 3 advertisements. GV> " An ingress PE receives the LOC:FUNC portion of the SRv6 Service SID to be used for Broadcast, Unknown Unicast, or Multicast (BUM) traffic through EVPN Route Type 3 advertisements. " 332 In the case where ESI Filtering is not used, the SRv6 Service SID to 333 be used is all what is received via the EVPN Route Type 3 (i.e., 334 LOC:FUNC parts alone). GV> " When ESI Filtering is not in use, the SRv6 Service SID to be used consists solely of the LOC:FUNC portion received via EVPN Route Type 3. " 336 When ESI filtering is used, the ESI Filtering ARG of the SRv6 Service 337 SID is signaled along with EVPN Route Type 1 (Ethernet A-D per ES 338 Route). This ARG along with the LOC:FUNC parts advertised via the 339 EVPN Route Type 3 forms the SRv6 Service SID to be used. GV> " When ESI Filtering is in use, the ESI Filtering ARG of the SRv6 Service SID is signaled through EVPN Route Type 1 (Ethernet Auto-Discovery per Ethernet Segment Route). The ARG, in combination with the LOC:FUNC portion received via EVPN Route Type 3, forms the SRv6 Service SID to be used. " 341 Since the LOC:FUNC and the ARG portions of the SRv6 Service SID are 342 signaled via different route advertisements, there can be conditions 343 where the ingress PE gets inconsistent ALs from the two route types. 344 If the ingress PE expected ESI filtering to be in use (i.e., when 345 forwarding BUM traffic to other PEs attached to a shared Ethernet 346 Segment) but does not find a usable ARG value during the above 347 processing, it SHOULD log a message to help with troubleshooting. GV " Since the LOC:FUNC and ARG portions of the SRv6 Service SID are signaled via different route advertisements, there may be cases where the ingress PE receives inconsistent AL values from the two route types. If the ingress PE expects ESI Filtering to be in use (i.e., when forwarding BUM traffic to other PEs attached to a shared Ethernet Segment) but does not receive a usable ARG value during processing, it SHOULD log a message to facilitate troubleshooting. " 349 Following are the processing steps to be used at the ingress PE: 350 351 1. When AL=0 is signaled via Route Type 3, then the egress PE does 352 not support or does not require ESI Filtering ARG for the 353 specific SID. The SRv6 Service SID is formed with the LOC:FUNC 354 parts alone and all bits after LBL+LNL+FL MUST be set to zero for 355 encoding on the data path. In this case, the router MUST ignore 356 the SID value and its SID structure advertised in the 357 corresponding Route Type 1. GV> " The ingress Provider Edge (PE) router MUST follow the processing steps outlined below when handling SRv6 Service SID advertisements: 1. If AL = 0 is signaled via EVPN Route Type 3: * The egress PE does not support or does not require an ESI Filtering ARG for the specific SRv6 Service SID. * The SRv6 Service SID is formed using only the LOC:FUNC portion, and all bits beyond LBL + LNL + FL MUST be set to zero for encoding in the data plane. * In this case, the router MUST ignore the SRv6 SID value and SID structure advertised in the corresponding EVPN Route Type 1. " 359 2. When a non-zero AL is signaled via Route Type 3, then the 360 matching Route Type 1 for the Ethernet Segment is found and 361 checked for the presence of an SRv6 SID advertisement with the 362 End.DT2M behavior. GV> " 2. If a non-zero AL is signaled via EVPN Route Type 3: * The ingress PE MUST locate the matching EVPN Route Type 1 advertisement for the Ethernet Segment and verify the presence of an SRv6 SID advertisement with the End.DT2M behavior. " 364 a. If the AL=0 in the Route Type 1, then there is no usable ARG 365 value. In such cases, the SRv6 Service SID to be used is 366 formed as in (1) above. GV> " a. If AL = 0 in EVPN Route Type 1: * No usable ARG value is available. * The SRv6 Service SID MUST be formed as described in step (1) above. " 368 b. If the AL values in Route Type 1 and 3 are both non-zero and 369 not equal, then there is no usable ARG value. It also 370 indicates an inconsistency in signaling from the egress PE. 371 To avoid looping, the BUM traffic MUST NOT be forwarded for 372 such routes from the specific Ethernet Segment and 373 implementations SHOULD log an error message. GV> " b. If the AL values in EVPN Route Type 1 and EVPN Route Type 3 are both non-zero but not equal: * No usable ARG value is available. * This inconsistency in signaling from the egress PE indicates a configuration error. * To prevent potential looping, BUM traffic MUST NOT be forwarded for such routes from the specific Ethernet Segment. * Implementations SHOULD log an error message for troubleshooting. " 375 c. The ARG value from Route Type 1 is usable only when its AL is 376 equal to the AL of the SID structure advertised via Route 377 Type 3. Once the usable ARG value is obtained, it MUST be 378 encoded within the rest of the SRv6 SID (LOC:FUNC parts) at 379 the offset of the ARG as indicated by the SID structure 380 (i.e., LBL+LNL+FL) in Route Type 3 and the bits after 381 LBL+LNL+FL+AL set to zero. GV> " c. If the AL values in EVPN Route Type 1 and EVPN Route Type 3 are both non-zero and equal: * The ARG value from EVPN Route Type 1 is considered valid. * The ARG value MUST be encoded within the SRv6 SID (LOC:FUNC) at the ARG offset as specified in the SID structure (i.e., LBL + LNL + FL) in EVPN Route Type 3. * All bits beyond LBL + LNL + FL + AL MUST be set to zero. " 461 4. Backward Compatibility 462 463 Existing implementations based on the bitwise logical-OR operation 464 specified in section 6.3 of [RFC9252] work only if the SID structures 465 of the two route types are identical. Backward compatibility with 466 implementations doing the bitwise logical-OR operation is preserved 467 due to the advertisement of SIDs in Route Type 3 and its 468 corresponding Route Type 1 with the same SID structure as described 469 in Section 3.1 and Section 3.2 when the SID structures of the two 470 route types are identical. As an extension, the bitwise logical-OR 471 operation specified in [RFC9252] cannot be used when the SID 472 structures of the two route types are not identical. GV> " Existing implementations that rely on the bitwise logical-OR operation, as specified in Section 6.3 of [RFC9252], function correctly only when the SID structures of the two EVPN Route Types are identical. Backward compatibility with implementations performing the bitwise logical-OR operation is maintained when EVPN Route Type 3 and its corresponding EVPN Route Type 1 advertise SIDs with the same SID structure, as outlined in Section 3.1 and Section 3.2. However, when the SID structures of the two route types are not identical, the bitwise logical-OR operation specified in [RFC9252] cannot be applied. Instead, an alternative method MUST be used to correctly derive the SRv6 Service SID in such cases. " Kind Regards, Gunter Van de Velde Routing Area Director
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
