draft-ietf-bess-mvpn-bidir-ingress-replication-01.txt   draft-ietf-bess-mvpn-bidir-ingress-replication-02.txt 
Network Working Group Z. Zhang Network Working Group Z. Zhang
Internet-Draft Y. Rekhter Internet-Draft Y. Rekhter
Updates: 6514 (if approved) Juniper Networks Updates: 6514 (if approved) Juniper Networks
Intended status: Standards Track A. Dolganow Intended status: Standards Track A. Dolganow
Expires: February 4, 2016 Alcatel-Lucent Expires: February 4, 2016 Alcatel-Lucent
August 3, 2015 August 3, 2015
Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication
draft-ietf-bess-mvpn-bidir-ingress-replication-01.txt draft-ietf-bess-mvpn-bidir-ingress-replication-02.txt
Abstract Abstract
RFC 6513 described a method to support bidirectional C-flow using RFC 6513 described a method to support bidirectional C-flow using
"Partial Mesh of MP2MP P-Tunnels". This document specifiess how "Partial Mesh of MP2MP P-Tunnels". This document specifiess how
partial mesh of MP2MP P-Tunnels can be simulated with Ingress partial mesh of MP2MP P-Tunnels can be simulated with Ingress
Replication, instead of a real MP2MP tunnel. This enables a Service Replication, instead of a real MP2MP tunnel. This enables a Service
Provider to use Ingress Replication to offer transparent BIDIR-PIM Provider to use Ingress Replication to offer transparent Bidir-PIM
[RFC 5015] service to its VPN customers. These specifications update service to its VPN customers. These specifications update RFC 6514.
RFC6514.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
In particular, Section 11.2.3 of RFC 6513, "Partial Mesh of MP2MP In particular, Section 11.2.3 of RFC 6513, "Partial Mesh of MP2MP
P-Tunnels", guarantees the above discard behavior without using an P-Tunnels", guarantees the above discard behavior without using an
extra PE Distinguisher label by having all PEs in the same partition 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 join a single MP2MP tunnel dedicated to that partition and use it to
transmit traffic. All traffic arriving on the tunnel will be from transmit traffic. All traffic arriving on the tunnel will be from
PEs in the same partition, so it will be always accepted. PEs in the same partition, so it will be always accepted.
RFC 6514 specifies BGP encodings and procedures used to implement RFC 6514 specifies BGP encodings and procedures used to implement
MVPN as specified in RFC 6513, while the details related to MP2MP MVPN as specified in RFC 6513, while the details related to MP2MP
tunnels are specified in [draft-ietf-l3vpn-mvpn-bidir-08]. tunnels are specified in [RFC7582].
[draft-ietf-l3vpn-mvpn-bidir-08] assumes that an MP2MP P-tunnel is RFC 7582 assumes that an MP2MP P-tunnel is realized either via Bidir-
realized either via PIM-Bidir, or via MP2MP mLDP. Each of them would PIM, or via MP2MP mLDP. Each of them would require signaling and
require signaling and state not just on PEs, but on the P routers as state not just on PEs, but on the P routers as well. This document
well. This document describes how the MP2MP tunnel can be simulated describes how the MP2MP tunnel can be simulated with a mesh of P2MP
with a mesh of P2MP tunnels, each of which is instantiated by Ingress tunnels, each of which is instantiated by Ingress Replication
Replication [I-D.ietf-bess-ir]. This does not require each PE on the [I-D.ietf-bess-ir]. This does not require each PE on the MP2MP
MP2MP tunnel to send an S-PMSI A-D route for the P2MP tunnel that the tunnel to send an S-PMSI A-D route for the P2MP tunnel that the PE is
PE is the root for, nor does it require each PE to send a Leaf A-D the root for, nor does it require each PE to send a Leaf A-D route to
route to the root of each P2MP tunnel in the mesh. the root of each P2MP tunnel in the mesh.
With the use of Ingress Replication,this scheme has both the With the use of Ingress Replication,this scheme has both the
advantages and the disadvantages of Ingress Replication in general. advantages and the disadvantages of Ingress Replication in general.
1.1. Terminology 1.1. Terminology
This document uses terminology from [RFC6513], [RFC6514], and This document uses terminology from [RFC6513], [RFC6514], and
[draft-ietf-l3vpn-mvpn-bidir-08]. [RFC7582].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
In following sections, the originator of an S-PMSI A-D route or Leaf In following sections, the originator of an S-PMSI A-D route or Leaf
skipping to change at page 7, line 19 skipping to change at page 7, line 19
Upstream PE wrt C-RPA and PEy only advertises Leaf A-D routes in Upstream PE wrt C-RPA and PEy only advertises Leaf A-D routes in
response to its Upstream PE's S-PMSI A-D route, or if relevant local response to its Upstream PE's S-PMSI A-D route, or if relevant local
join state is pruned, PEy MUST withdraw the corresponding Leaf A-D join state is pruned, PEy MUST withdraw the corresponding Leaf A-D
route. route.
3.2. Forwarding State 3.2. Forwarding State
The following specification regarding forwarding state matches the The following specification regarding forwarding state matches the
"When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is "When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is
a 'Match for Reception'" rules for "Flat Partitioning" method in a 'Match for Reception'" rules for "Flat Partitioning" method in
[draft-ietf-l3vpn-mvpn-bidir-08], except that the rules about [RFC7582], except that the rules about (C-*,C-*) are not applicable,
(C-*,C-*) are not applicable, because this document requires that because this document requires that (C-*,C-*-BIDIR) S-PMSI A-D routes
(C-*,C-*-BIDIR) S-PMSI A-D routes are always originated for a VPN are always originated for a VPN that supports C-Bidir flows.
that supports C-Bidir flows.
For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and
imports into one of its VRFs from its Upstream PE wrt the C-RPA, or imports into one of its VRFs from its Upstream PE wrt the C-RPA, or
if PEy itself advertises the S-PMSI A-D route in the VRF, PEy if PEy itself advertises the S-PMSI A-D route in the VRF, PEy
maintains a (C-*,C-G-BIDR) forwarding state in the VRF, with the maintains a (C-*,C-G-BIDR) forwarding state in the VRF, with the
Ingress Replication provider tunnel leaves being the originators of Ingress Replication provider tunnel leaves being the originators of
the S-PMSI A-D route and all relevant Leaf-A-D routes. The relevant the S-PMSI A-D route and all relevant Leaf-A-D routes. The relevant
Leaf A-D routes are the routes whose Route Key field contains the Leaf A-D routes are the routes whose Route Key field contains the
same information as the MCAST-VPN NLRI of the (C-*, C-G-BIDIR) S-PMSI same information as the MCAST-VPN NLRI of the (C-*, C-G-BIDIR) S-PMSI
A-D route advertised by the Upstream PE. A-D route advertised by the Upstream PE.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
February 2012, <http://www.rfc-editor.org/info/rfc6513>. February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using "Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <http://www.rfc-editor.org/info/rfc7582>. July 2015, <http://www.rfc-editor.org/info/rfc7582>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-bess-ir] [I-D.ietf-bess-ir]
Rosen, E., Subramanian, K., and J. Zhang, "Ingress Rosen, E., Subramanian, K., and J. Zhang, "Ingress
Replication Tunnels in Multicast VPN", Replication Tunnels in Multicast VPN",
 End of changes. 7 change blocks. 
24 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/