L3VPN Working Group                                    IJsbrand Wijnands
Internet Draft Engineering Task Force (IETF)                      IJ. Wijnands
Request for Comments: 7441                           Cisco Systems, Inc.
Intended Status: Proposed Standard
Updates: 6514                                              Eric C.                                                   E. Rosen
Expires: May 25, 2015
Category: Standards Track                         Juniper Networks, Inc.

                                                              Uwe
ISSN: 2070-1721                                                U. Joorde
                                                        Deutsche Telekom

                                                       November 25, 2014
                                                            January 2015

  Encoding mLDP FECs Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs)
                  in the NLRI of BGP MCAST-VPN Routes

                 draft-ietf-l3vpn-mvpn-mldp-nlri-10.txt

                                Abstract

   Many service providers offer "BGP/MPLS IP VPN" service to their
   customers.  Existing IETF standards specify the procedures and
   protocols that a service provider uses in order to offer this service
   to customers who have IP unicast and IP multicast traffic in their
   VPNs.  It is also desirable to be able to support customers who have
   MPLS multicast traffic in their VPNs.  This document specifies the
   procedures and protocol extensions that are needed to support
   customers who use the Multicast Extensions to Label Distribution
   Protocol Multipoint LDP (mLDP) as the control protocol
   for their MPLS multicast traffic.  Existing standards do provide some
   support for customers who use mLDP, but only under a restrictive set
   of circumstances.  This document generalizes the existing support to
   include all cases where the customer uses mLDP, without any
   restrictions.  This document updates RFC 6514.

Status of this This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product 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
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other documents at any
   time.  It the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work available in progress."

   The list Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html.
   http://www.rfc-editor.org/info/rfc7441.

Copyright and License Notice

   Copyright (c) 2014 2015 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.

Table of Contents

 1

   1. Introduction  ..........................................   3
 2 ....................................................3
   2. Why This Document is Needed  ...........................   4
 3 .....................................4
   3. Encoding an mLDP FEC in the MCAST-VPN NLRI  ............   5
 4 ......................5
   4. Wildcards  .............................................   7
 5 .......................................................7
   5. IANA Considerations  ...................................   7
 6 .............................................7
   6. Security Considerations  ...............................  10
 7          Acknowledgments  .......................................  10
 8          Authors' Addresses  ....................................  10
 9 .........................................9
   7. References ......................................................9
      7.1. Normative References  ..................................  11
10 .......................................9
      7.2. Informative References  ................................  11 .....................................9
   Acknowledgments ...................................................11
   Authors' Addresses ................................................11

