<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC6514 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6514.xml">
<!ENTITY RFC6513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6513.xml">
<!ENTITY I-D.ietf-mboned-mtrace-v2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mboned-mtrace-v2.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-kebler-kurapati-l3vpn-mvpn-mtrace-07" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="MVPN Mtrace">Multicast Traceroute for MVPNs</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Robert Kebler" initials="R." surname="Kebler">
     <organization>Juniper Networks</organization>
     <address>
       <postal>
         <street>10 Technology Park Drive</street>
         <city>Westford</city>
         <region>MA</region>
         <code>01886</code>
         <country>USA</country>
       </postal>
       <email>rkebler@juniper.net</email>
      </address>
    </author>

    <author fullname="Pavan Kurapati" initials="P." surname="Kurapati">
     <organization>Juniper Networks</organization>
     <address>
       <postal>
         <street>1194 N. Mathilda Ave</street>
         <city>Sunnyvale</city>
         <region>CA</region>
         <code>94089</code>
         <country>USA</country>
       </postal>
       <email>kurapati@juniper.net</email>
      </address>
    </author>

    <author fullname="Saud Asif" initials="S." surname="Asif">
     <organization>AT&amp;T LABS</organization>
     <address>
       <postal>
         <street>200 S Laurel Ave.</street>
         <city>Middletown</city>
         <region>NJ</region>
         <code>07748</code>
         <country>USA</country>
       </postal>
       <email>sasif@att.com</email>
      </address>
  </author>
  <author initials="Mankamana" surname="Mishra"
      fullname="Mankamana Mishra">
      <organization>Cisco Systems</organization>

      <address>
          <postal>
              <street>821 Alder Drive,</street>

              <region>MILPITAS, CALIFORNIA 95035</region>

              <country>UNITED STATES</country>
          </postal>

          <phone></phone>
          <email>mankamis@cisco.com</email>
      </address>
  </author>
      <author initials="Stig" surname="Venaas"
    fullname="Stig Venaas">
      <organization>Cisco Systems</organization>

      <address>
       <postal>
         <street>821 Alder Drive,</street>

        <region>MILPITAS, CALIFORNIA 95035</region>

        <country>UNITED STATES</country>
       </postal>

       <phone></phone>
       <email>stig@cisco.com</email>
       </address>
    </author>
  
    <date year="2021" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Routing Area</area>

    <workgroup>L3VPN</workgroup>

    <abstract>

      <t>Mtrace is a tool used to troubleshoot issues in a network deploying Multicast service. When multicast is used within a VPN service offering, the 
	  base Mtrace specification does not detect the failures. This document specifies a method of using multicast traceroute in a network offering Multicast in
	  VPN service.  
      </t>



    </abstract>
  </front>

  <middle>
<section title="Introduction">
<t>
The current multicast traceroute <xref target='I-D.ietf-mboned-mtrace-v2'/> travels up the tree hop-by-hop towards the source.  This verifies the basic multicast
state back to the source, but is not sufficient to verify the MVPN state. The base Mtrace specification assumes that the routers in the path are directly 
connected through interfaces. In the case of Multicast traffic over VPN service, the PEs who are MVPN neighbors may be separated by several router hops. 
The path taken by the query can be completely different from the path taken through core by the actual multicast traffic. 
Consider a case in the below figure, where provider tunnel between PE2 (Source) and PE1 (Receiver) is not established correctly due to incorrect MVPN state on PE2. 
In the current form of Mtrace, the Query would result in a successful response since there is no error detection mechanism for MVPN state available currently.
Even if one can infer from the statistics of the Mtrace Response that PE2 has an issue, the existing error codes are not sufficient to identify the root cause.  
Also, there could be a problem sending traffic over the provider tunnel from PE2 to PE1, but the mtrace query will not even travel over this provider tunnel. 
Therefore, the mtrace successful response can be misleading. This draft ensures that the Response uses same provider-tunnel that the given C-S,C-G data would traverse 
and returns appropriate MVPN specific error codes which would help in identifying the root cause.
</t>

