[bess] [Shepherding AD review] review of draft-ietf-bess-bgp-srv6-args-04

["Gunter van de Velde (Nokia)" <[e-mail]>]

[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