1.  Introduction

   Many service providers (SPs) offer "BGP/MPLS BGP/MPLS IP VPN" VPN service to their
   customers.  When a customer has IP multicast traffic in its VPN, the
   service provider needs to signal the customer multicast states across
   the backbone.  A customer with IP multicast traffic is typically
   using PIM ("Protocol (Protocol Independent Multicast") Multicast) [PIM] and/or IGMP
   ("Internet
   (Internet Group Management Protocol") Protocol) [IGMP] as the multicast control
   protocol in its VPN.  The IP multicast states of these protocols are
   commonly denoted as "(S,G)" and/or "(*,G)" states, where "S" is a
   multicast source address and "G" is a multicast group address.
   [MVPN-BGP] specifies the way an SP may use BGP to signal a customer's
   IP multicast states across the SP backbone.  This is done by using "Multiprotocol BGP"
   Multiprotocol BGP Updates whose "Subsequent Subsequent Address Family
   Identifier" Identifier
   (SAFI) value is "MCAST-VPN" MCAST-VPN (5).  The NLRI ("Network (Network Layer Reachability Information")
   Information) field of these Updates includes a customer Multicast
   Source field and a customer Multicast Group field, thus enabling the
   customer's (S,G) or (*,G) states to be encoded in the NLRI.

   It is also desirable for the BGP/MPLS IP VPN service to be able to
   support customers who are using MPLS multicast, either instead of, of or
   in addition to, to IP multicast.  This document specifies the procedures
   and protocol extensions needed to support customers who use mLDP
   ("Multicast Extensions to Label Distribution Protocol")
   [mLDP] to create and maintain Point-to-Multipoint (P2MP) and/or Multipoint-to-
   Multipoint
   Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs).  While
   mLDP is not the only protocol that can be used to create and maintain
   multipoint LSPs, consideration of other MPLS multicast control
   protocols is outside the scope of this document.

   When a customer is using mLDP in its VPN, the customer multicast
   states associated with mLDP are denoted by an mLDP "FEC Element"
   ("Forwarding FEC Element
   (Forwarding Equivalence Class element", Element; see [mLDP]), [mLDP]) instead of by an
   (S,G) or (*,G).  Thus  Thus, it is necessary to have a way to encode a
   customer's mLDP FEC Elements in the NLRI field of the BGP MCAST-VPN
   routes.

   While [MVPN-BGP] does specify a way of encoding an mLDP FEC Element
   in the MCAST-VPN NLRI field, the encoding specified therein makes a
   variety of restrictive assumptions about the customer's use of mLDP.
   (These assumptions are described in section Section 2 of this document.)  The
   purpose of this document is to update RFC 6514 [MVPN-BGP] so that
   customers using mLDP in their VPNs can be supported even when those
   assumptions do not hold.

   Some SPs use the MVPN procedures to provide "global table multicast"
   service (i.e., multicast service that is not in the context of a VPN)
   to customers.  Methods for doing this are specified in [GTM] and in
   [SEAMLESS-MCAST].  The procedures described in this document can be
   used along with the procedures of [GTM] or [SEAMLESS-MCAST] to
   provide global table multicast service to customers that use MPLS
   multicast in a global table context.

   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 [RFC2119].

2.  Why This Document is Is Needed

   An mLDP FEC Element consists of a FEC Type, a Root Node, and an
   Opaque Value.  mLDP uses several FEC types, and types and, in particular, uses
   the FEC type to distinguish between P2MP LSPs and MP2MP LSPs.

   Section 11.1.2 of [MVPN-BGP] ("Originating routes: Routes: mLDP as the C-
   multicast control protocol")
   Multicast Protocol") states:

      Whenever a PE ("Provider Edge" router) receives [Provider Edge router] receives, from one of its CEs ("Customer Edge" routers)
      [Customer Edge routers], a P2MP Label Map <X, Y, L> over interface
      I, where X is the Root Node Address, Y is the Opaque Value, and L
      is an MPLS label ... the PE constructs a Source Tree Join C-multicast C-
      multicast route whose MCAST-VPN NLRI contains X as the Multicast
      Source field, and Y as the Multicast Group field.

   In other words, the Root Node of the mLDP FEC Element appears in the
   Multicast Source Field, field, and the Opaque Value of the mLDP FEC Element
   appears in the Multicast Group field.

   This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be
   used if all of the following conditions hold:

   1.  A customer using mLDP is not also using PIM/IGMP.

       The encoding in [MVPN-BGP] does not specify any way in which one
       can determine, upon receiving a BGP Update, whether the Multicast
       Group field contains an IP address or whether it contains an mLDP
       FEC Element Opaque Value.  Therefore  Therefore, it might not uniquely
       identify a customer multicast state if the customer is using both
       PIM/IGMP and mLDP in its VPN.

   2.  A customer using mLDP is using only the mLDP P2MP FEC Element, Element and
       is not using the mLDP MP2MP FEC Element.

       The encoding in [MVPN-BGP] does not specify any way to encode the
       type of the mLDP FEC Element; it just assumes it to be a P2MP FEC
       Element.

   3.  A customer using mLDP is using only an mLDP Opaque Value type for
       which the Opaque Value is exactly 32 bits or 128 bits long.

       The use of Multicast Group fields that have other lengths is
       declared by [MVPN-BGP] to be "out of scope" of that document
       (see, e.g., section Section 4.3 of that document).

       This condition holds if the customer uses only the mLDP "Generic
       LSP Identifier" Opaque Value type (defined in [mLDP]).  However,
       mLDP supports many other Opaque Value types whose length is not
       restricted to be 32 or 128 bits.

   The purpose of this document is to update [MVPN-BGP] so that
   customers using mLDP can be supported, even when these conditions do
   not hold.

3.  Encoding an mLDP FEC in the MCAST-VPN NLRI

   When mLDP is used as the customer multicast control protocol, [MVPN-
   BGP]
   [MVPN-BGP] presupposes that an mLDP FEC element Element will be encoded in
   the NLRI of the following three MCAST-VPN route types:

   -  C-multicast Source Tree Join, Join route,

   -  S-PMSI A-D route, and

   -  Leaf A-D route.

   The other four MCAST-VPN route types defined in [MVPN-BGP] do not
   ever need to carry mLDP FEC Elements.  The C-multicast Shared Tree
   Join route and the Source Active A-D route are used to communicate
   state about unidirectional shared trees; since mLDP does not have
   unidirectional shared trees, these routes are not used to signal mLDP
   states.  The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D
   route do not identify specific customer multicast states, states and hence do
   not carry any information that is specific to the customer's
   multicast control protocol.

   This document defines three new route types:

   -  C-Multicast Source Tree Join route for C-multicast mLDP mLDP,

   -  S-PMSI A-D route for C-multicast mLDP mLDP, and

   -  Leaf A-D route for C-multicast mLDP.

   The term "C-multicast mLDP" in the names of these route types is
   intended to indicate that the NLRI of these routes contains mLDP FEC
   elements.
   Elements.

   Each of these route types corresponds to a route type defined in
   [MVPN-BGP].  IANA has been requested to allocate codepoints for these
   three route types such that (a) the high order high-order two bits have the
   value 0x01, and (b) the low order low-order six bits have the same value as the
   codepoints for the corresponding route types from [MVPN-BGP].

   In general, the procedures defined in other MVPN specifications for
   the C-Multicast Source Tree Join route, the S-PMSI A-D route, and the
   Leaf A-D route also apply as well to the C-Multicast Source Tree Join route
   for C-multicast mLDP, the S-PMSI A-D route for C-multicast mLDP, and
   the Leaf A-D route for C-multicast mLDP, respectively.  However, the
   NLRI of these three new route types is constructed differently than
   the NLRI of the corresponding routes from [MVPN-
   BGP]: [MVPN-BGP]: the "Multicast
   Source Length", "Multicast Source", "Multicast Group Length", and
   "Multicast Group" fields are omitted, and in their place is a single
   mLDP FEC Element, as defined in [mLDP].  (See
   section Section 2.2 of [mLDP]
   for a diagram of the mLDP FEC element.) Element.)

   As a result, the NLRI of an S-PMSI A-D route for C-multicast mLDP
   will consist of a Route Distinguisher, followed by the mLDP FEC,
   followed by the "Originating Router's IP Address Field". Address" field.

   The NLRI of a C-multicast Source Tree Join route for C-multicast mLDP
   will consist of a Route Distinguisher, followed by the Source AS,
   followed by the mLDP FEC.

   In a Leaf A-D route for C-multicast mLDP that has been derived from
   an S-PMSI A-D route for C-multicast mLDP, the "route key" "Route Key" field
   remains the NLRI of the S-PMSI A-D route from which it was derived.

   In a Leaf A-D route for C-multicast mLDP that has not been derived
   from an S-PMSI A-D, the "route key" "Route Key" field is as specified in
   [SEAMLESS-MCAST], except that the "Multicast Source Length",
   "Multicast Source", "Multicast Group Length", and "Multicast Group"
   fields are omitted, and in their place is a single mLDP FEC Element.
   Thus
   Thus, the route key Route Key field consists of a Route Distinguisher, an MLDP mLDP
   FEC element, Element, and the IP address of the Ingress PE router.

   Please note that [BGP-ERR] section [BGP-ERR], Section 5.4 ("Typed NLRI") is applicable
   if the Route Type field of the NLRI of a received MCAST-VPN route
   contains an unrecognized value.  Any such routes will be discarded.

   An mLDP FEC element Element contains an "address family" field whose value is
   from IANA's "Address Family Numbers" registry.  The value of the
   "address family" field identifies the address family of the "root
   node address" "Root
   Node Address" field of the FEC element. Element.  When an mLDP FEC element Element is
   encoded into the NLRI of an a BGP update Update whose SAFI is MCAST-VPN, the
   address family of the root node address Root Node Address (as indicated in the FEC
   element)
   Element) MUST "correspond to" correspond to the address family that is identified in
   the "Address Family Identifier" (AFI) field of that BGP update. Update.
   These two "address family" fields are considered to "correspond" correspond to
   each other under the following conditions:

   -  they contain identical values, or

   -  the BGP update's Update's AFI field identifies IPv4 as the address family,
      and the mLDP FEC element Element identifies "Multi-Topology IPv4" as the
      address family of the root node, or

   -  the BGP update's Update's AFI field identifies IPv6 as the address family,
      and the mLDP FEC element Element identifies "Multi-Topology IPv6" as the
      address family of the root node.

   For more information about the "multi-topology" address families, see
   [LDP-MT] and [mLDP-MT].

4.  Wildcards

   [MVPN-WILDCARDS] specifies encodings and procedures that allow
   "wildcards" to be specified in the NLRI of S-PMSI A-D routes.  A set
   of rules are given that specify when a customer multicast flow
   "matches" a given S-PMSI A-D route whose NLRI contains wildcards.
   However, the use of these wildcards is defined only for the case
   where the customer is using PIM as its multicast control protocol.
   The use of wildcards when the customer is using mLDP as its multicast
   control protocol is outside the scope of this document.

5.  IANA Considerations

   [MVPN-BGP] does not create a registry for the allocation of new
   MCAST-VPN Route Type values.  In retrospect, it seems that it should
   have done so.  IANA is requested to create has created a new registry called "BGP MCAST-VPN
   Route Types", referencing which references this document and [MVPN-BGP].  The
   registry should be has been created under the "top-level" top-level registry: "Border
   Gateway Protocol (BGP) Parameters
   http://www.iana.org/assignments/bgp-parameters/bgp-parameters". Parameters"
   <http://www.iana.org/assignments/bgp-parameters>.  The allocation
   policy should be is "Standards Action".  Values may be assigned from one of
   several ranges:

   -  Range 0x01-0x3f: Generic/PIM Range.  Values are assigned from this
      range when the NLRI format associated with the route type
      presupposes that PIM or IGMP is the C-multicast control protocol, protocol
      or when the NLRI format associated with the route type is
      independent of the C-multicast control protocol.

   -  Range 0x43-0x7f: mLDP Range.  Values are assigned from this range
      when the NLRI format associated with the route type presupposes
      that mLDP is the C-multicast control protocol.

   -  Range 0x80-0xff: This range is reserved; values should not be
      assigned from this range.

   In general, whenever an assignment is requested from this registry,
   two codepoints should be requested at the same time: one from the
   Generic/PIM range and one from the mLDP range.  The two codepoints
   should have the same low-order 6 bits.  If one of the two codepoints
   is not actually needed, it should be registered anyway, anyway and marked as
   "reserved".

   When the BGP
   "Reserved".

   The "BGP MCAST-VPN Route Types registry is created, it should
   contain Types" contains the following initial
   assignments:

   Value       Meaning                              Reference
   ---------   ----------------------------------   -------------------
   0x00        Reserved                             This RFC

   0x01        Intra-AS I-PMSI A-D route            This RFC, RFC6514 [RFC6514]

   0x02        Inter-AS I-PMSI A-D route            This RFC, RFC6514 [RFC6514]

   0x03        S-PMSI A-D route                     This RFC, RFC6514 [RFC6514]

   0x04        Leaf A-D route                       This RFC, RFC6514 [RFC6514]

   0x05        Source Active A-D route              This RFC, RFC6514 [RFC6514]

   0x06        Shared Tree Join route               This RFC, RFC6514 [RFC6514]

   0x07        Source Tree Join route               This RFC, RFC6514 [RFC6514]

   0x08-0x3f   Unassigned (Generic/PIM range)       This RFC

   0x40-0x42   Reserved                             This RFC

   0x43        S-PMSI A-D route for
               C-multicast mLDP                     This RFC
   0x44        Leaf A-D route for C-multicast mLDP  This RFC

   0x45-0x46   Reserved                             This RFC

   0x47        Source Tree Join route for
               C-multicast mLDP                     This RFC

   0x48-0x7f   Unassigned (mLDP range)              This RFC

   0x80-0xff   Reserved                             This RFC

6.  Security Considerations

   This document specifies a method of encoding an mLDP FEC element Element in
   the NLRI of some of the BGP Update messages that are specified in
   [MVPN-BGP].  The security considerations of [mLDP] and of [MVPN-BGP]
   are applicable, but no new security considerations are raised.

9.

7.  References

7.1.  Normative References

   [mLDP]     Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-to-
   Multipoint Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths",
   Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 2011,
              <http://www.rfc-editor.org/info/rfc6388>.

   [MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012 2012,
              <http://www.rfc-editor.org/info/rfc6514>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement
   Levels.", Bradner, Levels", BCP 14, RFC 2119, March 1997

10. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [BGP-ERR]  Chen, E., Ed, Scudder, J., Mohapatra, P., and K. Patel,
              "Revised Error Handling for BGP UPDATE Messages", Chen,
   Scudder, Mohapatra, Patel, draft-ietf-idr-error-handling-16.txt,
   November 2014 Work in
              Progress, draft-ietf-idr-error-handling-18, December 2015.

   [GTM] "Global Table Multicast with BGP-MVPN Procedures",      Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
              Pacella, D., and J. Schiller, draft-ietf-l3vpn-
   mvpn-global-table-mcast-00.txt, June 2014 "Global Table Multicast with
              BGP-MVPN Procedures", Work in Progress, draft-ietf-bess-
              mvpn-global-table-mcast-00, November 2014.

   [IGMP]     Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", Cain,
   Deering, Kouvelas, Fenner, Thyagarajan, RFC 3376, October 2002 2002,
              <http://www.rfc-editor.org/info/rfc3376>.

   [LDP-MT]   Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
              King, "LDP Extensions for Multi-Topology", Zhao, et. al., RFC 7307, July 2014
              2014, <http://www.rfc-editor.org/info/rfc7307>.

   [mLDP-MT]  Wijnands, IJ. and K. Raza, "mLDP Extensions for Multi
              Topology Routing", Wijnands,
   Raza, draft-iwijnand-mpls-mldp-multi-topology-03.txt, Work in Progress, draft-iwijnand-mpls-
              mldp-multi-topology-03, June 2013

   [MVPN-WILDCARDS], 2013.

   [MVPN-WILDCARDS]
              Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
              Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
   Rosen, Rekhter, Hendrickx, Qiu,
              RFC 6625, May 2012 2012,
              <http://www.rfc-editor.org/info/rfc6625>.

   [PIM]      Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM)",
   Fenner, Handley, Holbrook, Kouvelas, (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006, RFC 4601
              <http://www.rfc-editor.org/info/rfc4601>.

   [SEAMLESS-MCAST] "Inter-Area P2MP Segmented LSPs",
              Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I.,
              Leymann, N., and S. Saad, "Inter-Area P2MP Segmented
              LSPs", Work in Progress, draft-ietf-mpls-seamless-
   mcast-14.txt, July 2014

7.
              mcast-14, June 2014.

Acknowledgments

   The authors wish to thank Pradosh Mohapatra and Saquib Najam for
   their ideas and comments.  We also thank Yakov Rekhter and Martin
   Vigoureux for their comments.

8.

Authors' Addresses

   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a Diegem 1831
   BE
   E-mail:
   Belgium
   EMail: ice@cisco.com

   Eric C. Rosen
   Juniper Networks, Inc.
   10 Technology Park Drive
   Westford, Massachusetts MA  01886
   US
   E-mail:
   United States
   EMail: erosen@juniper.net

   Uwe Joorde
   Deutsche Telekom
   Hammer Str. 216-226
   D-48153 Muenster, Muenster
   Germany
   E-mail:
   EMail: Uwe.Joorde@telekom.de