draft-ietf-bess-mvpn-bidir-ingress-replication-00.txt   draft-ietf-bess-mvpn-bidir-ingress-replication-01.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: July 18, 2015 Alcatel-Lucent Expires: February 4, 2016 Alcatel-Lucent
January 14, 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-00.txt draft-ietf-bess-mvpn-bidir-ingress-replication-01.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 describes 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
service to its VPN customers. [RFC 5015] service to its VPN customers. These specifications update
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/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 18, 2015. This Internet-Draft will expire on February 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 34 skipping to change at page 3, line 34
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 [draft-ietf-l3vpn-mvpn-bidir-08].
[draft-ietf-l3vpn-mvpn-bidir-08] assumes that an MP2MP P-tunnel is [draft-ietf-l3vpn-mvpn-bidir-08] assumes that an MP2MP P-tunnel is
realized either via PIM-Bidir, or via MP2MP mLDP. Each of them would realized either via PIM-Bidir, or via MP2MP mLDP. Each of them would
require signaling and state not just on PEs, but on the P routers as require signaling and state not just on PEs, but on the P routers as
well. This document describes how the MP2MP tunnel can be simulated well. This document describes how the MP2MP tunnel can be simulated
with a mesh of P2MP tunnels, each of which is instantiated by Ingress with a mesh of P2MP tunnels, each of which is instantiated by Ingress
Replication. This does not require each PE on the MP2MP tunnel to Replication [I-D.ietf-bess-ir]. This does not require each PE on the
send an S-PMSI A-D route for the P2MP tunnel that the PE is the root MP2MP tunnel to send an S-PMSI A-D route for the P2MP tunnel that the
for, nor does it require each PE to send a Leaf A-D route to the root PE is the root for, nor does it require each PE to send a Leaf A-D
of each P2MP tunnel in the mesh. route to 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]. [draft-ietf-l3vpn-mvpn-bidir-08].
2. Requirements Language 2. Requirements Language
skipping to change at page 5, line 23 skipping to change at page 5, line 23
If a PE, say PEx, is connected to a site of a given VPN, and PEx's If a PE, say PEx, is connected to a site of a given VPN, and PEx's
next hop interface to some C-RPA is a VRF interface, then PEx MUST next hop interface to some C-RPA is a VRF interface, then PEx MUST
advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether
it has any local Bidir-PIM join states corresponding to the C-RPA it has any local Bidir-PIM join states corresponding to the C-RPA
learned from its CEs. It MAY also advertise one or more (C-*,C-G- learned from its CEs. It MAY also advertise one or more (C-*,C-G-
BIDIR) S-PMSI A-D route, just like how any other S-PMSI A-D routes BIDIR) S-PMSI A-D route, just like how any other S-PMSI A-D routes
are triggered. Here the C-G-BIDIR refers to a C-G where G is a are triggered. Here the C-G-BIDIR refers to a C-G where G is a
Bidir-PIM group, and the corresponding C-RPA is in the site that the Bidir-PIM group, and the corresponding C-RPA is in the site that the
PEx connects to. For example, the (C-*,C-G-BIDIR) S-PMSI A-D routes PEx connects to. For example, the (C-*,C-G-BIDIR) S-PMSI A-D routes
could be triggered when the (C-*, C-G-BIDIR) traffic rate goes above could be triggered when the (C-*, C-G-BIDIR) traffic rate goes above
a threshold, and fan-out could also be taken into account. Note that a threshold (this may require measuring the traffic in both
this requires measuring the traffic in both directions, due to the directions, due to the nature of Bidir-PIM), and fan-out could also
nature of Bidir-PIM. be taken into account.
The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with
tunnel type set to Ingress Replication, with Leaf Information tunnel type set to Ingress Replication, with Leaf Information
Required flag set, with a downstream allocated MPLS label that other Required flag set, with a downstream allocated MPLS label that other
PEs in the same partition MUST use when sending relevant C-bidir PEs in the same partition MUST use when sending relevant C-bidir
flows to this PE, and with the Tunnel Identifier field in the PTA set flows to this PE, and with the Tunnel Identifier field in the PTA set
to a routable address of the originator. The label may be shared to a routable address of the originator. The label may be shared
with other P-tunnels, subject to the anti-ambiguity rules for with other P-tunnels, subject to the anti-ambiguity rules for
extranet. For example, the (C-*,C-*-BIDIR) and (C-*,C-G-BIDIR) extranet [I-D.ietf-bess-mvpn-extranet]. For example, the (C-*,C-*-
S-PMSI A-D routes originated by a given PE can optionally share a BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE
label. can optionally share a label.
If some other PE, PEy, receives and imports into one of its VRFs any If some other PE, PEy, receives and imports into one of its VRFs any
(C-*, C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, (C-*, C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel,
and the VRF has any local Bidir-PIM join state that PEy has received and the VRF has any local Bidir-PIM join state that PEy has received
from its CEs, and if PEy chooses PEx as its Upstream PE wrt the C-RPA from its CEs, and if PEy chooses PEx as its Upstream PE wrt the C-RPA
for those states, PEy MUST advertise a Leaf A-D route in response. for those states, PEy MUST advertise a Leaf A-D route in response.
Or, if PEy has received and imported into one of its VRFs a (C-*,C-*- Or, if PEy has received and imported into one of its VRFs a (C-*,C-*-
BIDIR) S-PMSI A-D route from PEx before, then upon receiving in the BIDIR) S-PMSI A-D route from PEx before, then upon receiving in the
VRF any local Bidir-PIM join state from its CEs with PEx being the VRF any local Bidir-PIM join state from its CEs with PEx being the
Upstream PE for those states' C-RPA, PEy MUST advertise a Leaf A-D Upstream PE for those states' C-RPA, PEy MUST advertise a Leaf A-D
route. route.
The encoding of the Leaf A-D route is as specified in RFC 6514, The encoding of the Leaf A-D route is as specified in RFC 6514,
except that the Route Targets are set to the same value as in the except that the Route Targets are set to the same value as in the
corresponding S-PMSI A-D route so that the Leaf A-D route will be corresponding S-PMSI A-D route so that the Leaf A-D route will be
imported by all VRFs that import the corresponding S-PMSI A-D route. imported by all VRFs that import the corresponding S-PMSI A-D route.
This is irrespective of whether from a receiving PE, PEz's This is irrespective of whether the originator of the S-PMSI A-D
perspective PEx (originator of the S-PMSI A-D route) is the Upstream route is the Upstream PE or not from a receiving PE's perspective.
PE or not. The label in the PTA of the Leaf A-D route originated by The label in the PTA of the Leaf A-D route originated by PEy MUST be
PEy MUST be allocated specifically for PEx, so that when traffic allocated specifically for PEx, so that when traffic arrives with
arrives with that label, the traffic can associated with the that label, the traffic can associated with the partition
partition (represented by the PEx). The label may be shared with (represented by the PEx). The label may be shared with other
other P-tunnels, subject to the anti-ambiguity rules for extranet. P-tunnels, subject to the anti-ambiguity rules for extranet
For example, the (C-*,C-*-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D [I-D.ietf-bess-mvpn-extranet]. For example, the (C-*,C-*-BIDIR) and
routes originated by a given PE can optionally share a label. (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can
optionally share a label.
Note that RFC 6514 requires a PE/ASBR take no action with regard to a Note that RFC 6514 requires a PE/ASBR take no action with regard to a
Leaf A-D route unless that Leaf A-D route carries an IP Address Leaf A-D route unless that Leaf A-D route carries an IP Address
Specific RT identifying the PE/ASBR. This document removes that Specific RT identifying the PE/ASBR. This document removes that
requirement when the route key of a Leaf A-D route identifies a requirement when the route key of a Leaf A-D route identifies a
(C-*,C-*-BIDIR) or a (C-*,C-G-BIDIR) S-PMSI. (C-*,C-*-BIDIR) or a (C-*,C-G-BIDIR) S-PMSI.
To speed up convergence (so that PEy starts receiving traffic from To speed up convergence (so that PEy starts receiving traffic from
its new Upstream PE immediately instead of waiting until the new Leaf its new Upstream PE immediately instead of waiting until the new Leaf
A-D route corresponding to the new Upstream PE is received by sending A-D route corresponding to the new Upstream PE is received by sending
skipping to change at page 6, line 44 skipping to change at page 6, line 45
that it has received from its CEs in the VRF, PEy MUST advertise a that it has received from its CEs in the VRF, PEy MUST advertise a
Leaf A-D route in response. Or, if PEy has received and imported Leaf A-D route in response. Or, if PEy has received and imported
into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route before, then into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route before, then
upon receiving its local (C-*,C-G-BIDIR) join state from its CEs in upon receiving its local (C-*,C-G-BIDIR) join state from its CEs in
the VRF, it MUST advertise a Leaf A-D route. the VRF, it MUST advertise a Leaf A-D route.
The encoding of the Leaf A-D route is as specified in RFC 6514, The encoding of the Leaf A-D route is as specified in RFC 6514,
except that the Route Targets are set to the same as in the except that the Route Targets are set to the same as in the
corresponding S-PMSI A-D route so that the Leaf A-D route will be corresponding S-PMSI A-D route so that the Leaf A-D route will be
imported by all VRFs that import the corresponding S-PMSI A-D route. imported by all VRFs that import the corresponding S-PMSI A-D route.
This is irrespective of whether from the receiving PE, PEz's This is irrespective of whether the originator of the S-PMSI A-D
perspective PEx (originator of the S-PMSI A-D route) is the Upstream route is the Upstream PE or not from a receiving PE's perspective.
PE or not. The label in the PTA of the Leaf A-D route originated by The label in the PTA of the Leaf A-D route originated by PEy MUST be
PEy MUST be allocated specifically for PEx, so that when traffic allocated specifically for PEx, so that when traffic arrives with
arrives with that label, the traffic can associated with the that label, the traffic can associated with the partition
partition (represented by the PEx). The label may be shared with (represented by the PEx). The label may be shared with other
other P-tunnels, subject to the anti-ambiguity rules for extranet. P-tunnels, subject to the anti-ambiguity rules for extranet
For example, the (C-*,C-*-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D [I-D.ietf-bess-mvpn-extranet]. For example, the (C-*,C-*-BIDIR) and
routes originated by a given PE can optionally share a label. (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a given PE can
optionally share a label.
Whenever the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is Whenever the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is
withdrawn, or if PEy no longer chooses the originator PEx as its withdrawn, or if PEy no longer chooses the originator PEx as its
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
skipping to change at page 12, line 10 skipping to change at page 12, line 10
6. Acknowledgements 6. Acknowledgements
We would like to thank Eric Rosen for his comments, and suggestions We would like to thank Eric Rosen for his comments, and suggestions
of some texts used in the document. of some texts used in the document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. BGP IP VPNs", RFC 6513, DOI 10.17487/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, February 2012. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
<http://www.rfc-editor.org/info/rfc5015>.
[I-D.ietf-l3vpn-mvpn-bidir] [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
Rosen, E., Wijnands, I., Cai, Y., and A. Boers, "MVPN: "Multicast Virtual Private Network (MVPN): Using
Using Bidirectional P-Tunnels", Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
draft-ietf-l3vpn-mvpn-bidir-08 (work in progress), July 2015, <http://www.rfc-editor.org/info/rfc7582>.
June 2014.
7.2. Informative References 7.2. Informative References
[I-D.rosen-l3vpn-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",
draft-rosen-l3vpn-ir-01 (work in progress), April 2014. draft-ietf-bess-ir-01 (work in progress), May 2015.
[I-D.ietf-bess-mvpn-extranet]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
draft-ietf-bess-mvpn-extranet-02 (work in progress),
May 2015.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
10 Technology Park Dr. 10 Technology Park Dr.
Westford, MA 01886 Westford, MA 01886
US US
Email: zzhang@juniper.net Email: zzhang@juniper.net
 End of changes. 17 change blocks. 
46 lines changed or deleted 59 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/