Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
RFC 7740
|
| Document |
Type |
|
RFC - Proposed Standard
(January 2016; No errata)
|
|
Last updated |
|
2016-01-22
|
|
Replaces |
|
draft-ietf-l3vpn-mvpn-bidir-ingress-replication
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Thomas Morin
|
|
Shepherd write-up |
|
Show
(last changed 2015-08-04)
|
| IESG |
IESG state |
|
RFC 7740 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Alvaro Retana
|
|
Send notices to |
|
aretana@cisco.com
|
| IANA |
IANA review state |
|
Version Changed - Review Needed
|
|
IANA action state |
|
No IC
|
Internet Engineering Task Force (IETF) Z. Zhang
Request for Comments: 7740 Y. Rekhter
Category: Standards Track Juniper Networks
ISSN: 2070-1721 A. Dolganow
Alcatel-Lucent
January 2016
Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP)
Provider Tunnels with Ingress Replication
Abstract
RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to
support bidirectional customer multicast flows using a partial mesh
of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies
how a partial mesh of MP2MP tunnels can be simulated using Ingress
Replication. This solution enables a service provider to use Ingress
Replication to offer transparent bidirectional multicast service to
its VPN customers.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7740.
Zhang, et al. Standards Track [Page 1]
RFC 7740 C-BIDIR Support with IR January 2016
Copyright Notice
Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Control State . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Forwarding State . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normative References . . . . . . . . . . . . . . . . . . 7
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Zhang, et al. Standards Track [Page 2]
RFC 7740 C-BIDIR Support with IR January 2016
1. Introduction
Section 11.2 of RFC 6513 ("Partitioned Sets of PEs") describes two
methods of carrying Bidirectional PIM (BIDIR-PIM) [RFC5015] C-flow
traffic over a provider core without using the core as the Rendezvous
Point Link (RPL) or requiring Designated Forwarder election.
With these two methods, all Provider Edges (PEs) of a particular VPN
are separated into partitions, with each partition being all the PEs
that elect the same PE as the Upstream PE with respect to the C-RPA
(the Rendezvous Point Address in the customer's address space). A PE
must discard bidirectional C-flow traffic from PEs that are not in
the same partition as the PE itself.
In particular, Section 11.2.3 of RFC 6513 ("Partial Mesh of MP2MP
P-Tunnels") guarantees the above discard behavior without using an
extra PE Distinguisher Label by having all PEs in the same partition
join a single MP2MP tunnel dedicated to that partition and use it to
transmit traffic. All traffic arriving on the tunnel will be from
PEs in the same partition, so it will be always accepted.
RFC 6514 specifies BGP encodings and procedures used to implement
Multicast VPN (MVPN) as specified in RFC 6513, while the details
Show full document text