<figure title="MVPN topology">
<artwork>


                                    xxxxxx
                          xxxxxxxxxxx    xxxx      +-----+
                        xxx                  xxx   |     |   +---+
                       xx                      xx+-+ PE2 +---+CE2|
           +-----+    xx                         xx|     |   +---+
   +---+   |     |   x       Provider             x+-----+
   |CE1+---+ PE1 +--+x        Core              xxxx
   +---+   |     |   x                         xx
           +-----+   xx                        xxx  +----+
                      xxx                        x+-+    |   +---+
                        xxxxxxx        xxxxxxxxxxx  | PE3+---+CE3|
                              xx      xx            |    |   +---+
                               xxxxxxxx             +----+
								  
</artwork>
</figure>

</section>

<section title="Overview">

<t>
As described in the Mtracev2 specification <xref target='I-D.ietf-mboned-mtrace-v2'/>, 
a Querier initiates an Mtrace Query which is sent to the Last Hop Router.
Last Hop Router converts this into a Request and sends it towards the First Hop Router. 
This draft introduces a new "Downstream Request"  mechanism to allow the First Hop Router 
to send the mtrace request message back on the Provider tunnel to the Last hop router. The last 
hop router will then change it to Response and send it to the Querier who initiated the 
Query. If there is any error encountered by the Last hop router or First Hop router, a 
Response is directly unicasted to the querier with appropriate MVPN specific error codes 
added. Each hop in the path of Mtrace decrements the TTL value before sending the mtrace message.
</t>
<t>
Since the Mtrace is being extended for MVPNs, the Last Hop router and First Hop router 
SHOULD be a Provider Edge (PE) router so that the MVPN specific error codes can be contained 
within the provider space. The Request will be initiated by the egress PE and will travel 
upstream to the ingress PE. It is assumed that the Querier knows and can reach the egress 
PE. A Querier and egress PE can be the same router. 
</t>
<t>
For Mtrace initiated by the CEs, the specification mentioned in Mtracev2 <xref target='I-D.ietf-mboned-mtrace-v2'/> SHOULD be followed.
If a Mtrace message is received by the PE on CE facing interfaces containing MVPN specific extensions defined in this draft, it SHOULD be discarded. 
</t>
</section>
<section title="Protocol Details">
<t>
The protocol details that follow are described in terms of mtracev2.  However, the 
same procedures can be achieved with mtracev1. The protocol extensions needed for 
mtracev2 are described in Section 5 and the protocol extensions for mtracev1 and 
described in section 6.
</t>
<section title="Mtrace Query">
<t>
A Querier willing to perform a Mtrace on a MVPN issues a Mtrace Query.  The format of the 
Query TLV is as specified in the  Mtracev2 specification <xref target='I-D.ietf-mboned-mtrace-v2'/>.  
The (C-S,C-G) to be queried is populated in the source address and group address fields of the Mtrace2 Query block. 
A deployment may use wild card SPMSIs as defined in <xref target='RFC6625'/>. 
For example, a (C-*,C-*) wild card SPMSI or a (C-*,ALL-PIM-ROUTERS) can be used to send messages like BSR across PEs as mentioned in
section 5.3.4 MVPN specification  <xref target='RFC6513'/>. A querier may be interested in knowing the health of such a SPMSI tunnel. 
In this case, the Multicast Address and Source Address fields of the Mtrace2 query can be filled with wild cards (all 1s) accordingly by the querier.
</t>
<t>
The Querier MUST add a MVPN Extended Query Block to include the RD of the C-S,C-G that 
it wishes to trace. When wild card SPMSIs are used, a PE could have subscribed to multiple upstream PEs for wild card SPMSIs. Hence, a query
for a wild card SPMSI MUST also specify the upstream PE address that it is interested to query. The upstream PE address in the MVPN Extended
Query Block MUST be filled only for wild card queries. For a regular (C-S,C-G) query, this field SHOULD be set to 0s by the querier and is 
ignored by the receivers. 
</t>
<t>
This Query is sent to the Downstream PE (Last Hop Router)to initiate the mtrace towards the source.  
If a Querier does not receive a Response, it can retry sending Query messages with increasing TTL 
values to help diagnose where the Mtrace messages are being lost.  
</t>
</section>
<section title="Mtrace Request">
<t>
The PE that receives the query will lookup the (C-S,C-G) using the RD of the query to distinguish the vrf. If the RD doesnt match any VRF, PE sends 
a response with error code set to BAD_RD. The PE first checks the C-Mcast route that is matching (C-S,C-G) of the mtrace Query. It then finds the upstream multicast hop from the selected
C-Mcast route and unicasts the requests to the upstream multicast hop after decrementing the TTL. The Mtrace Request MUST have PMSI Tunnel Attributes Augmented Response Block populated 
with the PMSI attribute that the PE uses to receive the traffic for the given (C-S,C-G) traffic. 
</t>
<t>
 Upstream multicast hop can be same as upstream PE router in some cases, while it can be
