idnits 2.17.1 draft-kebler-kurapati-l3vpn-mvpn-mtrace-05.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 34 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '...First Hop router SHOULD be a Provider ...' RFC 2119 keyword, line 149: '... Mtracev2 [I-D.ietf-mboned-mtrace-v2] SHOULD be followed. If a Mtrace...' RFC 2119 keyword, line 151: '...in this draft, it SHOULD be discarded....' RFC 2119 keyword, line 175: '... The Querier MUST add a MVPN Extende...' RFC 2119 keyword, line 178: '... wild card SPMSI MUST also specify the...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 110 has weird spacing: '...xxxxxxx xxx...' -- The document date (April 27, 2020) is 1452 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) == Unused Reference: 'RFC6514' is defined on line 656, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN R. Kebler 3 Internet-Draft P. Kurapati 4 Intended status: Standards Track Juniper Networks 5 Expires: October 29, 2020 S. Asif 6 AT&T LABS 7 Mankamana. Mishra 8 Stig. Venaas 9 Cisco Systems 10 April 27, 2020 12 Multicast Traceroute for MVPNs 13 draft-kebler-kurapati-l3vpn-mvpn-mtrace-05 15 Abstract 17 Mtrace is a tool used to troubleshoot issues in a network deploying 18 Multicast service. When multicast is used within a VPN service 19 offering, the base Mtrace specification does not detect the failures. 20 This document specifies a method of using multicast traceroute in a 21 network offering Multicast in VPN service. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 29, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Mtrace Query . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Mtrace Request . . . . . . . . . . . . . . . . . . . . . 5 62 3.2.1. Ingress PE Procedures . . . . . . . . . . . . . . . . 6 63 3.3. Downstream Requests . . . . . . . . . . . . . . . . . . . 7 64 3.4. ASBR Behavior . . . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Virtual Hub and Spoke . . . . . . . . . . . . . . . . . . 8 66 3.6. Inter-Area Provider Tunnels . . . . . . . . . . . . . . . 9 67 3.6.1. Egress PE . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6.2. ABR Behavior . . . . . . . . . . . . . . . . . . . . 9 69 3.7. Mtrace MVPN Procedure . . . . . . . . . . . . . . . . . . 9 70 4. Error Detection . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. MVPN Error Codes . . . . . . . . . . . . . . . . . . . . 11 72 5. Mtracev2 Extensions . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. New Mtracev2 TLV Type . . . . . . . . . . . . . . . . . . 12 74 5.2. MVPN Extended Query Block . . . . . . . . . . . . . . . . 12 75 5.3. Leaf A-D Augmented Response Block . . . . . . . . . . . . 13 76 5.4. PMSI Tunnel Attributes Augmented Response Block . . . . . 14 77 6. Mtrace2 Standard Response Block considerations . . . . . . . 14 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 The current multicast traceroute [I-D.ietf-mboned-mtrace-v2] travels 87 up the tree hop-by-hop towards the source. This verifies the basic 88 multicast state back to the source, but is not sufficient to verify 89 the MVPN state. The base Mtrace specification assumes that the 90 routers in the path are directly connected through interfaces. In 91 the case of Multicast traffic over VPN service, the PEs who are MVPN 92 neighbors may be separated by several router hops. The path taken by 93 the query can be completely different from the path taken through 94 core by the actual multicast traffic. Consider a case in the below 95 figure, where provider tunnel between PE2 (Source) and PE1 (Receiver) 96 is not established correctly due to incorrect MVPN state on PE2. In 97 the current form of Mtrace, the Query would result in a successful 98 response since there is no error detection mechanism for MVPN state 99 available currently. Even if one can infer from the statistics of 100 the Mtrace Response that PE2 has an issue, the existing error codes 101 are not sufficient to identify the root cause. Also, there could be 102 a problem sending traffic over the provider tunnel from PE2 to PE1, 103 but the mtrace query will not even travel over this provider tunnel. 104 Therefore, the mtrace successful response can be misleading. This 105 draft ensures that the Response uses same provider-tunnel that the 106 given C-S,C-G data would traverse and returns appropriate MVPN 107 specific error codes which would help in identifying the root cause. 109 xxxxxx 110 xxxxxxxxxxx xxxx +-----+ 111 xxx xxx | | +---+ 112 xx xx+-+ PE2 +---+CE2| 113 +-----+ xx xx| | +---+ 114 +---+ | | x Provider x+-----+ 115 |CE1+---+ PE1 +--+x Core xxxx 116 +---+ | | x xx 117 +-----+ xx xxx +----+ 118 xxx x+-+ | +---+ 119 xxxxxxx xxxxxxxxxxx | PE3+---+CE3| 120 xx xx | | +---+ 121 xxxxxxxx +----+ 123 MVPN topology 125 2. Overview 127 As described in the Mtracev2 specification 128 [I-D.ietf-mboned-mtrace-v2], a Querier initiates an Mtrace Query 129 which is sent to the Last Hop Router. Last Hop Router converts this 130 into a Request and sends it towards the First Hop Router. This draft 131 introduces a new "Downstream Request" mechanism to allow the First 132 Hop Router to send the mtrace request message back on the Provider 133 tunnel to the Last hop router. The last hop router will then change 134 it to Response and send it to the Querier who initiated the Query. 135 If there is any error encountered by the Last hop router or First Hop 136 router, a Response is directly unicasted to the querier with 137 appropriate MVPN specific error codes added. Each hop in the path of 138 Mtrace decrements the TTL value before sending the mtrace message. 140 Since the Mtrace is being extended for MVPNs, the Last Hop router and 141 First Hop router SHOULD be a Provider Edge (PE) router so that the 142 MVPN specific error codes can be contained within the provider space. 143 The Request will be initiated by the egress PE and will travel 144 upstream to the ingress PE. It is assumed that the Querier knows and 145 can reach the egress PE. A Querier and egress PE can be the same 146 router. 148 For Mtrace initiated by the CEs, the specification mentioned in 149 Mtracev2 [I-D.ietf-mboned-mtrace-v2] SHOULD be followed. If a Mtrace 150 message is received by the PE on CE facing interfaces containing MVPN 151 specific extensions defined in this draft, it SHOULD be discarded. 153 3. Protocol Details 155 The protocol details that follow are described in terms of mtracev2. 156 However, the same procedures can be achieved with mtracev1. The 157 protocol extensions needed for mtracev2 are described in Section 5 158 and the protocol extensions for mtracev1 and described in section 6. 160 3.1. Mtrace Query 162 A Querier willing to perform a Mtrace on a MVPN issues a Mtrace 163 Query. The format of the Query TLV is as specified in the Mtracev2 164 specification [I-D.ietf-mboned-mtrace-v2]. The (C-S,C-G) to be 165 queried is populated in the source address and group address fields 166 of the Mtrace2 Query block. A deployment may use wild card SPMSIs as 167 defined in [RFC6625]. For example, a (C-*,C-*) wild card SPMSI or a 168 (C-*,ALL-PIM-ROUTERS) can be used to send messages like BSR across 169 PEs as mentioned in section 5.3.4 MVPN specification [RFC6513]. A 170 querier may be interested in knowing the health of such a SPMSI 171 tunnel. In this case, the Multicast Address and Source Address 172 fields of the Mtrace2 query can be filled with wild cards (all 1s) 173 accordingly by the querier. 175 The Querier MUST add a MVPN Extended Query Block to include the RD of 176 the C-S,C-G that it wishes to trace. When wild card SPMSIs are used, 177 a PE could have subscribed to multiple upstream PEs for wild card 178 SPMSIs. Hence, a query for a wild card SPMSI MUST also specify the 179 upstream PE address that it is interested to query. The upstream PE 180 address in the MVPN Extended Query Block MUST be filled only for wild 181 card queries. For a regular (C-S,C-G) query, this field SHOULD be 182 set to 0s by the querier and is ignored by the receivers. 184 This Query is sent to the Downstream PE (Last Hop Router)to initiate 185 the mtrace towards the source. If a Querier does not receive a 186 Response, it can retry sending Query messages with increasing TTL 187 values to help diagnose where the Mtrace messages are being lost. 189 3.2. Mtrace Request 191 The PE that receives the query will lookup the (C-S,C-G) using the RD 192 of the query to distinguish the vrf. If the RD doesnt match any VRF, 193 PE sends a response with error code set to BAD_RD. The PE first 194 checks the C-Mcast route that is matching (C-S,C-G) of the mtrace 195 Query. It then finds the upstream multicast hop from the selected 196 C-Mcast route and unicasts the requests to the upstream multicast hop 197 after decrementing the TTL. The Mtrace Request MUST have PMSI Tunnel 198 Attributes Augmented Response Block populated with the PMSI attribute 199 that the PE uses to receive the traffic for the given (C-S,C-G) 200 traffic. 202 Upstream multicast hop can be same as upstream PE router in some 203 cases, while it can be the ASBR or the BGP nexthop of the selected 204 C-Mcast route in Inter-AS scenarios. The procedures for finding 205 upstream multicast hop is discussed in detail under section 5.1 of 206 MVPN specification [RFC6513]. 208 When a wild card query is received, the PE will look for the upstream 209 PE address in the MVPN Extended query block. The PE will then check 210 if it has bound to the wild card SPMSI tunnel from the specified 211 upstream PE. If it has, it will populate the Leaf A-D Augmented 212 Response Block and PMSI Tunnel Attributes Augmented Response Block 213 with the respective values. If the PE has not received any wild card 214 SPMSI AD route from the specified upstream PE in the query, it should 215 send a response with the error code set to 216 NO_WILD_CARD_SPMSI_AD_RCVD. If the PE has received wild card SPMSI 217 AD route from the upstream PE, but has not responded with a LEAF-AD 218 route, it should send a response with the error code set to 219 NO_WILD_CARD_SPMSI_LEAF_AD_SENT. 221 For a non-wild-card query, the upstream PE address field in the MVPN 222 Extended query block MUST be ignored by the PEs. It MUST follow the 223 procedure to find the upstream multicast hop as discussed earlier. 225 If the route does not match any MVPN-TIB state, then the PE should 226 send a Response to the Querier with the error code set to 227 NO_CMCAST_STATE. If the PE cannot locate the upstream PE then it 228 should send a response to the Querier with the NO_UPSTREAM_PE error 229 code. 231 From the selected UMH route, the local PE extracts the ASN of the 232 upstream PE (as carried in the Source AS Extended Community of the 233 route), and the source-AS field of the mtrace Query is set to that 234 AS. 236 If the local and the upstream PEs are in the same AS, then the RD in 237 the mtrace Query is set to the RD of the VPN-IP route for the source/ 238 RP. 240 Section 8 of MVPN specification [RFC6513] mentions two procedures 241 (Segmented and Non-Segmented) for handling Inter-AS scenarios. If 242 the local and the upstream PEs are in different ASes, and if 243 segmented Inter-AS procedure is used, then the local PE finds in its 244 VRF an Inter-AS I-PMSI A-D route whose Source AS field carries the 245 ASN of the upstream PE. The RD of the found Inter-AS I-PMSI A-D 246 route is used as the RD of the mtrace Query. If Inter-AS I-PMSI A-D 247 route is not found, a response with error code UNKNOWN_INTER_AS is 248 sent. 250 To support non-segmented inter-AS tunnels, if the local and the 251 upstream PEs are in different ASes, the local system finds in its VRF 252 an Intra-AS I-PMSI A-D route from the upstream PE. The Originating 253 Router's IP Address field of that route has the same value as the one 254 carried in the VRF Route Import of the unicast route to the address 255 carried in the Multicast Source field. The RD of the found Intra-AS 256 I-PMSI A-D route is used as the RD in the mtrace Query. The Source 257 AS field in the mtrace Query is set to value of the Originating 258 Router's IP Address field of the found Intra-AS I-PMSI A-D route. 260 The PE receiving Mtrace Query will check for any errors. If any 261 error is detected it will send the error back to the Querier. 262 Otherwise, it will change the TLV value to be an Mtrace Request, and 263 it will add a Mtrace2 Standard Response Block. It will also add a 264 PMSI Tunnel Attributes Augmented Response Block with the attributes 265 of the PMSI used to receive traffic for the S,G. If a Leaf-AD route 266 was advertised to the upstream PE for this S,G then the PE will also 267 include a Leaf-AD Augmented Response Block with the NLRI of the 268 associated Leaf-AD route. 270 3.2.1. Ingress PE Procedures 272 The PE that receives the Request, will check the PMSI attributes of 273 the sender of request to see if they match the values used to send 274 traffic for the S,G. If the values do not match, then the PE uses 275 the appropriate pmsi error code as specified in 'MVPN Error Codes' 276 section and sends a mtrace Response back to the Querier. Also, if a 277 Leaf A-D Augmented Response Block is included, the PE will validate 278 that it has received this Leaf A-D route from the router that sent 279 the Request. If not, then this PE should change the error code to 280 BAD_LEAF_AD and send the Response to the Querier. If the PE expects 281 that a Leaf A-D route is needed for the downstream PE to receive 282 traffic, but did not receive one in the mtrace Request from the 283 sending router, then it should use a NO_LEAF_AD_RCVD error code for 284 the mtrace Response. For a wild card SPMSI query, if the PE didn't 285 receive LEAF AD route from the downstream PE, it should use 286 NO_LEAD_AD_RCVD error code. 288 When the upstream PE receives the Request, it will check for any 289 errors. If there are errors detected, or if the TTL expired, then 290 the PE will change the TLV code to be a Mtrace Response and unicast 291 the response back to the Querier. 293 The ingress PE will also check it has local vrf connectivity for the 294 source/RP. If it does not have any connectivity to the source/RP 295 then it should use the base specification error code NO_ROUTE and 296 send an mtrace Response. Note that in a Virtual Hub and Spoke 297 environment, it is possible for a PE to receive a mtrace Request and 298 need to propagate it to another upstream PE. These procedures are 299 outlined in the section "Virtual Hub and Spoke". If the PE does not 300 expect to be receiving mtrace Responses from the mvpn core and have 301 the route to the source located via another upstream PE, then it can 302 use the base specification RPF_IF error code. 304 If the PE that receives the Request is the ingress PE that has local 305 vrf connectivity for the source, then it will add a Standard Response 306 Block to the mtrace message. It will not include the additional PMSI 307 Attributes Response Block. Then it will turn the Request into a 308 Downstream Request by changing the value of the Type field of the 309 TLV. It will send the mtrace message on the provider tunnel used to 310 send the S,G data traffic. 312 3.3. Downstream Requests 314 When a router receives Mtrace Downstream Request, it will determine 315 if it has added any of the Response Blocks for this mtrace message. 316 If it does not locate its address in the list of Response Blocks, 317 then it will silently discard this mtrace message. Otherwise, it 318 will set the 'D' bit in its PMSI Tunnel Attributes Augmented Response 319 Block to indicate that this message has been received on the PMSI 320 tunnel. 322 If this router is the egress PE that provided the initial Response 323 Block, then it will change the mtrace type to a Reply and sends the 324 Reply to the Querier (the egress PE and the Querier may be the same 325 router). Otherwise, this router must send the Downstream PE on the 326 PMSI that it would normally send traffic for the S,G. Before sending 327 the Downstream Request, the router must decrement the TTL and check 328 for TTL expiry. If the TTL has expired, then this router must send 329 the Response to the Querier with the appropriate code. 331 3.4. ASBR Behavior 333 When an ASBR receives a mtrace Request the ASBR finds an Inter-AS 334 I-PMSI A-D route whose RD and Source AS matches the RD and Source AS 335 carried in the mtrace Query. If no matching route is found and the 336 ASBR is using segmented tunnels as described in MVPN specification 337 [RFC6513], the ASBR sends an UNKNOWN_INTER_AS error code back to the 338 Querier. If a matching route is found, the ASBR acts as a "first hop 339 router" and modifies the Query type to DOWNSTREAM_REQUEST. ASBR in 340 this case MUST validate the PMSI attributes similar to the "first hop 341 router" and respond if there is any errors. ASBR MUST populate PMSI 342 Tunnel Attributes Augmented Response Block with the Inter-AS provider 343 tunnel information before sending the DOWNSTREAM_REQUEST. Note that 344 the mtrace request does not proceed upstream as it is assumed that 345 performing a traceroute and exposing IP addresses across AS 346 boundaries would not be desirable with Segmented Inter-AS Provider 347 Tunnels. 349 To support non-segmented inter-AS tunnels as described in [RFC6513], 350 instead of matching the RD and Source AS carried in the mtrace Query 351 against the RD and Source AS of an Inter-AS I-PMSI A-D route, the 352 ASBR should match it against the RD and the Originating Router's IP 353 Address of the Intra- AS I-PMSI A-D routes. The Next Hop field of 354 the MP_REACH_NLRI of the found Intra-AS I-PMSI A-D route is used as 355 the destination for the mtrace Request. 357 3.5. Virtual Hub and Spoke 359 When a Virtual-Hub (V-HUB) as described in specification 360 [I-D.ietf-l3vpn-virtual-hub] receives a mtrace Request the S,G may be 361 reachable via one of its vrf interfaces. In this case, the V-HUB is 362 an ingress PE and the procedure are defined in the Section "Ingress 363 PE Procedures". Otherwise, the C-RP/C-S of the route is reachable 364 via some other PE. This is the case where the received route was 365 originated by a Virtual-spoke (V-spoke) that sees the V-HUB as the 366 "upstream PE" for the given source, but the V-HUB sees another PE as 367 the "upstream PE" for that source. In this case, the V-HUB should 368 check the PMSI attributes sent in the mtrace Request against the 369 Tunnel Attributes of the Provider Tunnel used to send traffic for the 370 S,G from the upstream PE to the V-Spoke. 372 The V-HUB sends a mtrace Request to its upstream PE the same way as 373 it would if it received a mtrace Query. V-HUB MUST add PMSI Tunnel 374 Attributes Augmented Response Block of its own before sending the 375 mtrace Request to the upstream PE. It may also add Leaf-AD Augmented 376 Response Block if a Leaf-AD route was advertised upstream by the 377 V-HUB. If the RD or Source-AS of the upstream PE is different, the 378 V-HUB updates the MVPN Extended Query Block accordingly. 380 3.6. Inter-Area Provider Tunnels 382 3.6.1. Egress PE 384 The egress PE does the same procedures as specified in 385 Section "Mtrace Request" except it sends the Request upstream to the 386 IP address determined from the Global Administrator field of the 387 Inter-area P2MP Segmented Next-hop Extended Community as described in 388 specification [I-D.ietf-mpls-seamless-mcast] . If the egress PE has 389 sent a Leaf-AD route then it must send a Leaf-AD Augmented Response 390 Block with the NLRI of the Leaf A-D route. 392 3.6.2. ABR Behavior 394 ABR MUST find a S-PMSI or I-PMSI route whose NLRI has the same value 395 as the Route Key field of the received mtrace Leaf-AD extended Query 396 Block. If such a matching route is not found then a Response should 397 be sent to the Querier with the NO_LEAF_AD_RCVD. If the ABR has sent 398 a Leaf-AD route then it must add a Leaf-AD Augmented Response Block 399 with the values of Leaf A-D route NLRI. The upstream node's IP 400 address is the IP address determined from the Global Administrator 401 field of the Inter-area P2MP Segmented Next-hop Extended Community. 403 3.7. Mtrace MVPN Procedure 405 In this section, we will briefly discuss the Mtrace procedure taking 406 a working and non-working network topology. 408 Querier + Egress PE + PE/ASBR/ABR + Ingress PE 409 | | | | 410 | Query | | | 411 |+----------->| | | 412 | | Request | | 413 | |+------------> | | 414 | | | Request | 415 | | |+----------------->| 416 | | | | 417 | | | | 418 | | | Downstream Request| 419 | | |<-----------------+| 420 | Response | Downstream Request| | 421 |<----------- | <-----------------+ | 422 | | | | 423 | | | | 424 v v v v 426 Mtrace MVPN Procedure 428 The above figure depicts the path of MTRACE in working condition. 429 MTRACE request for MVPN can traverse multiple hops when a Virtual HUB 430 is present or when segmented P2MP inter-area tunnels are used. If no 431 error conditions are detected the downstream request will travel the 432 same path as the regular multicast packet for the queried mroute 433 would flow. The last hop router/egress router will convert it into a 434 Response and send it back to querier 436 Let us consider a non-working case where Mtrace is expected to be 437 used. Taking Virtual-HUB as an example, assume that there is a data- 438 path issue between V-HUB and Egress Spoke. The below steps take 439 place to determine the issue between V-HUB and egress Spoke 441 1 - Querier sends the Mtrace Query towards LHR (Egress PE-Spoke). 443 2 - Egress PE sends Request to V-HUB. V-HUB realises that the 444 first hop router is a connected spoke and sends the request to 445 Ingress Spoke PE. 447 3 - Ingress Spoke PE sends Downstream Request to V-HUB. The same 448 is received by V-HUB. V-HUB sets the 'D' bit in its PMSI Tunnel 449 Attributes Augmented Response Block. 451 4 - V-HUB sends Downstream request to ingress spoke. This is 452 never received by the ingress spoke. 454 5 - The result of first 4 steps is that querier did not receive 455 the response. This makes the querier fall back to TTL method. 457 6 - Querier reduces the TTL and the result will show that the hop 458 from V-HUB to ingress spoke is missing thereby pointing the issue 459 at the right place. 461 4. Error Detection 463 All routers will check for normal multicast errors as defined in the 464 Mtracev2 specification. In addition, they will check for errors 465 specific to MVPNs and this specification. 467 All receiving routers will check the state of the Provider Tunnel 468 used for forwarding traffic for the given S,G. The ability and 469 manner to check if the Provider Tunnel is down depends on the 470 Provider Tunnel type. If the Provider Tunnel is known to be down the 471 PE will respond with a PTUNNEL_DOWN error. 473 In some situations the router needs to send a Leaf AD route to the 474 upstream PE. If the upstream expects a Leaf AD route, but did not 475 receive one from the downstream PE, then the NO_LEAF_AD_RCVD error 476 will be sent. 478 The receiving router will check the values of the PMSI Tunnel 479 attributes to see if they match the expected values for the PMSI. If 480 an Inclusive-PMSI is used, then the router will verify that the 481 values match those in the I-PMSI A-D route. If a Selective PMSI is 482 used, then the Tunnel Attributes will be matched against the S-PMSI 483 or Leaf A-D Route, depending on the Tunnel Type. If the values do 484 not match, then a error code of the corresponding PMSI mismatch will 485 be sent. 487 If a router receives a MVPN traceroute, but does not have the proper 488 MVPN configuration, then it will respond with a UNEXPECTED_MVPN error 490 4.1. MVPN Error Codes 491 Value Name Description 492 ----- -------------- -------------------------------------- 493 0x11 PTUNNEL_DOWN The provide tunnel for this S,G is down. 495 0x12 NO_LEAF_AD_RCVD The S-PMSI has not been joined by 496 downstream neighbor 498 0x13 BAD_LEAF_AD The Leaf A-D route does not match 499 the expected values 501 0x14 BAD_RD The RD is known to not exist on this PE 503 0x15 UNEXPECTED_MVPN The MVPN traceroute message is unexpected 505 0x16 BAD_PMSI_ATTR_FLAG Error matching the PMSI attribute flag 507 0x17 BAD_PMSI_ATTR_TYPE Error matching the PMSI attribute type 509 0x18 BAD_PMSI_ATTR_LABEL Error matching the PMSI attribute label 511 0x19 BAD_PMSI_ATTR_ID Error matching the PMSI attribute tunnel 512 identifier 514 0x1a UNKNOWN_INTER_AS Could not locate the Inter-AS provider 515 tunnel segment. 517 0x1b NO_UPSTREAM_PE No valid upstream PE or route 519 0x1c NO_CMCAST_STATE No C-Mcast route for the requested query 521 0x1d NO_WILD_CARD_SPMSI_AD_RCVD No Wild Card SPMSI SPMSI AD is received from the upstream PE 522 0x1e NO_WILD_CARD_SPMSI_LEAD_AD_SENT PE did not send LEAF-AD route for the wild card SPMSI 524 5. Mtracev2 Extensions 526 5.1. New Mtracev2 TLV Type 528 A new Mtracev2 TLV type will be created for the Mtrace2 Downstream 529 Request. 531 5.2. MVPN Extended Query Block 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | MBZ |T| 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Extended Query Type | MBZ | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Route | 540 + + 541 | Distinguisher | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Source-AS | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Upstream PE | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 MVPN Extended Query Block 550 Type: Mtrace2 Extended Query Block Type 552 Length: Length of the MVPN Extended Query Block 554 MBZ: Sent with all 0's, ignored on receipt 556 T bit: This bit should be 0 558 Extended Query Type: New type defined 560 MBZ: Sent with all 0's, ignored on receipt 562 Route Distinguisher: The RD of the S,G that should be traced 564 Source-AS: The Autonomous System Number (ASN) of the Source 566 Upstream PE: IP Address of the Upstream PE 568 5.3. Leaf A-D Augmented Response Block 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type | Value .... | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 Leaf A-D Augmented Response Block 578 MBZ: Sent with all 0's, ignored on receipt 580 Type: New type defined 582 Value: The NLRI value of the associated Leaf A-D route 584 5.4. PMSI Tunnel Attributes Augmented Response Block 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type |D| MBZ | Value.. | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 PMSI Tunnel Attributes Augmented Response Block 594 MBZ: Sent with all 0's, ignored on receipt 596 Type: New type defined 598 D: 'D' bit indicating that Downstream Request is received on PMSI 600 Value: The PMSI Tunnel Attribute as defined in RFC 6514 602 6. Mtrace2 Standard Response Block considerations 604 The PEs in the MVPN Mtrace add the Standard Response Block as defined 605 in Mtrace2 [I-D.ietf-mboned-mtrace-v2]. For a PE, the incoming or 606 outgoing interface can be a Tunnel. The First Hop Router (FHR) PE 607 which is connected to the source SHOULD populate the incoming 608 interface address with the respective interface connected to the CE. 609 The outgoing interface address MAY be populated with 0 in this case. 610 Other routers in the mtrace path MAY populate incoming and outgoing 611 interface address fields as 0. 'Multicast Rtg Protocol' field MUST 612 be populated with 0s by the Last Hop Router (LHR). First Hop Router 613 (FHR) can populate this field with respective multicast routing 614 protocol used towards its upstream CE. All the remaining fields of 615 the Standard Response Block are populated as defined by the Mtrace2 616 [I-D.ietf-mboned-mtrace-v2] specification. 618 7. IANA Considerations 620 New TLV Type for MTRACE_MVPN_QUERY, MTRACE_MVPN_REQUEST, 621 MTRACE_MVPN_DOWNSTREAM_REQUEST, MTRACE_MVPN_RESPONSE 623 8. Security Considerations 625 There are no security considerations for this design other than what 626 is already in the mtracev2 specification. 628 9. Acknowledgments 630 The authors would like to thank Yakov Rekhter and Marco Rodrigues for 631 their valuable review and feedback. 633 10. Normative References 635 [I-D.ietf-l3vpn-virtual-hub] 636 Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 637 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 638 VPNs", draft-ietf-l3vpn-virtual-hub-08 (work in progress), 639 July 2013. 641 [I-D.ietf-mboned-mtrace-v2] 642 Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: 643 Traceroute Facility for IP Multicast", draft-ietf-mboned- 644 mtrace-v2-26 (work in progress), July 2018. 646 [I-D.ietf-mpls-seamless-mcast] 647 Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 648 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area P2MP 649 Segmented LSPs", draft-ietf-mpls-seamless-mcast-17 (work 650 in progress), February 2015. 652 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 653 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 654 2012, . 656 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 657 Encodings and Procedures for Multicast in MPLS/BGP IP 658 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 659 . 661 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 662 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 663 RFC 6625, DOI 10.17487/RFC6625, May 2012, 664 . 666 Authors' Addresses 667 Robert Kebler 668 Juniper Networks 669 10 Technology Park Drive 670 Westford, MA 01886 671 USA 673 Email: rkebler@juniper.net 675 Pavan Kurapati 676 Juniper Networks 677 1194 N. Mathilda Ave 678 Sunnyvale, CA 94089 679 USA 681 Email: kurapati@juniper.net 683 Saud Asif 684 AT&T LABS 685 200 S Laurel Ave. 686 Middletown, NJ 07748 687 USA 689 Email: sasif@att.com 691 Mankamana Mishra 692 Cisco Systems 693 821 Alder Drive, 694 MILPITAS, CALIFORNIA 95035 695 UNITED STATES 697 Email: mankamis@cisco.com 699 Stig Venaas 700 Cisco Systems 701 821 Alder Drive, 702 MILPITAS, CALIFORNIA 95035 703 UNITED STATES 705 Email: stig@cisco.com