Internet DRAFT - draft-li-bess-mvpn-role-state-ad
draft-li-bess-mvpn-role-state-ad
Network Working Group Z. Li
Internet-Draft S. Zhuang
Intended status: Standards Track Huawei Technologies
Expires: April 20, 2016 October 18, 2015
Role-Based State Advertisement for Multicast in MPLS/BGP IP VPNs
draft-li-bess-mvpn-role-state-ad-00
Abstract
The document defines and uses a new BGP attribute called the "Role
Discovery attribute" to advertise the role and corresponding primary/
backup state for Multicast in MPLS/BGP IP VPNs [RFC6514]. The role-
based state advertisement can help optimization of process in MPLS/
BGP Multicast VPN.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 20, 2016.
Copyright Notice
Copyright (c) 2015 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
Li & Zhuang Expires April 20, 2016 [Page 1]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applications and Requirements . . . . . . . . . . . . . . . . 3
3.1. Easing Provision of mLDP P2MP LSP . . . . . . . . . . . . 3
3.2. Reducing Unnecessary Traffic Replication . . . . . . . . 3
3.3. Local Protection of Egress Nodes . . . . . . . . . . . . 4
3.4. Centralized Multicast Traffic Optimization . . . . . . . 4
4. Role Discovery Attribute . . . . . . . . . . . . . . . . . . 5
5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Advertisement of Role-based State for Root Nodes . . . . 6
5.2. Advertisement of Role-based State for Leaf Nodes . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[RFC6513] defines the protocols and procedures for multicast in the
BGP/MPLS IP VPN (Virtual Private Network) [RFC4364] and [RFC6514]
describes the BGP encodings and procedures for exchanging the
information elements required by Multicast in MPLS/BGP IP VPNs.
In MPLS/BGP Multicast VPN, there is close relation between the
multicast service and the tunnel which bears the multicast service.
The tunnel can be triggered to setup automatically after the auto-
discovery of the leaf PEs. This can facilitate the provision of the
tunnels for multicast. Or else, it will take much effort for the
provision work which is troublesome and error-prone. Based on the
thinking, it is desirable that more information can be advertised
along with the auto-discovery route which can optimize the provision
of MPLS/BGP Multicast VPN.
This document identifies the applications and requirements to
advertise the role and corresponding state for Multicast in MPLS/BGP
IP VPNs and defines a new BGP attribute called the "Role Discovery
Li & Zhuang Expires April 20, 2016 [Page 2]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
attribute" to achieve the object. The role-based state advertisement
can help optimization of multicast process.
2. Terminology
CE: Customer Edge
PE: Provider Edge
MVPN: Multicast VPN
3. Applications and Requirements
3.1. Easing Provision of mLDP P2MP LSP
The multipoint extensions for Label Distribution Protocol (mLDP) P2MP
LSP can be used to bear multicast service in MPLS/BGP MVPN [RFC6514].
It needs to send label mappings to the root to set up the P2MP LSP.
So it has to specify the root node address on all leaf nodes for a
specific P2MP LSP. In MPLS/BGP MVPN, if the root/leaf role
information of the PE in the MVPN can be advertised in the auto-
discovery route, the leaf PE can directly trigger mLDP to send label
mapping to the ingress PE of the MVPN without explicitly specifying
the root address. It can facilitate the provision of the MVPN when
mLDP P2MP LSP is used.
3.2. Reducing Unnecessary Traffic Replication
There exist multi-homing scenarios in MPLS/BGP MVPN. As shown in the
figure 1, CE2 multi-homes to two PEs ( PE2 and PE3). We assume PE1
is the ingress PE and PE2/PE3 are the egress PEs for a specific MPLS/
BGP MVPN. If C-join is always sent from the CE2 to the PE2 for the
MVPN, the multicast traffic sent from the PE1 to PE3 will be always
dropped since there is not (C-S, C-G) entry in the MVPN on PE3. If
PE1 can learn that the remote PE would not forward the multicast
traffic to any CE, the bandwidth can be saved in the network for PE1
can stop to setup the ingress replication tunnel or P2MP LSPs to the
remote PE or stop to replicate the unnecessary traffic to the tunnels
to the remote PE. In order to achieve the object, the primary or
backup state for the leaf PE can be advertised. As to a PE in a
specific MVPN, the primary state means that it needs to forward the
multicast traffic to the CE. The backup state means it would not
forward the multicast traffic to any CE.
Li & Zhuang Expires April 20, 2016 [Page 3]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
+---------------+
| IP/MPLS |
| Network |
+----+ +----+ +----+
| CE1|-----| |-----------| |____
+----+ | PE1| | PE2| \
| |-------- +----+ \+----+
+----+ \ | | CE2|
| \ +----+ /+----+
| \| |____/
| | PE3|
| +----+
| |
+---------------+
Figure 1 Multi-homing Network for Multicast in MPLS/BGP IP VPN
3.3. Local Protection of Egress Nodes
[I-D.ietf-mpls-rsvp-ingress-protection] and
[I-D.ietf-mpls-rsvp-egress-protection] proposes mechanisms for
locally protecting ingress and egress nodes of MPLS TE P2MP LSPs. In
the mechanism for the local protection of egress nodes, the backup
egress node needs to be designated for the primary egress node for a
P2MP LSP. The previous hop node of the primary egress node sets up a
backup Sub-LSP from itself to the backup egress node after receiving
the information about the backup egress node. The provision of the
local protection mechanism of egress nodes in P2MP LSPs can be
facilitated in MPLS/BGP MVPN by advertising the primary/backup state
and the protected egress node address with the auto-discovery route.
When the ingress PE of the MVPN learns which egress PE can be used as
the backup node to protect the primary egress node, it can directly
trigger to set up the P2MP LSP with local protection of egress nodes.
The method saves much provision effort since it need not statically
designate the protection between the backup egress node and the
primary egress node for a P2MP LSP.
3.4. Centralized Multicast Traffic Optimization
As the development of central controlled multicast application such
as PCE-initiated P2MP LSP
[I-D.palle-pce-stateful-pce-initiated-p2mp-lsp], PCE can be used to
initiate the setup of RSVP-TE P2MP LSP for the purpose of traffic
optimization. In order to support such applications, the controller
should learn the roles of Multicast VPN instances distributed on
different PEs.
Li & Zhuang Expires April 20, 2016 [Page 4]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
4. Role Discovery Attribute
This document defines and uses a new BGP attribute called the "Role
Discovery attribute". This is an optional transitive BGP attribute.
The format of this attribute is defined as follows:
+-----------------------------------+
|R|RS|L|LS| Reserved |
+-----------------------------------+
|Protected Root's IP Addr(Optional) |
+-----------------------------------+
|Protected Leaf's IP Addr(Optional) |
+-----------------------------------+
R field is one bit to identify if the PE is used as the root node in
the MVPN.
RS field is two bits to identify the primary/backup state if the PE
is used as the root node. There are three values for the RS field:
o 0 means the PE is used as the primary root node.
o 1 means the PE is used as the backup root node. But the protected
root node's IP address does not exist.
o 2 means the PE is used as the backup root node and there exists
the protected root node's IP address.
L field is one bit to identify if the PE is used as the leaf node in
the MVPN.
LS field is two bits to identify the primary/backup state if the PE
is used as the leaf node. There are three values for the LS field:
o 0 means the PE is used as the primary leaf node.
o 1 means the PE is used as the backup leaf node. But the protected
leaf node's IP address does not exist.
o 2 means the PE is used as the backup leaf node and there exists
the protected leaf node's IP address.
Protected Root's IP Addr is an optional field. It specifies the
IPv4/IPv6 address of the protected root node. The field exists only
when the value of the RS field is 2.
Li & Zhuang Expires April 20, 2016 [Page 5]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
Protected Leaf's IP Addr is an optional field. It specifies the
IPv4/IPv6 address of the protected leaf node. The field exists only
when the value of the LS field is 2.
The Role Discovery attribute can be used in conjunction with Intra-AS
I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes.
5. Operations
5.1. Advertisement of Role-based State for Root Nodes
The Role Discovery attribute can be used in conjunction with Intra-AS
I-PMSI A-D routes to advertise the role and corresponding primary/
backup state for root nodes in MPLS/BGP MVPN.
If a PE is specified as the root PE for a specific MVPN, it MUST set
the R bit as 1 in the A-D route. Otherwise, the R bit MUST NOT be
set.
If the root PE is used as the backup ingress node to protect the
primary root PE, the RS field in the A-D route MUST set as 1 when
there is no determined root node to be protected. In this case the
primary root node protected by the backup root node can be calculated
by all nodes according to some uniform algorithms which is out of the
scope of this document. When the RS field in the A-D route is set as
1, the Protected Root's IP Addr field MUST NOT exist in the A-D
route.
If the root PE is used as the backup ingress node to protect the
primary root PE, the RS field in the A-D route MUST set as 2 when
there is a determined root node to be protected. In this case the
Protected Root's IP Addr field MUST exist in the A-D route which will
specify the IPv4/IPv6 address of the protected root node.
If the R bit is set as 1 and the RS field is set as 0 in the A-D
route, the Protected Root's IP Addr field MUST NOT exist in the A-D
route. This means the PE is used as the primary root PE.
If the R bit in the A-D route is set as 0, the RS field MUST be
ignored and the Protected Root's IP Addr field MUST NOT exist in the
A-D route.
5.2. Advertisement of Role-based State for Leaf Nodes
The Role Discovery attribute can be used in conjunction with Intra-AS
I-PMSI A-D routes to advertise the role and corresponding primary/
backup state for leaf nodes in MPLS/BGP MVPN.
Li & Zhuang Expires April 20, 2016 [Page 6]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
If a PE is specified as the leaf PE for a specific MVPN, it MUST set
the L bit as 1 in the A-D route. Otherwise, the L bit MUST NOT be
set.
If the leaf PE is used as the backup egress node to protect the
primary leaf PE, the LS field in the A-D route MUST set as 1 when
there is no determined leaf node to be protected. In this case the
primary leaf node protected by the backup leaf node can be calculated
by all nodes according to some uniform algorithms which is out of the
scope of this document. When the LS field in the A-D route is set as
1, the Protected Leaf's IP Addr field MUST NOT exist in the A-D
route.
If the leaf PE is used as the backup egress node to protect the
primary leaf PE, the LS field in the A-D route MUST set as 2 when
there is a determined leaf node to be protected. In this case the
Protected Leaf's IP Addr field MUST exist in the A-D route which will
specify the IPv4/IPv6 address of the protected leaf node.
If the L bit is set as 1 and the LS field is set as 0 in the A-D
route, the Protected Leaf's IP Addr field MUST NOT exist in the A-D
route. This means the PE is used as the primary leaf PE.
If the L bit in the A-D route is set as 0, the LS field MUST be
ignored and the Protected Leaf's IP Addr field MUST NOT exist in the
A-D route.
6. IANA Considerations
This document defines and uses a new BGP attribute called the "Role
Discovery attribute". This is an optional transitive BGP attribute.
The type is to be assigned by IANA.
7. Security Considerations
There are no additional security aspects beyond those specified in
([RFC6513]) and [RFC6514].
8. Acknowledgements
The authors would like to thank Hui Ni and Yisong Liu for their
contributions to this work
9. References
Li & Zhuang Expires April 20, 2016 [Page 7]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
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
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
9.2. Informative References
[I-D.ietf-mpls-rsvp-egress-protection]
Chen, H., Li, Z., So, N., Liu, A., Saad, T., Xu, F., Toy,
M., Huang, L., and L. Liu, "Extensions to RSVP-TE for LSP
Egress Local Protection", draft-ietf-mpls-rsvp-egress-
protection-02 (work in progress), October 2014.
[I-D.ietf-mpls-rsvp-ingress-protection]
Chen, H. and R. Torvi, "Extensions to RSVP-TE for LSP
Ingress Local Protection", draft-ietf-mpls-rsvp-ingress-
protection-02 (work in progress), October 2014.
[I-D.palle-pce-stateful-pce-initiated-p2mp-lsp]
Palle, U., Dhody, D., Tanaka, Y., Ali, Z., and V. Beeram,
"PCEP Extensions for PCE-initiated Point-to-Multipoint LSP
Setup in a Stateful PCE Model", draft-palle-pce-stateful-
pce-initiated-p2mp-lsp-06 (work in progress), June 2015.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li & Zhuang Expires April 20, 2016 [Page 8]
Internet-Draft Role-Based State Advertisement in MVPN October 2015
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Li & Zhuang Expires April 20, 2016 [Page 9]
