idnits 2.17.1 draft-ietf-mpls-sr-epe-oam-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 414 has weird spacing: '...k-depth if an...' == Line 447 has weird spacing: '...k-depth if an...' -- The document date (8 November 2021) is 872 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5065' is mentioned on line 359, but not defined == Missing Reference: 'RFC4271' is mentioned on line 370, but not defined == Missing Reference: 'RFC6286' is mentioned on line 370, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft K. Arora 4 Intended status: Standards Track M. Srivastava 5 Expires: 12 May 2022 Juniper Networks Inc. 6 S. Ninan 7 Individual Contributor 8 X. Xu 9 Capital Online Inc. 10 8 November 2021 12 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) 13 Egress Peer Engineering Segment Identifiers (SIDs) with MPLS Data Planes 14 draft-ietf-mpls-sr-epe-oam-04 16 Abstract 18 Egress Peer Engineering (EPE) is an application of Segment Routing to 19 Solve the problem of egress peer selection. The Segment Routing 20 based BGP-EPE solution allows a centralized controller, e.g. a 21 Software Defined Network (SDN) controller to program any egress peer. 22 The EPE solution requires a node to program the PeerNode Segment 23 Identifier(SID) describing a session between two nodes, the PeerAdj 24 SID describing the link (one or more) that is used by sessions 25 between peer nodes, and the PeerSet SID describing an arbitrary set 26 of sessions or links between a local node and its peers. This 27 document provides new sub-TLVs for EPE Segment Identifiers (SID) that 28 would be used in the MPLS Target stack TLV (Type 1), in MPLS Ping and 29 Traceroute procedures. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 12 May 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 66 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 67 4. FEC Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. PeerAdj SID Sub-TLV . . . . . . . . . . . . . . . . . . . 4 69 4.2. PeerNode SID Sub-TLV . . . . . . . . . . . . . . . . . . 6 70 4.3. PeerSet SID Sub-TLV . . . . . . . . . . . . . . . . . . . 8 71 5. EPE-SID FEC validation . . . . . . . . . . . . . . . . . . . 10 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 9.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Egress Peer Engineering (EPE) as defined in 83 [I-D.ietf-spring-segment-routing-central-epe] is an effective 84 mechanism to select the egress peer link based on different criteria. 85 The EPE-SIDs provide means to represent egress peer links. Many 86 network deployments have built their networks consisting of multiple 87 Autonomous Systems either for ease of operations or as a result of 88 network mergers and acquisitons. The inter-AS links connecting the 89 two Autonomous Systems could be traffic engineered using EPE-SIDs in 90 this case as well.It is important to be able to validate the control 91 plane to forwarding plane synchronization for these SIDs so that any 92 anomaly can be detected easily by the operator. 94 +---------+ +------+ 95 | | | | 96 | H B------D G 97 | | +---/| AS 2 |\ +------+ 98 | |/ +------+ \ | |---L/8 99 A AS1 C---+ \| | 100 | |\\ \ +------+ /| AS 4 |---M/8 101 | | \\ +-E |/ +------+ 102 | X | \\ | K 103 | | +===F AS 3 | 104 +---------+ +------+ 106 Figure 1: Reference Diagram 108 In this reference diagram, EPE-SIDs are advertised from AS1 to AS2 109 and AS3. In certain cases the EPE-SIDs advertised by the control 110 plane may not be in synchronization with label programmed in data- 111 plane. For example, on C a PeerAdj SID could be advertised to 112 indicate it is for the link C->D. Due to some software anomaly the 113 actual data forwarding on this PeerAdj SID could be happening over 114 C->E link. If E had relevant data paths for further forwarding the 115 packet, this kind of anomalies will go unnoticed by the operator. A 116 FEC definition for the EPE-SIDs will define the details of the 117 control plane association of the SID and the data plane validation of 118 the SID will be done during the MPLS trace route procedure. When 119 there is a multi-hop EBGP session between the ASBRs, PeerNode SID is 120 advertised and traffic would be load-balanced between the interfaces 121 connecting two nodes. In the reference diagram C and F could have a 122 PeerNode-SID advertised. When the OAM packet is received on F, it 123 needs to validate if the packet came on one of the two interfaces 124 connected to C. 126 This document provides Target Forwarding Equivalence Class (FEC) 127 stack TLV definitions for EPE-SIDs. Other procedures for MPLS Ping 128 and Traceroute as defined in [RFC8287] section 7 and clarified by 129 [RFC8690] are applicable for EPE-SIDs as well. 131 2. Theory of Operation 133 [I-D.ietf-idr-bgpls-segment-routing-epe] provides mechanisms to 134 advertise the EPE-SIDs in BGP-LS. These EPE-SIDs may be used to 135 build Segment Routing paths as described in 136 [I-D.ietf-spring-segment-routing-policy] or using Path Computation 137 Element Protocol (PCEP) extensions as defined in [RFC8664]. Data 138 plane monitoring for such paths which consist of EPE-SIDs will use 139 extensions defined in this document to build the Taget FEC stack TLV. 140 The MPLS Ping and Traceroute procedures MAY be initaited by the head- 141 end of the Segment Routing path or a centralized topology-aware data 142 plane monitoring system as described in [RFC8403]. The extensions in 143 [I-D.ietf-spring-segment-routing-policy] and [RFC8664] do not define 144 the details of the SID and such extensions are out of scope for this 145 document. The node initiating the data plane monitoring may acquire 146 the details of EPE-SIDs through BGP-LS advertisements as described in 147 [I-D.ietf-idr-bgpls-segment-routing-epe]. There may be other 148 possible mechanisms to learn the definition of the SID from 149 controller. Details of such mechanisms are out of scope for this 150 document. 152 The EPE-SIDs are advertised for inter-AS links which run EBGP 153 sessions. The procedures to operate EBGP sessions in a scenario with 154 unnumbered interfaces is not very well defined and hence out of scope 155 for this document. During AS migration scenario procedures described 156 in [RFC7705] may be in force. In these scenarios, if the local and 157 remote AS fields in the FEC as described in Section 4 carries the 158 global AS and not the "local AS" as defined in [RFC7705], the FEC 159 validation procedures may fail. 161 3. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in BCP 166 14, [RFC2119], [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 4. FEC Definitions 171 Three new sub-TLVs are defined for the Target FEC Stack TLV (Type 1), 172 the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path 173 TLV (Type 21). 175 Sub-Type Sub-TLV Name 176 -------- --------------- 177 TBD1 PeerAdj SID Sub-TLV 178 TBD2 PeerNode SID Sub-TLV 179 TBD3 PeerSet SID Sub-TLV 181 Figure 2: New sub-TLV types 183 4.1. PeerAdj SID Sub-TLV 184 0 1 2 3 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |Type = TBD | Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Local AS Number (4 octets) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Remote As Number (4 octets) | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Local BGP router ID (4 octets) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Remote BGP Router ID (4 octets) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Local Interface address (4/16 octets) | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Remote Interface address (4/16 octets) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 3: PeerAdj SID Sub-TLV 204 Type : TBD 206 Length : variable based on IPV4/IPV6 interface address. Length 207 excludes the length of Type and length field.For IPV4 interface 208 addresses length will be 24. In case of IPV6 address length will be 209 48 211 Local AS Number : 213 4 octet unsigned integer representing the Member ASN inside the 214 Confederation.[RFC5065]. The AS number corresponds to the AS to 215 which PeerAdj SID advertising node belongs to. 217 Remote AS Number : 219 4 octet unsigned integer representing the Member ASN inside the 220 Confederation.[RFC5065]. The AS number corresponds to the AS of the 221 remote node for which the PeerAdj SID is advertised. 223 Local BGP Router ID : 225 4 octet unsigned integer of the advertising node representing the BGP 226 Identifier as defined in [RFC4271] and [RFC6286]. 228 Remote BGP Router ID : 230 4 octet unsigned integer of the receiving node representing the BGP 231 Identifier as defined in [RFC4271] and [RFC6286]. 233 Local Interface Address : 235 In case of PeerAdj SID Local interface address corresponding to the 236 PeerAdj SID should be apecified in this field. For IPV4,this field 237 is 4 octets; for IPV6, this field is 16 octets. Link Local IPV6 238 addresses are for further study. 240 Remote Interface Address : 242 In case of PeerAdj SID Remote interface address corresponding to the 243 PeerAdj SID should be apecified in this field. For IPV4,this field 244 is 4 octets; for IPV6, this field is 16 octets.Link Local IPv6 245 addresses are for further study. 247 [I-D.ietf-idr-bgpls-segment-routing-epe] mandates sending local 248 interface ID and remote interface ID in the Link Descriptors and 249 allows a value of 0 in the remote descriptors. It is useful to 250 validate the incoming interface for a OAM packet and if the remote 251 descriptor is 0 this validation is not possible. 252 [I-D.ietf-idr-bgpls-segment-routing-epe] allows optional link 253 descriptors of local and remote interface addresses as described in 254 section 4.2. This document recommends sending these optional 255 descriptors and use them to validate incoming interface. When these 256 local and remote interface addresses are not available, an ingress 257 node can send 0 in the local and/or remote interface address field. 258 The receiver SHOULD skip the validation for the incoming interface if 259 the address field contains 0. 261 4.2. PeerNode SID Sub-TLV 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |Type = TBD | Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Local AS Number (4 octets) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Remote As Number (4 octets) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Local BGP router ID (4 octets) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Remote BGP Router ID (4 octets) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 4: PeerNode SID Sub-TLV 278 Type : TBD 280 Length : 16 282 Local AS Number : 284 4 octet unsigned integer representing the Member ASN inside the 285 Confederation.[RFC5065]. The AS number corresponds to the AS to 286 which PeerNode SID advertising node belongs to. 288 Remote AS Number : 290 4 octet unsigned integer representing the Member ASN inside the 291 Confederation.[RFC5065]. The AS number corresponds to the AS of the 292 remote node for which the PeerNode SID is advertised. 294 Local BGP Router ID : 296 4 octet unsigned integer of the advertising node representing the BGP 297 Identifier as defined in [RFC4271] and [RFC6286]. 299 Remote BGP Router ID : 301 4 octet unsigned integer of the receiving node representing the BGP 302 Identifier as defined in [RFC4271] and [RFC6286]. 304 When there is a multi-hop EBGP session between two ASBRs, PeerNode 305 SID is advertised for this session and traffic can be load balanced 306 across these interfaces. An EPE controller that does bandiwdth 307 management for these links should be aware of the links on which the 308 traffic will be load-balanced. As per [RFC8029], the node 309 advertising the EPE SIDs will send Downstream Detailed Mapping TLV 310 (DDMT) specifying the details of nexthop interfaces, the OAM packet 311 will be sent out. Based on this information controller MAY choose to 312 verify the actual forwarding state with the topology information 313 controller has. On the router, the validation procedures will 314 include received DDMT validation as specified in [RFC8029] to verify 315 the control and forwarding state synchronization on the two routers. 316 Any descrepancies between controller's state and forwarding state 317 will not be detected by the procedures described in the document. 319 4.3. PeerSet SID Sub-TLV 320 0 1 2 3 321 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 |Type = TBD | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Local AS Number (4 octets) | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Local BGP router ID (4 octets) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | No.of elements in set | Reserved | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Remote As Number (4 octets) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Remote BGP Router ID (4 octets) | 334 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 336 One element in set consists of below details 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Remote As Number (4 octets) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Remote BGP Router ID (4 octets) | 341 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 343 Figure 5: PeerSet SID Sub-TLV 345 Type : TBD 347 Length : variable based on the number of elements in the set. The 348 length field does not include the length of Type and Length fields. 350 Local AS Number : 352 4 octet unsigned integer representing the Member ASN inside the 353 Confederation.[RFC5065]. The AS number corresponds to the AS to 354 which PeerSet SID advertising node belongs to. 356 Remote AS Number : 358 4 octet unsigned integer representing the Member ASN inside the 359 Confederation.[RFC5065]. The AS number corresponds to the AS of the 360 remote node for which the PeerSet SID is advertised. 362 Advertising BGP Router ID : 364 4 octet unsigned integer of the advertising node representing the BGP 365 Identifier as defined in [RFC4271] and [RFC6286]. 367 Receiving BGP Router ID : 369 4 octet unsigned integer of the receiving node representing the BGP 370 Identifier as defined in [RFC4271] and [RFC6286]. 372 No.of elements in set: 374 Number of remote ASes, the set SID load-balances on. 376 PeerSet SID may be associated with a number of PeerNode SIDs and 377 PeerAdj SIDs. The remote AS number and the Router ID of each of 378 these PeerNode SIDs PeerAdj SIDs MUST be included in the FEC. 380 5. EPE-SID FEC validation 382 When a remote ASBR of the EPE-SID advertisement receives the MPLS OAM 383 packet with top FEC being the EPE-SID, it SHOULD perform validity 384 checks on the content of the EPE-SID FEC sub-TLV. The basic length 385 check should be performed on the received FEC. 387 PeerAdj SID 388 ----------- 389 Length = 24 or 48 391 Peer Node SID 392 ------------- 393 Length = 20 + “No.of IPv4 interface pairs” * 8 + 394 “No.of IPv6 interface pairs ” * 32 396 PeerSet SID 397 ----------- 398 Length = 9 + no.of elements in the set * 399 (8 + “No.of IPv4 interface pairs” * 8 + 400 “No.of IPv6 interface pairs ” * 32) 402 Figure 6: Length Validation 404 If a malformed FEC sub-TLV is received, then a return code of 1, 405 "Malformed echo request received" as defined in [RFC8029] SHOULD be 406 sent. The below section augments the section 7.4 of [RFC8287] 408 4a. Segment Routing EPE-SID Validation: 410 If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV 411 at FEC-stack-depth is TBD1 (PeerAdj SID sub-TLV) 413 Set the Best-return-code to 10, "Mapping for this FEC is not 414 the given label at stack-depth if any below 415 conditions fail: 417 o Validate that the Receiving Node BGP Local AS matches 418 with the remote AS field in the received PeerAdj SID 419 FEC sub-TLV. 421 o Validate that the Receiving Node BGP Router-ID matches 422 with the Remote Router ID field in the received 423 PeerAdj SID FEC. 425 o Validate that there is a EBGP session with a peer 426 having local As number and BGP Router-ID as 427 specified in the Local AS number and Local Router-ID 428 field in the received PeerAdj SID FEC sub-TLV. 430 If the Remote interface address is not zero, validate the 431 incoming interface. 432 Set the Best-return-code to 35 "Mapping for this FEC is not 433 associated with the incoming interface" (RFC8287) if any below 434 conditions fail: 436 o Validate the incoming interface on which the OAM packet 437 was receieved, matches with the remote interface 438 specified in the PeerAdj SID FEC sub-TLV 440 If all above validations have passed, set the return code to 3 441 "Replying router is an egress for the FEC at stack-depth" 443 Else, if the Target FEC sub-TLV at FEC-stack-depth is TBD2 444 (PeerNode SID sub-TLV), 446 Set the Best-return-code to 10, "Mapping for this FEC is not 447 the given label at stack-depth if any below 448 conditions fail: 450 o Validate that the Receiving Node BGP Local AS matches with 451 the remote AS field in the 452 received PeerNode SID FEC sub-TLV. 454 o Validate that the Receiving Node BGP Router-ID matches 455 with the Remote Router ID field in the received 456 PeerNode SID FEC. 458 o Validate that there is a EBGP session with a peer 459 having local As number and BGP Router-ID as 460 specified in the Local AS number and Local Router-ID 461 field in the received PeerNode SID FEC sub-TLV. 463 If all above validations have passed, set the return code to 3 464 "Replying router is an egress for the FEC at stack-depth" 466 Else, if the Target FEC sub-TLV at FEC-stack-depth is TBD3 467 (PeerSet SID sub-TLV), 469 Set the Best-return-code to 10, "Mapping for this FEC is not 470 the given label at stack-depth" if any below 471 conditions fail: 473 o Validate that the Receiving Node BGP Local AS matches 474 with one of the remote AS field in the received PeerSet 475 SID FEC sub-TLV. 477 o Validate that the Receiving Node BGP Router-ID matches 478 with one of the Remote Router ID field in the received 479 PeerSet SID FEC sub-TLV. 481 o Validate that there is a EBGP session with a peer having 482 local As number and BGP Router-ID as 483 specified in the Local AS number and Local Router-ID 484 field in the received PeerSet SID FEC sub-TLV. 486 If all above validations have passed, set the return code to 3 487 "Replying router is an egress for the FEC at stack-depth" 489 Figure 7: EPE-SID FEC validiation 491 6. IANA Considerations 493 IANA is requested to allocated three new Target FEC stack sub-TLVs 494 from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the 495 "TLVs" registry of the "Multi-Protocol Label switching (MPLS) Label 496 Switched Paths (LSPs) Ping parameters" namespace. 498 PeerAdj SID Sub-TLV : TBD1 500 PeerNode SID Sub-TLV: TBD2 502 PeerSet SID Sub-TLV : TBD3 504 The three lowest free values from the Standard Tracks range should be 505 allocated if possible. 507 7. Security Considerations 509 The EPE-SIDs are advertised for egress links for Egress Peer 510 Engineering purposes or for inter-As links between co-operating ASes. 511 When co-operating domains are involved, they can allow the packets 512 arriving on trusted interfaces to reach the control plane and get 513 processed. When EPE-SIDs which are created for egress TE links where 514 the neighbor AS is an independent entity, it may not allow packets 515 arriving from external world to reach the control plane. In such 516 deployments MPLS OAM packets will be dropped by the neighboring AS 517 that receives the MPLS OAM packet. In MPLS traceroute applications, 518 when the AS boundary is crossed with the EPE-SIDs, the FEC stack is 519 changed. [RFC8287] does not mandate that the initiator upon 520 receiving an MPLS Echo Reply message that includes the FEC Stack 521 Change TLV with one or more of the original segments being popped 522 remove a corresponding FEC(s) from the Target FEC Stack TLV in the 523 next (TTL+1) traceroute request. If an initiator does not remove the 524 FECs belonging to the previous AS that has traversed, it MAY expose 525 the internal AS information to the following AS being traversed in 526 traceroute. 528 8. Acknowledgments 530 Thanks to Loa Andersson, Dhruv Dhody, Ketan Talaulikar, Italo Busi 531 and Alexander Vainshtein, Deepti Rathi for careful review and 532 comments. 534 9. References 536 9.1. Normative References 538 [I-D.ietf-idr-bgpls-segment-routing-epe] 539 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 540 S., and J. Dong, "Border Gateway Protocol - Link State 541 (BGP-LS) Extensions for Segment Routing BGP Egress Peer 542 Engineering", Work in Progress, Internet-Draft, draft- 543 ietf-idr-bgpls-segment-routing-epe-19, 16 May 2019, 544 . 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, 549 DOI 10.17487/RFC2119, March 1997, 550 . 552 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 553 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 554 Switched (MPLS) Data-Plane Failures", RFC 8029, 555 DOI 10.17487/RFC8029, March 2017, 556 . 558 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 559 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 560 May 2017, . 562 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 563 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 564 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 565 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 566 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 567 . 569 [RFC8690] Nainar, N., Pignataro, C., Iqbal, F., and A. Vainshtein, 570 "Clarification of Segment ID Sub-TLV Length for RFC 8287", 571 RFC 8690, DOI 10.17487/RFC8690, December 2019, 572 . 574 9.2. Informative References 576 [I-D.ietf-spring-segment-routing-central-epe] 577 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 578 Afanasiev, "Segment Routing Centralized BGP Egress Peer 579 Engineering", Work in Progress, Internet-Draft, draft- 580 ietf-spring-segment-routing-central-epe-10, 21 December 581 2017, . 584 [I-D.ietf-spring-segment-routing-policy] 585 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 586 P. Mattes, "Segment Routing Policy Architecture", Work in 587 Progress, Internet-Draft, draft-ietf-spring-segment- 588 routing-policy-14, 25 October 2021, 589 . 592 [RFC7705] George, W. and S. Amante, "Autonomous System Migration 593 Mechanisms and Their Effects on the BGP AS_PATH 594 Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, 595 . 597 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 598 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 599 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 600 2018, . 602 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 603 and J. Hardwick, "Path Computation Element Communication 604 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 605 DOI 10.17487/RFC8664, December 2019, 606 . 608 Authors' Addresses 610 Shraddha Hegde 611 Juniper Networks Inc. 612 Exora Business Park 613 Bangalore 560103 614 KA 615 India 617 Email: shraddha@juniper.net 619 Kapil Arora 620 Juniper Networks Inc. 622 Email: kapilaro@juniper.net 624 Mukul Srivastava 625 Juniper Networks Inc. 627 Email: msri@juniper.net 628 Samson Ninan 629 Individual Contributor 631 Email: samson.cse@gmail.com 633 Xiaohu Xu 634 Capital Online Inc. 635 Beijing 636 China 638 Email: xiaohu.xu@capitalonline.net