the ASBR or the BGP nexthop of the selected C-Mcast route in Inter-AS scenarios. The procedures for finding upstream multicast hop is discussed in detail
under section 5.1 of MVPN specification <xref target='RFC6513'/>. 
</t>
<t>
When a wild card query is received, the PE will look for the upstream PE address in the MVPN Extended query block. The PE will then check if it has bound to
the wild card SPMSI tunnel from the specified upstream PE. If it has, it will populate the Leaf A-D Augmented Response Block and PMSI Tunnel Attributes
Augmented Response Block with the respective values. If the PE has not received any wild card SPMSI AD route from the specified upstream PE in the query, it 
should send a response with the error code set to NO_WILD_CARD_SPMSI_AD_RCVD. If the PE has received wild card SPMSI AD route from the upstream PE, but has
not responded with a LEAF-AD route, it should send a response with the error code set to NO_WILD_CARD_SPMSI_LEAF_AD_SENT.
</t>
<t>
For a non-wild-card query, the upstream PE address field in the MVPN Extended query block MUST be ignored by the PEs. It MUST follow the procedure to find the
upstream multicast hop as discussed earlier.
</t>
<t>
If the route does not match any MVPN-TIB state, then the PE should send a Response to the Querier with the 
error code set to NO_CMCAST_STATE. 

If the PE cannot locate the upstream PE then it should send a response to the Querier with the 
NO_UPSTREAM_PE error code.

</t>

<t>
 From the selected UMH route, the local PE extracts the ASN of the
 upstream PE (as carried in the Source AS Extended Community of the
 route), and the source-AS field of the mtrace Query is set to that AS.  
</t>
<t>

If the local and the upstream PEs are in the same AS, then the RD 
in the mtrace Query is set to the RD of the VPN-IP route for the source/RP.

</t>

<t> 
Section 8 of MVPN specification <xref target='RFC6513'/> mentions two procedures (Segmented and Non-Segmented) for handling
Inter-AS scenarios. If the local and the upstream PEs are in different ASes, and if segmented Inter-AS procedure is used, then the
local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source AS field carries the ASN of the upstream PE. The RD of the found
Inter-AS I-PMSI A-D route is used as the RD of the mtrace Query.  If Inter-AS I-PMSI A-D route is not found, a response with
error code UNKNOWN_INTER_AS is sent.
</t>
<t>

To support non-segmented inter-AS tunnels, if the
local and the upstream PEs are in different ASes, the local system
finds in its VRF an Intra-AS I-PMSI A-D route from the upstream PE. The Originating 
Router's IP Address field of that route has the same
value as the one carried in the VRF Route Import of the unicast
route to the address carried in the Multicast Source field.  The RD
of the found Intra-AS I-PMSI A-D route is used as the RD in the mtrace Query.  
The Source AS field in the mtrace Query is set to value of the Originating Router's 
IP Address field of the found Intra-AS I-PMSI A-D route.
</t>
<t>
The PE receiving Mtrace Query will check for any errors.  If any error is detected it will send the error 
back  to the Querier.  Otherwise, it will change the TLV value to be an Mtrace Request, 
and it will add a Mtrace2 Standard Response Block. It will also add a PMSI Tunnel 
Attributes Augmented Response Block with the attributes of the PMSI used to receive 
traffic for the S,G.  If a Leaf-AD route was advertised to the upstream PE for this 
S,G then the PE will also include a Leaf-AD Augmented Response Block with the NLRI 
of the associated Leaf-AD route.
</t>

