Internet DRAFT - draft-dolganow-l3vpn-mvpn-expl-track

draft-dolganow-l3vpn-mvpn-expl-track



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

   <Add any 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]