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