<section title="Ingress PE Procedures">
<t>
The PE that receives the Request, will check the PMSI attributes of the sender of 
request to see if they match the values used to send traffic for the S,G. If the 
values do not match, then the PE uses the appropriate pmsi error code as specified in 'MVPN Error Codes' section
and sends a mtrace Response back to the Querier.  Also, if a 
Leaf A-D Augmented Response Block is included, the PE will validate that it has 
received this Leaf A-D route from the router that sent the Request.  If not, then 
this PE should change the error code to BAD_LEAF_AD and send the Response to the 
Querier.  If the PE expects that a Leaf A-D route is needed for the downstream PE 
to receive traffic, but did not receive one in the mtrace Request from the sending 
router, then it should use a NO_LEAF_AD_RCVD error code for the mtrace Response. For a wild card SPMSI query, if
the PE didn't receive LEAF AD route from the downstream PE, it should use NO_LEAD_AD_RCVD error code.
</t>
<t>
When the upstream PE receives the Request, it will check for any errors.  If there 
are errors detected, or if the TTL expired, then the PE will 
change the TLV code to be a Mtrace Response and unicast the response back to the Querier.  
</t>

<t>
The ingress PE will also check it has local vrf connectivity for the source/RP.  If 
it does not have any connectivity to the source/RP then it should use the base 
specification error code NO_ROUTE and send an mtrace Response.  Note that in a 
Virtual Hub and Spoke environment, it is possible for a PE to receive a mtrace Request 
and need to propagate it to another upstream PE.  These procedures are outlined in 
the section "Virtual Hub and Spoke".  If the PE does not expect to be receiving mtrace 
Responses from the mvpn core and have the route to the source located via another 
upstream PE, then it can use the base specification RPF_IF error code.
</t>

<t>

If the PE that receives the Request is the ingress PE that has local vrf 
connectivity for the source, then it will add a Standard Response Block 
to the mtrace message.  It will not include the additional PMSI Attributes 
Response Block. Then it will turn the Request into a Downstream Request 
by changing the value of the Type field of the TLV.  It will send the 
mtrace message on the provider tunnel used to send the S,G data traffic.

</t>
</section>





</section>
<section title="Downstream Requests">
<t>
When a router receives Mtrace Downstream Request, it will determine if it has 
added any of the Response Blocks for this mtrace message.  If it does not 
locate its address in the list of Response Blocks, then it will silently 
discard this mtrace message.  Otherwise, it will set the 'D' bit in its PMSI Tunnel Attributes Augmented Response Block to indicate 
that this message has been received on the PMSI tunnel. 
</t>
<t>
If this router is the egress PE that provided the initial Response Block, then 
it will change the mtrace type to a Reply and sends the Reply to the Querier 
(the egress PE and the Querier may be the same router).  Otherwise, this router 
must send the Downstream PE on the PMSI that it would normally send traffic 
for the S,G.  Before sending the Downstream Request, the router must decrement 
the TTL and check for TTL expiry.  If the TTL has expired, then this router 
must send the Response to the Querier with the appropriate code.
</t>
</section>

<section title="ASBR Behavior">
<t>
When an ASBR receives a mtrace Request the ASBR finds
an Inter-AS I-PMSI A-D route whose RD and Source AS matches the RD
and Source AS carried in the mtrace Query.  If no matching route
is found and the ASBR is using segmented tunnels as described in MVPN specification <xref target='RFC6513'/>,
the ASBR sends an UNKNOWN_INTER_AS error code back to the Querier.  
If a matching route is found, the ASBR acts as a "first hop router" and 
modifies the Query type to DOWNSTREAM_REQUEST. ASBR in this case MUST validate the PMSI attributes similar to the "first hop router" 
and respond if there is any errors. ASBR MUST populate PMSI Tunnel Attributes Augmented Response Block with
the Inter-AS provider tunnel information before sending the DOWNSTREAM_REQUEST. Note that the mtrace 
request does not proceed upstream as it is assumed that performing a 
traceroute and exposing IP addresses across AS boundaries would not be 
desirable with Segmented Inter-AS Provider Tunnels.
</t>
<t>

