idnits 2.17.1 draft-kebler-kurapati-l3vpn-mvpn-mtrace-01.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 15 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 138: '...First Hop router SHOULD be a Provider ...' RFC 2119 keyword, line 146: '... Mtracev2 [I-D.ietf-mboned-mtrace-v2] SHOULD be followed. If a Mtrace...' RFC 2119 keyword, line 148: '...in this draft, it SHOULD be discarded....' RFC 2119 keyword, line 172: '... The Querier MUST add a MVPN Extende...' RFC 2119 keyword, line 175: '... 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 107 has weird spacing: '...xxxxxxx xxx...' -- The document date (July 4, 2014) is 3583 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 651, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-mboned-mtrace-v2-10 == Outdated reference: A later version (-17) exists of draft-ietf-mpls-seamless-mcast-14 Summary: 2 errors (**), 0 flaws (~~), 5 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: January 5, 2015 S. Asif 6 AT&T LABS 7 July 4, 2014 9 Multicast Traceroute for MVPNs 10 draft-kebler-kurapati-l3vpn-mvpn-mtrace-01 12 Abstract 14 Mtrace is a tool used to troubleshoot issues in a network deploying 15 Multicast service. When multicast is used within a VPN service 16 offering, the base Mtrace specification does not detect the failures. 17 This document specifies a method of using multicast traceroute in a 18 network offering Multicast in VPN service. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 5, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Mtrace Query . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Mtrace Request . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.1. Ingress PE Procedures . . . . . . . . . . . . . . . . 6 60 3.3. Downstream Requests . . . . . . . . . . . . . . . . . . . 7 61 3.4. ASBR Behavior . . . . . . . . . . . . . . . . . . . . . . 8 62 3.5. Virtual Hub and Spoke . . . . . . . . . . . . . . . . . . 8 63 3.6. Inter-Area Provider Tunnels . . . . . . . . . . . . . . . 9 64 3.6.1. Egress PE . . . . . . . . . . . . . . . . . . . . . . 9 65 3.6.2. ABR Behavior . . . . . . . . . . . . . . . . . . . . 9 66 3.7. Mtrace MVPN Procedure . . . . . . . . . . . . . . . . . . 9 67 4. Error Detection . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.1. MVPN Error Codes . . . . . . . . . . . . . . . . . . . . 11 69 5. Mtracev2 Extensions . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. New Mtracev2 TLV Type . . . . . . . . . . . . . . . . . . 12 71 5.2. MVPN Extended Query Block . . . . . . . . . . . . . . . . 12 72 5.3. Leaf A-D Augmented Response Block . . . . . . . . . . . . 13 73 5.4. PMSI Tunnel Attributes Augmented Response Block . . . . . 14 74 6. Mtrace2 Standard Response Block considerations . . . . . . . 14 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The current multicast traceroute [I-D.ietf-mboned-mtrace-v2] travels 84 up the tree hop-by-hop towards the source. This verifies the basic 85 multicast state back to the source, but is not sufficient to verify 86 the MVPN state. The base Mtrace specification assumes that the 87 routers in the path are directly connected through interfaces. In 88 the case of Multicast traffic over VPN service, the PEs who are MVPN 89 neighbors may be separated by several router hops. The path taken by 90 the query can be completely different from the path taken through 91 core by the actual multicast traffic. Consider a case in the below 92 figure, where provider tunnel between PE2 (Source) and PE1 (Receiver) 93 is not established correctly due to incorrect MVPN state on PE2. In 94 the current form of Mtrace, the Query would result in a successful 95 response since there is no error detection mechanism for MVPN state 96 available currently. Even if one can infer from the statistics of 97 the Mtrace Response that PE2 has an issue, the existing error codes 98 are not sufficient to identify the root cause. Also, there could be 99 a problem sending traffic over the provider tunnel from PE2 to PE1, 100 but the mtrace query will not even travel over this provider tunnel. 101 Therefore, the mtrace successful response can be misleading. This 102 draft ensures that the Response uses same provider-tunnel that the 103 given C-S,C-G data would traverse and returns appropriate MVPN 104 specific error codes which would help in identifying the root cause. 106 xxxxxx 107 xxxxxxxxxxx xxxx +-----+ 108 xxx xxx | | +---+ 109 xx xx+-+ PE2 +---+CE2| 110 +-----+ xx xx| | +---+ 111 +---+ | | x Provider x+-----+ 112 |CE1+---+ PE1 +--+x Core xxxx 113 +---+ | | x xx 114 +-----+ xx xxx +----+ 115 xxx x+-+ | +---+ 116 xxxxxxx xxxxxxxxxxx | PE3+---+CE3| 117 xx xx | | +---+ 118 xxxxxxxx +----+ 120 MVPN topology 122 2. Overview 124 As described in the Mtracev2 specification 125 [I-D.ietf-mboned-mtrace-v2], a Querier initiates an Mtrace Query 126 which is sent to the Last Hop Router. Last Hop Router converts this 127 into a Request and sends it towards the First Hop Router. This draft 128 introduces a new "Downstream Request" mechanism to allow the First 129 Hop Router to send the mtrace request message back on the Provider 130 tunnel to the Last hop router. The last hop router will then change 131 it to Response and send it to the Querier who initiated the Query. 132 If there is any error encountered by the Last hop router or First Hop 133 router, a Response is directly unicasted to the querier with 134 appropriate MVPN specific error codes added. Each hop in the path of 135 Mtrace decrements the TTL value before sending the mtrace message. 137 Since the Mtrace is being extended for MVPNs, the Last Hop router and 138 First Hop router SHOULD be a Provider Edge (PE) router so that the 139 MVPN specific error codes can be contained within the provider space. 140 The Request will be initiated by the egress PE and will travel 141 upstream to the ingress PE. It is assumed that the Querier knows and 142 can reach the egress PE. A Querier and egress PE can be the same 143 router. 145 For Mtrace initiated by the CEs, the specification mentioned in 146 Mtracev2 [I-D.ietf-mboned-mtrace-v2] SHOULD be followed. If a Mtrace 147 message is received by the PE on CE facing interfaces containing MVPN 148 specific extensions defined in this draft, it SHOULD be discarded. 150 3. Protocol Details 152 The protocol details that follow are described in terms of mtracev2. 153 However, the same procedures can be achieved with mtracev1. The 154 protocol extensions needed for mtracev2 are described in Section 5 155 and the protocol extensions for mtracev1 and described in section 6. 157 3.1. Mtrace Query 159 A Querier willing to perform a Mtrace on a MVPN issues a Mtrace 160 Query. The format of the Query TLV is as specified in the Mtracev2 161 specification [I-D.ietf-mboned-mtrace-v2]. The (C-S,C-G) to be 162 queried is populated in the source address and group address fields 163 of the Mtrace2 Query block. A deployment may use wild card SPMSIs as 164 defined in [RFC6625]. For example, a (C-*,C-*) wild card SPMSI or a 165 (C-*,ALL-PIM-ROUTERS) can be used to send messages like BSR across 166 PEs as mentioned in section 5.3.4 MVPN specification [RFC6513]. A 167 querier may be interested in knowing the health of such a SPMSI 168 tunnel. In this case, the Multicast Address and Source Address 169 fields of the Mtrace2 query can be filled with wild cards (all 1s) 170 accordingly by the querier. 172 The Querier MUST add a MVPN Extended Query Block to include the RD of 173 the C-S,C-G that it wishes to trace. When wild card SPMSIs are used, 174 a PE could have subscribed to multiple upstream PEs for wild card 175 SPMSIs. Hence, a query for a wild card SPMSI MUST also specify the 176 upstream PE address that it is interested to query. The upstream PE 177 address in the MVPN Extended Query Block MUST be filled only for wild 178 card queries. For a regular (C-S,C-G) query, this field SHOULD be 179 set to 0s by the querier and is ignored by the receivers. 181 This Query is sent to the Downstream PE (Last Hop Router)to initiate 182 the mtrace towards the source. If a Querier does not receive a 183 Response, it can retry sending Query messages with increasing TTL 184 values to help diagnose where the Mtrace messages are being lost. 186 3.2. Mtrace Request 188 The PE that receives the query will lookup the (C-S,C-G) using the RD 189 of the query to distinguish the vrf. If the RD doesnt match any VRF, 190 PE sends a response with error code set to BAD_RD. The PE first 191 checks the C-Mcast route that is matching (C-S,C-G) of the mtrace 192 Query. It then finds the upstream multicast hop from the selected 193 C-Mcast route and unicasts the requests to the upstream multicast hop 194 after decrementing the TTL. The Mtrace Request MUST have PMSI Tunnel 195 Attributes Augmented Response Block populated with the PMSI attribute 196 that the PE uses to receive the traffic for the given (C-S,C-G) 197 traffic. 199 Upstream multicast hop can be same as upstream PE router in some 200 cases, while it can be the ASBR or the BGP nexthop of the selected 201 C-Mcast route in Inter-AS scenarios. The procedures for finding 202 upstream multicast hop is discussed in detail under section 5.1 of 203 MVPN specification [RFC6513]. 205 When a wild card query is received, the PE will look for the upstream 206 PE address in the MVPN Extended query block. The PE will then check 207 if it has bound to the wild card SPMSI tunnel from the specified 208 upstream PE. If it has, it will populate the Leaf A-D Augmented 209 Response Block and PMSI Tunnel Attributes Augmented Response Block 210 with the respective values. If the PE has not received any wild card 211 SPMSI AD route from the specified upstream PE in the query, it should 212 send a response with the error code set to 213 NO_WILD_CARD_SPMSI_AD_RCVD. If the PE has received wild card SPMSI 214 AD route from the upstream PE, but has not responded with a LEAF-AD 215 route, it should send a response with the error code set to 216 NO_WILD_CARD_SPMSI_LEAF_AD_SENT. 218 For a non-wild-card query, the upstream PE address field in the MVPN 219 Extended query block MUST be ignored by the PEs. It MUST follow the 220 procedure to find the upstream multicast hop as discussed earlier. 222 If the route does not match any MVPN-TIB state, then the PE should 223 send a Response to the Querier with the error code set to 224 NO_CMCAST_STATE. If the PE cannot locate the upstream PE then it 225 should send a response to the Querier with the NO_UPSTREAM_PE error 226 code. 228 From the selected UMH route, the local PE extracts the ASN of the 229 upstream PE (as carried in the Source AS Extended Community of the 230 route), and the source-AS field of the mtrace Query is set to that 231 AS. 233 If the local and the upstream PEs are in the same AS, then the RD in 234 the mtrace Query is set to the RD of the VPN-IP route for the source/ 235 RP. 237 Section 8 of MVPN specification [RFC6513] mentions two procedures 238 (Segmented and Non-Segmented) for handling Inter-AS scenarios. If 239 the local and the upstream PEs are in different ASes, and if 240 segmented Inter-AS procedure is used, then the local PE finds in its 241 VRF an Inter-AS I-PMSI A-D route whose Source AS field carries the 242 ASN of the upstream PE. The RD of the found Inter-AS I-PMSI A-D 243 route is used as the RD of the mtrace Query. If Inter-AS I-PMSI A-D 244 route is not found, a response with error code UNKNOWN_INTER_AS is 245 sent. 247 To support non-segmented inter-AS tunnels, if the local and the 248 upstream PEs are in different ASes, the local system finds in its VRF 249 an Intra-AS I-PMSI A-D route from the upstream PE. The Originating 250 Router's IP Address field of that route has the same value as the one 251 carried in the VRF Route Import of the unicast route to the address 252 carried in the Multicast Source field. The RD of the found Intra-AS 253 I-PMSI A-D route is used as the RD in the mtrace Query. The Source 254 AS field in the mtrace Query is set to value of the Originating 255 Router's IP Address field of the found Intra-AS I-PMSI A-D route. 257 The PE receiving Mtrace Query will check for any errors. If any 258 error is detected it will send the error back to the Querier. 259 Otherwise, it will change the TLV value to be an Mtrace Request, and 260 it will add a Mtrace2 Standard Response Block. It will also add a 261 PMSI Tunnel Attributes Augmented Response Block with the attributes 262 of the PMSI used to receive traffic for the S,G. If a Leaf-AD route 263 was advertised to the upstream PE for this S,G then the PE will also 264 include a Leaf-AD Augmented Response Block with the NLRI of the 265 associated Leaf-AD route. 267 3.2.1. Ingress PE Procedures 269 The PE that receives the Request, will check the PMSI attributes of 270 the sender of request to see if they match the values used to send 271 traffic for the S,G. If the values do not match, then the PE uses 272 the appropriate pmsi error code as specified in 'MVPN Error Codes' 273 section and sends a mtrace Response back to the Querier. Also, if a 274 Leaf A-D Augmented Response Block is included, the PE will validate 275 that it has received this Leaf A-D route from the router that sent 276 the Request. If not, then this PE should change the error code to 277 BAD_LEAF_AD and send the Response to the Querier. If the PE expects 278 that a Leaf A-D route is needed for the downstream PE to receive 279 traffic, but did not receive one in the mtrace Request from the 280 sending router, then it should use a NO_LEAF_AD_RCVD error code for 281 the mtrace Response. For a wild card SPMSI query, if the PE didn't 282 receive LEAF AD route from the downstream PE, it should use 283 NO_LEAD_AD_RCVD error code. 285 When the upstream PE receives the Request, it will check for any 286 errors. If there are errors detected, or if the TTL expired, then 287 the PE will change the TLV code to be a Mtrace Response and unicast 288 the response back to the Querier. 290 The ingress PE will also check it has local vrf connectivity for the 291 source/RP. If it does not have any connectivity to the source/RP 292 then it should use the base specification error code NO_ROUTE and 293 send an mtrace Response. Note that in a Virtual Hub and Spoke 294 environment, it is possible for a PE to receive a mtrace Request and 295 need to propagate it to another upstream PE. These procedures are 296 outlined in the section "Virtual Hub and Spoke". If the PE does not 297 expect to be receiving mtrace Responses from the mvpn core and have 298 the route to the source located via another upstream PE, then it can 299 use the base specification RPF_IF error code. 301 If the PE that receives the Request is the ingress PE that has local 302 vrf connectivity for the source, then it will add a Standard Response 303 Block to the mtrace message. It will not include the additional PMSI 304 Attributes Response Block. Then it will turn the Request into a 305 Downstream Request by changing the value of the Type field of the 306 TLV. It will send the mtrace message on the provider tunnel used to 307 send the S,G data traffic. 309 3.3. Downstream Requests 311 When a router receives Mtrace Downstream Request, it will determine 312 if it has added any of the Response Blocks for this mtrace message. 313 If it does not locate its address in the list of Response Blocks, 314 then it will silently discard this mtrace message. Otherwise, it 315 will set the 'D' bit in its PMSI Tunnel Attributes Augmented Response 316 Block to indicate that this message has been received on the PMSI 317 tunnel. 319 If this router is the egress PE that provided the initial Response 320 Block, then it will change the mtrace type to a Reply and sends the 321 Reply to the Querier (the egress PE and the Querier may be the same 322 router). Otherwise, this router must send the Downstream PE on the 323 PMSI that it would normally send traffic for the S,G. Before sending 324 the Downstream Request, the router must decrement the TTL and check 325 for TTL expiry. If the TTL has expired, then this router must send 326 the Response to the Querier with the appropriate code. 328 3.4. ASBR Behavior 330 When an ASBR receives a mtrace Request the ASBR finds an Inter-AS 331 I-PMSI A-D route whose RD and Source AS matches the RD and Source AS 332 carried in the mtrace Query. If no matching route is found and the 333 ASBR is using segmented tunnels as described in MVPN specification 334 [RFC6513], the ASBR sends an UNKNOWN_INTER_AS error code back to the 335 Querier. If a matching route is found, the ASBR acts as a "first hop 336 router" and modifies the Query type to DOWNSTREAM_REQUEST. ASBR in 337 this case MUST validate the PMSI attributes similar to the "first hop 338 router" and respond if there is any errors. ASBR MUST populate PMSI 339 Tunnel Attributes Augmented Response Block with the Inter-AS provider 340 tunnel information before sending the DOWNSTREAM_REQUEST. Note that 341 the mtrace request does not proceed upstream as it is assumed that 342 performing a traceroute and exposing IP addresses across AS 343 boundaries would not be desirable with Segmented Inter-AS Provider 344 Tunnels. 346 To support non-segmented inter-AS tunnels as described in [RFC6513], 347 instead of matching the RD and Source AS carried in the mtrace Query 348 against the RD and Source AS of an Inter-AS I-PMSI A-D route, the 349 ASBR should match it against the RD and the Originating Router's IP 350 Address of the Intra- AS I-PMSI A-D routes. The Next Hop field of 351 the MP_REACH_NLRI of the found Intra-AS I-PMSI A-D route is used as 352 the destination for the mtrace Request. 354 3.5. Virtual Hub and Spoke 356 When a Virtual-Hub (V-HUB) as described in specification 357 [I-D.ietf-l3vpn-virtual-hub] receives a mtrace Request the S,G may be 358 reachable via one of its vrf interfaces. In this case, the V-HUB is 359 an ingress PE and the procedure are defined in the Section "Ingress 360 PE Procedures". Otherwise, the C-RP/C-S of the route is reachable 361 via some other PE. This is the case where the received route was 362 originated by a Virtual-spoke (V-spoke) that sees the V-HUB as the 363 "upstream PE" for the given source, but the V-HUB sees another PE as 364 the "upstream PE" for that source. In this case, the V-HUB should 365 check the PMSI attributes sent in the mtrace Request against the 366 Tunnel Attributes of the Provider Tunnel used to send traffic for the 367 S,G from the upstream PE to the V-Spoke. 369 The V-HUB sends a mtrace Request to its upstream PE the same way as 370 it would if it received a mtrace Query. V-HUB MUST add PMSI Tunnel 371 Attributes Augmented Response Block of its own before sending the 372 mtrace Request to the upstream PE. It may also add Leaf-AD Augmented 373 Response Block if a Leaf-AD route was advertised upstream by the 374 V-HUB. If the RD or Source-AS of the upstream PE is different, the 375 V-HUB updates the MVPN Extended Query Block accordingly. 377 3.6. Inter-Area Provider Tunnels 379 3.6.1. Egress PE 381 The egress PE does the same procedures as specified in 382 Section "Mtrace Request" except it sends the Request upstream to the 383 IP address determined from the Global Administrator field of the 384 Inter-area P2MP Segmented Next-hop Extended Community as described in 385 specification [I-D.ietf-mpls-seamless-mcast] . If the egress PE has 386 sent a Leaf-AD route then it must send a Leaf-AD Augmented Response 387 Block with the NLRI of the Leaf A-D route. 389 3.6.2. ABR Behavior 391 ABR MUST find a S-PMSI or I-PMSI route whose NLRI has the same value 392 as the Route Key field of the received mtrace Leaf-AD extended Query 393 Block. If such a matching route is not found then a Response should 394 be sent to the Querier with the NO_LEAF_AD_RCVD. If the ABR has sent 395 a Leaf-AD route then it must add a Leaf-AD Augmented Response Block 396 with the values of Leaf A-D route NLRI. The upstream node's IP 397 address is the IP address determined from the Global Administrator 398 field of the Inter-area P2MP Segmented Next-hop Extended Community. 400 3.7. Mtrace MVPN Procedure 402 In this section, we will briefly discuss the Mtrace procedure taking 403 a working and non-working network topology. 405 Querier + Egress PE + PE/ASBR/ABR + Ingress PE 406 | | | | 407 | Query | | | 408 |+----------->| | | 409 | | Request | | 410 | |+------------> | | 411 | | | Request | 412 | | |+----------------->| 413 | | | | 414 | | | | 415 | | | Downstream Request| 416 | | |<-----------------+| 417 | Response | Downstream Request| | 418 |<----------- | <-----------------+ | 419 | | | | 420 | | | | 421 v v v v 423 Mtrace MVPN Procedure 425 The above figure depicts the path of MTRACE in working condition. 426 MTRACE request for MVPN can traverse multiple hops when a Virtual HUB 427 is present or when segmented P2MP inter-area tunnels are used. If no 428 error conditions are detected the downstream request will travel the 429 same path as the regular multicast packet for the queried mroute 430 would flow. The last hop router/egress router will convert it into a 431 Response and send it back to querier 433 Let us consider a non-working case where Mtrace is expected to be 434 used. Taking Virtual-HUB as an example, assume that there is a data- 435 path issue between V-HUB and Egress Spoke. The below steps take 436 place to determine the issue between V-HUB and egress Spoke 438 1 - Querier sends the Mtrace Query towards LHR (Egress PE-Spoke). 440 2 - Egress PE sends Request to V-HUB. V-HUB realises that the 441 first hop router is a connected spoke and sends the request to 442 Ingress Spoke PE. 444 3 - Ingress Spoke PE sends Downstream Request to V-HUB. The same 445 is received by V-HUB. V-HUB sets the 'D' bit in its PMSI Tunnel 446 Attributes Augmented Response Block. 448 4 - V-HUB sends Downstream request to ingress spoke. This is 449 never received by the ingress spoke. 451 5 - The result of first 4 steps is that querier did not receive 452 the response. This makes the querier fall back to TTL method. 454 6 - Querier reduces the TTL and the result will show that the hop 455 from V-HUB to ingress spoke is missing thereby pointing the issue 456 at the right place. 458 4. Error Detection 460 All routers will check for normal multicast errors as defined in the 461 Mtracev2 specification. In addition, they will check for errors 462 specific to MVPNs and this specification. 464 All receiving routers will check the state of the Provider Tunnel 465 used for forwarding traffic for the given S,G. The ability and 466 manner to check if the Provider Tunnel is down depends on the 467 Provider Tunnel type. If the Provider Tunnel is known to be down the 468 PE will respond with a PTUNNEL_DOWN error. 470 In some situations the router needs to send a Leaf AD route to the 471 upstream PE. If the upstream expects a Leaf AD route, but did not 472 receive one from the downstream PE, then the NO_LEAF_AD_RCVD error 473 will be sent. 475 The receiving router will check the values of the PMSI Tunnel 476 attributes to see if they match the expected values for the PMSI. If 477 an Inclusive-PMSI is used, then the router will verify that the 478 values match those in the I-PMSI A-D route. If a Selective PMSI is 479 used, then the Tunnel Attributes will be matched against the S-PMSI 480 or Leaf A-D Route, depending on the Tunnel Type. If the values do 481 not match, then a error code of the corresponding PMSI mismatch will 482 be sent. 484 If a router receives a MVPN traceroute, but does not have the proper 485 MVPN configuration, then it will respond with a UNEXPECTED_MVPN error 487 4.1. MVPN Error Codes 488 Value Name Description 489 ----- -------------- -------------------------------------- 490 0x11 PTUNNEL_DOWN The provide tunnel for this S,G is down. 492 0x12 NO_LEAF_AD_RCVD The S-PMSI has not been joined by 493 downstream neighbor 495 0x13 BAD_LEAF_AD The Leaf A-D route does not match 496 the expected values 498 0x14 BAD_RD The RD is known to not exist on this PE 500 0x15 UNEXPECTED_MVPN The MVPN traceroute message is unexpected 502 0x16 BAD_PMSI_ATTR_FLAG Error matching the PMSI attribute flag 504 0x17 BAD_PMSI_ATTR_TYPE Error matching the PMSI attribute type 506 0x18 BAD_PMSI_ATTR_LABEL Error matching the PMSI attribute label 508 0x19 BAD_PMSI_ATTR_ID Error matching the PMSI attribute tunnel 509 identifier 511 0x1a UNKNOWN_INTER_AS Could not locate the Inter-AS provider 512 tunnel segment. 514 0x1b NO_UPSTREAM_PE No valid upstream PE or route 516 0x1c NO_CMCAST_STATE No C-Mcast route for the requested query 518 0x1d NO_WILD_CARD_SPMSI_AD_RCVD No Wild Card SPMSI SPMSI AD is received from the upstream PE 519 0x1e NO_WILD_CARD_SPMSI_LEAD_AD_SENT PE did not send LEAF-AD route for the wild card SPMSI 521 5. Mtracev2 Extensions 523 5.1. New Mtracev2 TLV Type 525 A new Mtracev2 TLV type will be created for the Mtrace2 Downstream 526 Request. 528 5.2. MVPN Extended Query Block 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type | Length | MBZ |T| 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Extended Query Type | MBZ | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Route | 537 + + 538 | Distinguisher | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Source-AS | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Upstream PE | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 MVPN Extended Query Block 547 Type: Mtrace2 Extended Query Block Type 549 Length: Length of the MVPN Extended Query Block 551 MBZ: Sent with all 0's, ignored on receipt 553 T bit: This bit should be 0 555 Extended Query Type: New type defined 557 MBZ: Sent with all 0's, ignored on receipt 559 Route Distinguisher: The RD of the S,G that should be traced 561 Source-AS: The Autonomous System Number (ASN) of the Source 563 Upstream PE: IP Address of the Upstream PE 565 5.3. Leaf A-D Augmented Response Block 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Value .... | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Leaf A-D Augmented Response Block 575 MBZ: Sent with all 0's, ignored on receipt 577 Type: New type defined 579 Value: The NLRI value of the associated Leaf A-D route 581 5.4. PMSI Tunnel Attributes Augmented Response Block 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Type |D| MBZ | Value.. | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 PMSI Tunnel Attributes Augmented Response Block 591 MBZ: Sent with all 0's, ignored on receipt 593 Type: New type defined 595 D: 'D' bit indicating that Downstream Request is received on PMSI 597 Value: The PMSI Tunnel Attribute as defined in RFC 6514 599 6. Mtrace2 Standard Response Block considerations 601 The PEs in the MVPN Mtrace add the Standard Response Block as defined 602 in Mtrace2 [I-D.ietf-mboned-mtrace-v2]. For a PE, the incoming or 603 outgoing interface can be a Tunnel. The First Hop Router (FHR) PE 604 which is connected to the source SHOULD populate the incoming 605 interface address with the respective interface connected to the CE. 606 The outgoing interface address MAY be populated with 0 in this case. 607 Other routers in the mtrace path MAY populate incoming and outgoing 608 interface address fields as 0. 'Multicast Rtg Protocol' field MUST 609 be populated with 0s by the Last Hop Router (LHR). First Hop Router 610 (FHR) can populate this field with respective multicast routing 611 protocol used towards its upstream CE. All the remaining fields of 612 the Standard Response Block are populated as defined by the Mtrace2 613 [I-D.ietf-mboned-mtrace-v2] specification. 615 7. IANA Considerations 617 New TLV Type for MTRACE_MVPN_QUERY, MTRACE_MVPN_REQUEST, 618 MTRACE_MVPN_DOWNSTREAM_REQUEST, MTRACE_MVPN_RESPONSE 620 8. Security Considerations 622 There are no security considerations for this design other than what 623 is already in the mtracev2 specification. 625 9. Acknowledgments 627 The authors would like to thank Yakov Rekhter and Marco Rodrigues for 628 their valuable review and feedback. 630 10. Normative References 632 [I-D.ietf-l3vpn-virtual-hub] 633 Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 634 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 635 VPNs", draft-ietf-l3vpn-virtual-hub-08 (work in progress), 636 July 2013. 638 [I-D.ietf-mboned-mtrace-v2] 639 Asaeda, H. and W. Lee, "Mtrace Version 2: Traceroute 640 Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-10 641 (work in progress), July 2013. 643 [I-D.ietf-mpls-seamless-mcast] 644 Rekhter, Y. and R. Aggarwal, "Inter-Area P2MP Segmented 645 LSPs", draft-ietf-mpls-seamless-mcast-14 (work in 646 progress), July 2014. 648 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 649 VPNs", RFC 6513, February 2012. 651 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 652 Encodings and Procedures for Multicast in MPLS/BGP IP 653 VPNs", RFC 6514, February 2012. 655 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 656 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 657 6625, May 2012. 659 Authors' Addresses 661 Robert Kebler 662 Juniper Networks 663 10 Technology Park Drive 664 Westford, MA 01886 665 USA 667 Email: rkebler@juniper.net 668 Pavan Kurapati 669 Juniper Networks 670 1194 N. Mathilda Ave 671 Sunnyvale, CA 94089 672 USA 674 Email: kurapati@juniper.net 676 Saud Asif 677 AT&T LABS 678 200 S Laurel Ave. 679 Middletown, NJ 07748 680 USA 682 Email: sasif@att.com