Layer 3 IP VPN Andrew Dolganow Internet Draft Jayant Kotalwar Intended status: Standard track Alcatel-Lucent Updates: 6514, 6625 October 16, 2014 Expires: April 2015 Explicit tracking in MPLS/BGP IP VPNs draft-dolganow-l3vpn-mvpn-expl-track-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 16, 2009. Dolganow Expires April 16, 2015 [Page 1] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract RFC 6513 and RFC 6514 define encoding and procedures for multicast MPLS/BGP IP Virtual Private Networks (VPNs). As defined in these RFCs, in some cases when BGP is used to exchange C-multicast routes, a need may exist to explicitly track PEs joining the same C- multicast-tree. The RFCs define encoding and procedures for explicit tracking using "PMSI Tunnel attribute" and "Leaf A-D route"; however, the procedures are missing details and clarity. RFC 6625 defines encodings and procedures for wildcards in multicast MPLS/BGP IP VPNs. The RFC does not cover explicit tracking for wildcard multicast streams. This documents updates RFC 6514 and 6625 with procedures required to achieve explicit PE tracking for (C-S, C-G) and wildcard multicast streams. Table of Contents 1. Introduction...................................................3 1.1. Terminology...............................................3 2. Conventions used in this document..............................4 3. Explicit tracking request encoding.............................4 3.1. No S-PMSI A-D route for the multicast stream..............4 3.2. S-PMSI A-D route for the multicast stream exist...........4 4. Intra-AS explicit tracking procedures..........................4 4.1. Procedures on PE used to reach C-source...................5 4.1.1. No S-PMSI A-D route for the multicast stream.........5 4.1.2. S-PMSI A-D route for the multicast stream exist......5 4.2. Procedures on PE receiving S-PMSI route with explicit tracking "PMSI Tunnel attribute"...............................6 Dolganow Expires April 16, 2015 [Page 2] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 5. Inter-AS procedures............................................7 6. Security Considerations........................................7 7. IANA Considerations............................................7 8. Conclusions....................................................7 9. References.....................................................7 9.1. Normative References......................................7 9.2. Informative References....................................7 10. Acknowledgments...............................................7 1. Introduction Section 5.3.2 of [MVPN] describes the method for explicit tracking of PEs that join the same C-tree. A mechanism using "PMSI Tunnel attribute" and "Leaf A-D routes" is described, while for detailed procedures a reader is referred to [MVPN-BGP]. [MVPN-BGP] defines encoding and procedures for, among others, explicit tracking in: 1. Section 5. This section defines how to encode "PMSI Tunnel attribute" to initiate explicit tracking on a PE: the attribute must have "Leaf Information required" (L) flag set to 1, Tunnel Type field set to "No tunnel information". 2. Section 4.4. This section defines encoding of "Leaf A-D Route" attribute that is used by PEs to respond to explicit tracking requests as encoded above. The section then points to procedures in other sections (especially section 12.3) of [MVPN-BGP] on how to generate and process "Leaf A-D route" Following the above-procedures demonstrates that explicit tracking has not been fully incorporated into [MVPN-BGP] procedures. Therefore, a need exists to clarify and modify [MVPN-BGP] procedures for explicit tracking of PEs that join a given C-tree when BGP is used to exchange multicast routes. This document explicitly defines procedure clarification/modification required to achieve explicit PE tracking. 1.1. Terminology This document uses terminology from [MVPN] and [MVPN-BGP] and [MVPN- WC]. Dolganow Expires April 16, 2015 [Page 3] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 2. Conventions used in this document Wildcard streams term applies to each (C-*, C-G), (C-S, C-*) and (C- *, G-*) types of wildcard multicast streams as defined in [MVPN-WC] unless explicitly limited to only a subset of those wildcard types. Multicast stream term applies to (C-S, C-G) or a wildcard stream as defined above. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 Error! Reference source not found.. 3. Explicit tracking request encoding 3.1. S-PMSI A-D route without tunnel information This case applies when S-PMSI A-D route does not exist OR S-PMSI A-D route's Multicast Source and Multicast Group fields do not encode the stream to be tracked. A PE originating explicit tracking for the multicast stream MUST use MCAST-VPN NLRI of an S-PMSI A-D route with PMSI tunnel attribute encoded as per section 5 of [MVPN-BGP] including setting "Leaf Information required" (L) flag to 1 and Tunnel Type field set to "No tunnel information". 3.2. S-PMSI A-D route with tunnel information This case applies when S-PMSI A-D route's Multicast Source and Multicast Group fields encode the stream to be tracked. A PE originating explicit tracking for multicast stream SHOULD set the Leaf Information Required flag in the PMSI Tunnel attribute of the MCAST-VPN NLRI of the S-PMSI A-D route to 1 and keep all other fields unchanged. This ensures that this PE originates only a single S-PMSI A-D route for this (C-S, C-G) or wildcard stream. 4. Intra-AS explicit tracking procedures The following sections define procedures on PEs to support explicit tracking for Intra-AS. Dolganow Expires April 16, 2015 [Page 4] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 4.1. Procedures on Sender PE 4.1.1. S-PMSI A-D route without tunnel information To initiate explicit tracking for a (C-S, C-G) stream, a PE must originate S-PMSI A-D route as defined by procedures in section 12.1 of [MVPN-BGP] with the following modification: 1. PMSI tunnel attribute MUST be encoded as per section 4.1 above (i.e. the attribute does not contain P-multicast tree tunnel information) To initiate explicit tracking for a wildcard stream, a PE must originate an S-PMSI A-D route as defined by procedures in section 4 of [MVPN-WC] with the following modification: 1. PMSI tunnel attribute MUST be encoded as per section 4.1 above (i.e. the attribute does not contain P-multicast tree identity) 2. PE MUST exclude the above-generated S-PMSI A-D route when finding a match for Data transmission as specified in section 3.1 of [MVPN-WC] Upon receiving a Leaf A-D route in response to the explicit tracking request for a multicast stream, the PE performs regular procedures defined in section 9.2.3.5 of [MVPN-BGP]. Specific use of tracking information on the PE is out of scope for this specification. To terminate explicit tracking for multicast stream, a PE MUST withdraw the above-originated S-PMSI A-D route. If the sender PE decides to bound explicitly tracked stream to S-PMSI P-tunnel, the PE MUST execute procedures defined in section 12.1 of [MVPN-BGP] for (C-S, C-G) and, if applicable, procedures of section 4 of [MVPN-WC]. These procedures, among others, will re-originate S- PMSI A-D route with updated PMSI Tunnel attribute (including encoding of S-PMSI P-multicast tree tunnel information). If explicit tracking for the multicast stream is to continue, the resulting S-PMSI A-D route type will be encoded as per section 3.2 above. 4.1.2. S-PMSI A-D route with tunnel information The procedures defined in this section apply only if PE has originated S-PMSI A-D route with PMSI Tunnel attribute encoding the multicast stream to be tracked with Leaf Information Required flag set to 0. Dolganow Expires April 16, 2015 [Page 5] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 To initiate explicit tracking for the multicast stream, a PE SHOULD update the PMSI tunnel attribute with Leaf Information Required flag to 1 and re-originate the S-PMSI A-D route To stop explicit tracking for the multicast stream, a PE SHOULD re- originate S-PMSI A-D route with all information unchanged but Leaf Information Required flag set to 0. To continue explicit tracking for a multicast stream which is being switched from an S-PMSI tunnel to an I-PMSI tunnel, the PE should first execute procedures to initiate explicit tracking of a multicast stream as defined in section 4.1.1 above to ensure tracking information remains current during the switch. 4.2. Procedures on PE receiving S-PMSI route with explicit tracking "PMSI Tunnel attribute" We say a PE is to receive traffic for the explicitly tracked wildcard stream, if at least one (C-S, C-G) C-flow matches the S-PMSI A-D route encoding the explicitly tracked stream using procedures of section 3.2 of [MVPN-WC]. PE receiving S-MPSI A-D route with tracking request, performs procedures defined in section 12.3 of [MVPN-NG] either as result of receiving (C-S, C-G) tracking request or as consequence of procedures of section 4 of [MVPN-WC] for wildcard stream tracking request with the following modifications: 1. The procedures requiring set-up of forwarding path to receive traffic from the tunnel advertised by the S-PMSI route do not apply if the PMSI Tunnel attribute is encoded as per section 3.1 of this document. The PE continues to receive traffic on the current P-tunnel. 2. If a PE determines that it no longer is to receive traffic for an explicitly tracked multicast stream from the PE that originated explicit tracking for that streams, the PE MUST withdraw the Leaf A-D route originated in response to explicit tracking using standard procedures defined in [MVPN-BGP]. 3. If a PE determines that it is to receive traffic for an explicitly tracked multicast stream from the PE that originated explicit tracking for that streams, the PE MUST re-originate a Leaf A-D route as defined in [MVPN-BGP]. Dolganow Expires April 16, 2015 [Page 6] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 5. Inter-AS procedures Left for future study 6. Security Considerations No security considerations beyond those already covered by [MVPN], [MVPN-BGP] and [MVPN-WC] are introduced by this document. 7. IANA Considerations 8. Conclusions 9. References 9.1. Normative References [MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen and R. Aggarwal, editors, RFC 6513, February 2012 [MVPN-BGP]"BGP encodings and Procedures for Multicast in MPLS/BGP IP VPNs", R. Aggarwa, E. Rosen, T. Morin, and Y. Rekhter, RFC 6514, February 2012 [MVPN-WC] "Wildcards in Multicast VPN Auto-Discovery Routes", E. Rosen, Y. Rekhter, W. Hendrickx, R. Qiu, RFC 6625, May 2012 [PIM-SM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", B. Fenner, M. Handley, H. Holbrook,and I. Kouvelas, RFC 4601, 2006 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, RFC 2119, March 1997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Dolganow Expires April 16, 2015 [Page 7] Internet-Draft draft-dolganow-l3vpn-mvpn-expl-track-00 October 2014 Authors' Addresses Andrew Dolganow Alcatel-Lucent 600 March Rd. Ottawa, ON, Canada Email: andrew.dolganow@alcatel-lucent.com Jayant Kotalwar Alcatel-Lucent 701 East Middlefield Rd Mountain View, CA 94043, USA Email: jayant.kotalwar@alcatel-lucent.com Dolganow Expires April 16, 2015 [Page 8]