To support non-segmented inter-AS tunnels as described in <xref target='RFC6513'/>, instead of matching the RD
and Source AS carried in the mtrace Query against the RD and
Source AS of an Inter-AS I-PMSI A-D route, the ASBR should match it
against the RD and the Originating Router's IP Address of the Intra-
AS I-PMSI A-D routes.  The Next Hop field of the MP_REACH_NLRI of the 
found Intra-AS I-PMSI A-D route is used as the destination for the mtrace 
Request.
</t>
</section>

<section title="Virtual Hub and Spoke">
<t>
When a Virtual-Hub (V-HUB) as described in specification <xref target='I-D.ietf-l3vpn-virtual-hub'/> receives a mtrace Request the S,G may be reachable 
via one of its vrf interfaces.  In this case, the V-HUB is an ingress PE and the procedure are defined in the Section "Ingress PE Procedures". Otherwise, 
the C-RP/C-S of the route is reachable via some other PE. This is the case where the received route was originated by a 
Virtual-spoke (V-spoke) that sees the V-HUB as the "upstream PE" for the given source, but the V-HUB sees another PE as the "upstream PE" for 
that source. In this case, the V-HUB should check the PMSI attributes sent in the mtrace Request against the Tunnel Attributes of the Provider 
Tunnel used to send traffic for the S,G from the upstream PE to the V-Spoke. 
</t>
<t>
The V-HUB sends a mtrace Request to its upstream PE the same way as it would 
if it received a mtrace Query. V-HUB MUST add PMSI Tunnel Attributes Augmented Response Block of its own before sending the mtrace Request to the upstream PE. It may
also add Leaf-AD Augmented Response Block if a Leaf-AD route was advertised upstream by the V-HUB. If the RD or Source-AS of the upstream PE is different, the V-HUB
updates the MVPN Extended Query Block accordingly.

</t>
</section>

<section title="Inter-Area Provider Tunnels">
<section title="Egress PE">
<t>

 The egress PE does the same procedures as specified in Section "Mtrace Request" 
except it sends the Request upstream to the IP address determined from the
   Global Administrator field of the Inter-area P2MP Segmented Next-hop
   Extended Community as described in specification <xref target='I-D.ietf-mpls-seamless-mcast'/> . If the egress PE has sent a Leaf-AD route then it must 
send a Leaf-AD Augmented Response Block with the NLRI of the Leaf A-D route. 
  
</t>

</section>

<section title="ABR Behavior">
<t>
 ABR MUST find a S-PMSI or I-PMSI route
   whose NLRI has the same value as the Route Key field of the received mtrace 
Leaf-AD extended Query Block. If such a matching route is not found then a 
Response should be sent to the Querier with the NO_LEAF_AD_RCVD.  If the 
ABR has sent a Leaf-AD route then it must add a Leaf-AD Augmented Response 
Block with the values of Leaf A-D route NLRI.  The upstream node's IP address 
is the IP address determined from the Global Administrator field of the 
Inter-area P2MP Segmented Next-hop Extended Community.
</t>



</section>
</section>

<section title="Mtrace MVPN Procedure">
<t>
In this section, we will briefly discuss the Mtrace procedure taking a working and non-working network topology.
</t>
<figure title="Mtrace MVPN Procedure">
<artwork> <![CDATA[


Querier       + Egress PE         + PE/ASBR/ABR      + Ingress PE        
|             |                   |                   |                   
|  Query      |                   |                   |                   
|+----------->|                   |                   |                   
|             |  Request          |                   |                   
|             |+------------>     |                   |                   
|             |                   |  Request          |                   
|             |                   |+----------------->|                   
|             |                   |                   | 
|             |                   |                   |
|             |                   | Downstream Request|                   
|             |                   |<-----------------+|                   
|  Response   | Downstream Request|                   |                   
|<----------- | <-----------------+                   | 
|             |                   |                   |                   
|             |                   |                   |                   
v             v                   v                   v                         
							
]]></artwork>
</figure>

<t>
The above figure depicts the path of MTRACE in working condition. MTRACE request for MVPN can traverse multiple hops 
when a Virtual HUB is present or when segmented P2MP inter-area tunnels are used. If no error conditions are detected
the downstream request will travel the same path as the regular multicast packet for the queried mroute would flow.
The last hop router/egress router will convert it into a Response and send it back to querier
</t>
<t>
Let us consider a non-working case where Mtrace is expected to be used. Taking Virtual-HUB as an example, assume that
there is a data-path issue between V-HUB and Egress Spoke. The below steps take place to determine the issue between
V-HUB and egress Spoke
</t>

