Internet DRAFT - draft-li-l3vpn-mvpn-role-state-ad
draft-li-l3vpn-mvpn-role-state-ad
Network Working Group Z. Li
Internet-Draft Z. Zhuang
Intended status: Standards Track H. Ni
Expires: January 4, 2015 Huawei Technologies
July 3, 2014
Role-Based State Advertisement for Multicast in MPLS/BGP IP VPNs
draft-li-l3vpn-mvpn-role-state-ad-02
Abstract
The document defines a new type of Intra-AS I-PMSI A-D route to
advertise the role and corresponding primary/backup state for
Multicast in MPLS/BGP IP VPNs. The role-based state advertisement
can help optimization of process in MPLS/BGP Multicast VPN to reduce
unnecessary traffic replication and facilitate service provision.
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 January 4, 2015.
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
Li, et al. Expires January 4, 2015 [Page 1]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 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
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
4.1. Role-Based Intra-AS I-PMSI A-D Route . . . . . . . . . . 4
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. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.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) 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 requirements to advertise the role and
corresponding state for Multicast in MPLS/BGP IP VPNs and defines a
new type of Intra-AS I-PMSI A-D route to achieve the object. The
Li, et al. Expires January 4, 2015 [Page 2]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
role-based state advertisement can help optimization of multicast
process to reduce unnecessary traffic replication and facilitate
service provision in MPLS/BGP Multicast VPN .
2. Terminology
CE: Customer Edge
PE: Provider Edge
MVPN: Multicast VPN
3. Motivations
3.1. Easing Provision of mLDP P2MP LSP
An mLDP P2MP LSP can be used to bear multicast service in MPLS/BGP
MVPN. 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 CE2 to PE2 for the MVPN, the
multicast traffic sent from 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, et al. Expires January 4, 2015 [Page 3]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
+---------------+
| 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] propose 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.
4. Protocol Extensions
A new type of Intra-AS I-PMSI A-D route is defined for the MCAST-VPN
NLRI. It is called as Role-Based Intra-AS I-PMSI A-D route. Route
Type for the A-D route is to be defined.
4.1. Role-Based Intra-AS I-PMSI A-D Route
A Role-Based Intra-AS I-PMSI A-D route type specific MCAST-VPN NLRI
consists of the following:
Li, et al. Expires January 4, 2015 [Page 4]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
|R|RS|L|LS| Reserved |
+-----------------------------------+
|Protected Root's IP Addr(Optional) |
+-----------------------------------+
|Protected Leaf's IP Addr(Optional) |
+-----------------------------------+
The Route Distinguisher (RD) is encoded as described in [RFC4364].
Originating Router's IP Addr is to advertise the originating PE's
IPv4/IPv6 address.
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:
-- 0 means the PE is used as the primary root node.
-- 1 means the PE is used as the backup root node. But the protected
root node's IP address does not exist.
-- 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:
-- 0 means the PE is used as the primary leaf node.
-- 1 means the PE is used as the backup leaf node. But the protected
leaf node's IP address does not exist.
-- 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, et al. Expires January 4, 2015 [Page 5]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
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.
5. Operations
5.1. Advertisement of Role-Based State for Root Nodes
The Role-Based Intra-AS I-PMSI A-D route can be used 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 are 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-Based Intra-AS I-PMSI A-D route can be used to advertise the
role and corresponding primary/backup state for leaf nodes in MPLS/
BGP MVPN.
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.
Li, et al. Expires January 4, 2015 [Page 6]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
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 are 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 a new type of A-D route for MCAST-VPN NLRI.
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. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
Li, et al. Expires January 4, 2015 [Page 7]
Internet-Draft Role-Based State Advertisement in MVPN July 2014
8.2. Informative References
[I-D.ietf-mpls-rsvp-egress-protection]
Chen, H., Ning, S., Liu, A., Xu, F., Toy, M., Huang, L.,
and L. Liu, "Extensions to RSVP-TE for LSP Egress Local
Protection", draft-ietf-mpls-rsvp-egress-protection-00
(work in progress), March 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-00 (work in progress), March 2014.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Hui Ni
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: nihui@huawei.com
Li, et al. Expires January 4, 2015 [Page 8]