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]