<t>
<list>
<t>
1 - Querier sends the Mtrace Query towards LHR (Egress PE-Spoke).
</t>
<t>
2 - Egress PE sends Request to V-HUB. V-HUB realises that the first hop router is a connected spoke and sends the request to Ingress Spoke PE.
</t>
<t>
3 - Ingress Spoke PE sends Downstream Request to V-HUB. The same is received by V-HUB. V-HUB sets the 'D' bit in its PMSI Tunnel Attributes Augmented Response Block. 
</t>
<t>
4 - V-HUB sends Downstream request to ingress spoke. This is never received by the ingress spoke. 
</t>
<t>
5 - The result of first 4 steps is that querier did not receive the response. This makes the querier fall back to TTL method.
</t>
<t>
6 - Querier reduces the TTL and the result will show that the hop from V-HUB to ingress spoke is missing thereby pointing the issue at the right place.
</t>
</list>
</t>

</section>
</section>
<section title="Error Detection">
<t>
All routers will check for normal multicast errors as defined in the Mtracev2 
specification.  In addition, they will check for errors specific to MVPNs and this 
specification.
</t>

<t>
All receiving routers will check the state of the Provider Tunnel used for 
forwarding traffic for the given S,G.  The ability and manner to check if 
the Provider Tunnel is down depends on the Provider Tunnel type. If the Provider 
Tunnel is known to be down the PE will respond with a 
PTUNNEL_DOWN error.
</t>

<t>
In some situations the router needs to send a Leaf AD route to the upstream PE. 
If the upstream expects a Leaf AD route, but did not receive one from the 
downstream PE, then the NO_LEAF_AD_RCVD error will be sent.
</t>
<t>
The receiving router will check the values of the PMSI Tunnel attributes to see 
if they match the expected values for the PMSI.  If an Inclusive-PMSI is used, then 
the router will verify that the values match those in the I-PMSI A-D route.  
If a Selective PMSI is used, then the Tunnel Attributes will be matched 
against the S-PMSI or Leaf A-D Route, depending on the Tunnel Type.  If the values 
do not match, then a error code of the corresponding PMSI mismatch will be sent.
</t>
<t>
If a router receives a MVPN traceroute, but does not have the proper MVPN configuration, 
then it will respond with a UNEXPECTED_MVPN error
</t>

<section title="MVPN Error Codes">
<figure align="center" >
<artwork align="center"><![CDATA[

  Value  Name                                    Description
  ----- --------------                        --------------------------------------
  0x11  PTUNNEL_DOWN                          The provide tunnel for this S,G is down.

  0x12  NO_LEAF_AD_RCVD                       The S-PMSI has not been joined by
                                              downstream neighbor

  0x13  BAD_LEAF_AD                           The Leaf A-D route does not match
                                              the expected values

  0x14  BAD_RD                                The RD is known to not exist on this PE

  0x15  UNEXPECTED_MVPN                       The MVPN traceroute message is unexpected

  0x16  BAD_PMSI_ATTR_FLAG                    Error matching the PMSI attribute flag 

  0x17  BAD_PMSI_ATTR_TYPE                    Error matching the PMSI attribute type 

  0x18  BAD_PMSI_ATTR_LABEL                   Error matching the PMSI attribute label

  0x19  BAD_PMSI_ATTR_ID                      Error matching the PMSI attribute tunnel 
                                              identifier

  0x1a  UNKNOWN_INTER_AS                      Could not locate the Inter-AS provider
                                              tunnel segment.

  0x1b  NO_UPSTREAM_PE                        No valid upstream PE or route 
  
  0x1c  NO_CMCAST_STATE                       No C-Mcast route for the requested query
  
  0x1d  NO_WILD_CARD_SPMSI_AD_RCVD            No Wild Card SPMSI SPMSI AD is received from the upstream PE
  0x1e  NO_WILD_CARD_SPMSI_LEAD_AD_SENT       PE did not send LEAF-AD route for the wild card SPMSI


]]></artwork>
</figure>
</section>
</section>
<section title="Mtracev2 Extensions">

