Hi Gunter, Thanks for the detailed review, your comments, and suggestions. We've incorporated most of your suggestions verbatim or with some alterations.
Please check inline below for responses. We have also posted and update that includes the changes discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-srv6-args-05 On Wed, Feb 12, 2025 at 6:24 PM Gunter van de Velde (Nokia) < gunter.van_de_ve...@nokia.com> wrote: > [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. > KT> We've fixed and cleaned up the usage and expansion on first use. I hope this helps. Most of the acronyms come from EVPN and SRv6 specifications, as may be expected. > > > ## 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? > KT> IMO it would be inappropriate to use anything from within 5f00::/16 for the purpose of documentation related to SRv6 SIDs with the reason being the operational implications that are similar to https://www.rfc-editor.org/rfc/rfc3849.html#section-3 and https://www.rfc-editor.org/rfc/rfc9637.html#section-4 even if in a different context. Also, RFC9602 does not (rightly) suggest the use of this space for SRv6 SID documentation purposes. > > > ## Argument Length is not abbreviated as AL on first usage, but on 2nd > usage > KT> The text is reorganized a little bit to take care of this. > > > ## 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Minor tweak to remove the abbreviations. > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Updated with some change in the suggested use of normative language. > > > 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]. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Incorporated with slight edits to clarify what "This approach" means. > > > 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]. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Incorporated without splitting across paragraphs to keep everything related to "When ESI filtering is in use ..." together. > > > 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': > > " > KT> Ack > > > 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. > > " > KT> Incorporated with minor changes for clarity. > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> There is an issue with your suggested text. We've clarified the same with modified text. > > > 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: > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Ack > > > 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. > > " > KT> Incorporated some of the suggestions, but not splitting into bullets as above since it is a single "case" as opposed to the next one that has multiple "sub-cases". > > > 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. > > > > " > KT> The normative language is not required at each step since we have it at the start of the procedures. However, we've incorporated some of your suggested language. > > > 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. > > " > KT> Incorporated the language with some tweaks and also clarified one case. > > > 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. > > " > KT> Incorporated the language without splitting into bullets. > > > 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. > > " > KT> Incorporated the language without splitting into bullets. > > > 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. > > " > KT> Ack - incorporated with minor change. Thanks, Ketan (on behalf of my co-authors) > > > 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