<section title="New Mtracev2 TLV Type">
<t>
A new Mtracev2 TLV type will be created for the Mtrace2 Downstream Request.
</t>
</section>
<section title="MVPN Extended Query Block">
<figure align="center" title="MVPN Extended Query Block">
<artwork align="center"><![CDATA[

    0                   1                   2                   3
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |           Length              |      MBZ    |T|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Extended Query Type      |           MBZ                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Route                             |
    +                                                               +
    |                         Distinguisher                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Source-AS                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Upstream PE                         |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
</figure>
<t><list>

<t>Type:  Mtrace2 Extended Query Block Type</t>
<t>Length:  Length of the MVPN Extended Query Block</t>
<t>MBZ:  Sent with all 0's, ignored on receipt</t>
<t>T bit:  This bit should be 0</t>
<t>Extended Query Type:  New type defined</t>
<t>MBZ:  Sent with all 0's, ignored on receipt</t>
<t>Route Distinguisher:  The RD of the S,G that should be traced</t>
<t>Source-AS:  The Autonomous System Number (ASN) of the Source</t>
<t>Upstream PE:  IP Address of the Upstream PE </t>
</list>
</t>
</section>
<section title="Leaf A-D Augmented Response Block">
<figure align="center" title="Leaf A-D Augmented Response Block">
<artwork align="center"><![CDATA[

   0                   1                   2                   3
   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                                               
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |           Value ....          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
</figure>
<t><list>

<t>MBZ:  Sent with all 0's, ignored on receipt</t>
<t>Type:  New type defined</t>
<t>Value:  The NLRI value of the associated Leaf A-D route</t>


</list>
</t>
</section>

<section title="PMSI Tunnel Attributes Augmented Response Block">
<figure align="center" title="PMSI Tunnel Attributes Augmented Response Block">
<artwork align="center"><![CDATA[

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |D|    MBZ      | Value..       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  

]]></artwork>
</figure>
<t><list>

<t>MBZ:  Sent with all 0's, ignored on receipt</t>
<t>Type:  New type defined</t>
<t>D: 'D' bit indicating that Downstream Request is received on PMSI </t>
<t>Value:  The PMSI Tunnel Attribute as defined in RFC 6514</t>

</list>
</t>
</section>

</section>


<section title="Mtrace2 Standard Response Block considerations">
<t>
The PEs in the MVPN Mtrace add the Standard Response Block as defined in Mtrace2 <xref target='I-D.ietf-mboned-mtrace-v2'/>. For a PE, the 
incoming or outgoing interface can be a Tunnel. The First Hop Router (FHR) PE which is connected to the source SHOULD populate the incoming interface address 
with the respective interface connected to the CE. The outgoing interface address MAY be populated with 0 in this case. 
Other routers in the mtrace path MAY populate incoming and outgoing interface address fields as 0. 'Multicast Rtg Protocol' field MUST be populated with 0s by the 
Last Hop Router (LHR). First Hop Router (FHR) can populate this field with respective multicast routing protocol used towards its upstream CE.
All the remaining fields of the Standard Response Block are populated as defined by the Mtrace2 <xref target='I-D.ietf-mboned-mtrace-v2'/> specification.
</t>
</section>



    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>New TLV Type for MTRACE_MVPN_QUERY, MTRACE_MVPN_REQUEST, MTRACE_MVPN_DOWNSTREAM_REQUEST, MTRACE_MVPN_RESPONSE</t>
   
      
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There are no security considerations for this design other than what
   is already in the mtracev2 specification.
</t>
    </section>
	<section title="Acknowledgments">
<t>
The authors would like to thank Yakov Rekhter and Marco Rodrigues for their valuable review and feedback.
</t>
</section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>


    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
    &RFC6514;
    &RFC6513;
	&I-D.ietf-mboned-mtrace-v2;
	<?rfc include="reference.RFC.6625.xml"?>
    <?rfc include="reference.I-D.ietf-l3vpn-virtual-hub.xml"?>
	<?rfc include="reference.I-D.ietf-mpls-seamless-mcast.xml"?>

    </references>




    <!-- Change Log


v00 2013-05-13  RK    Initial pass
    -->

  </back>
</rfc>
