Internet DRAFT - draft-li-l2vpn-evpn-mcast-state-ad
draft-li-l2vpn-evpn-mcast-state-ad
Network Working Group Z. Li
Internet-Draft J. Zhang
Intended status: Standards Track Huawei Technologies
Expires: August 18, 2014 February 14, 2014
Multicast State Advertisement in E-VPN
draft-li-l2vpn-evpn-mcast-state-ad-01
Abstract
The document defines a new extended community to advertise the active
or inactive state for multicast along with the Inclusive Multicast
Ethernet Tag route or Ethernet Auto-Discovery route in E-VPN. The
multicast state advertised can help optimization of multicast process
in E-VPN to reduce unnecessary traffic replication for the broadcast,
unknown unicast and multicast (BUM) traffic.
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 August 18, 2014.
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 & Zhang Expires August 18, 2014 [Page 1]
Internet-Draft Multicast State Advertisement in E-VPN February 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. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Multicast State Advertisement per EVI . . . . . . . . . . 4
5.2. Multicast State Advertisement per <EVI, ESI> . . . . . . 5
6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 5
6.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
E-VPN [I-D.ietf-l2vpn-evpn] introduces a solution for multipoint
L2VPN services, with advanced multi-homing capabilities, using BGP
for distributing customer/client MAC address reachability information
over the core MPLS/IP network.
In E-VPN when the PE receives the broadcast, unknown unicast, or
multicast (BUM) traffic, it can forward the traffic to other PEs of
the E-VPN through ingress replication or P2MP LSPs. The Inclusive
Multicast Ethernet Tag routes which are distributed to discover the
multicast membership of the E-VPN can be used to trigger setup of
ingress replication tunnels or P2MP LSPs. In the actual network, the
multicast service maybe use a great deal of bandwidth. It is
important to save the possible bandwidth when deploy multicast
service.
This document defines a new extended community to advertise the
active or inactive state for multicast along with Inclusive Multicast
Ethernet Tag routes or Ethernet Auto-Discovery routes in E-VPN. The
multicast state advertised can help optimization of multicast process
Li & Zhang Expires August 18, 2014 [Page 2]
Internet-Draft Multicast State Advertisement in E-VPN February 2014
in E-VPN to reduce unnecessary traffic replication for the BUM
traffic.
2. Terminology
CE: Customer Edge
E-VPN: Ethernet VPN
ES: Ethernet Segment
ESI: Ethernet Segment Identifier
EVI: Ethernet VPN Instance
PE: Provider Edge
S-EVPN: Segment-based EVPN
3. Problem Statements
There exist multi-homing scenarios in E-VPN. As shown in the figure
1, CE2 multi-homes to two PEs ( PE2 and PE3). When ingress
replication is used for the BUM traffic, PE1 needs to send two copies
of the same BUM traffic to both PE2 and PE3. We assume that PE2 is
the Designated Forwarder (DF) for the CE2 in the E-VPN. Thus only
PE2 will forward the BUM traffic to CE2 while the traffic to the PE3
will be dropped. From the example we can see that the copy of the
BUM traffic sent to PE3 is not necessary in the network. If PE1 can
learn that the remote PE cannot forward the BUM traffic to any CE,
the bandwidth can be saved since PE1 can stop to replicate the
unnecessary traffic to the remote PE. In order to achieve the
object, the active or inactive state related with forwarding the BUM
traffic in a EVI can be advertised by the egress PE. As to a
specific EVI, the active state means that there is at least one
Ethernet Segment for the EVI on the PE which needs to forward the BUM
traffic to the CE and the inactive state means that none of Ethernet
Segments for the EVI on the PE would forward the BUM traffic to CEs.
As to a specific Ethernet Segment in a EVI, the active state means
the Ethernet Segment in the EVI would forward the BUM traffic to the
CE and the inactive state means that the Ethernet Segment in the EVI
would not forward the BUM traffic to the CE.
Li & Zhang Expires August 18, 2014 [Page 3]
Internet-Draft Multicast State Advertisement in E-VPN February 2014
+---------------+
| IP/MPLS |
| Network |
+----+ ES1 +----+ +----+
| CE1|-----| |-----------| |____ES2
+----+ | PE1| | PE2| \
| |-------- +----+ \+----+
+----+ \ | | CE2|
| \ +----+ /+----+
| \| |____/
| | PE3| ES2
| +----+
| |
+---------------+
Figure 1 Multi-homing Network of E-VPN
4. Protocol Extensions
A new extended community is defined to identify the multicast state
of the EVI on the leaf PE. This extended community is called as
Multicast State Extended Community. It is a new transitive extended
community with the Type field is 0x06, and the Sub-Type is to be
defined. It may be advertised along with Inclusive Multicast
Ethernet Tag routes or Ethernet Auto-Discovery routes.
Each Multicast State Extended Community is encoded as a 8-octet value
as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type(TBD) | State(One Octet) |Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The state is encoded as one octet. A value of 0 means that the
multicast state is Active and a value of 1 means that the multicast
state is Inactive.
5. Operations
5.1. Multicast State Advertisement per EVI
If the multicast state of a specific EVI needs to be advertised, the
Multicast State Extended Community MUST be included in the Inclusive
Multicast Ethernet Tag Route for the EVI. Construction of the
Inclusive Multicast Ethernet Tag Route can refer to Section 12.1 in
[I-D.ietf-l2vpn-evpn]. If the multicast state of the EVI is Active,
Li & Zhang Expires August 18, 2014 [Page 4]
Internet-Draft Multicast State Advertisement in E-VPN February 2014
the state field in the Multicast State Extended Community MUST be set
to 0. If the multicast state of the EVI is Inactive, the state field
in the Multicast State Extended Community MUST be set to 1. When a
PE receives the Inclusive Multicast Ethernet Tag Route with the EVI
State Extended Community, it can determine the multicast state of the
EVI on the leaf PE originating the route is Active or Inactive.
5.2. Multicast State Advertisement per <EVI, ESI>
If the multicast state of a specific Ethernet Segment in an EVI needs
to be advertised, the Multicast State Extended Community MUST be
included in the Ethernet Auto-Discovery route for the Ethernet
Segment in the EVI. Constructing the Ethernet A-D Route per EVI can
refer to Section 9.4 of [I-D.ietf-l2vpn-evpn]. The Ethernet A-D
route can be constructed for a given <ESI, Ethernet Tag ID> tuple per
EVI or per <ESI, EVI>(where the Ethernet Tag ID is set to 0). If the
Ethernet Segment of a specific EVI transports the BUM traffic, the
state field in the Multicast State Extended Community MUST be set to
0. If the Ethernet Segment of the EVI does not transport the BUM
traffic, the state field in the Multicast State Extended Community
MUST be set to 1. When a PE receives Ethernet A-D routes per EVI
with the EVI State Extended Community, it can determine the multicast
state of the Ethernet Segment of the EVI on the leaf PE originating
the route is Active or Inactive. According to the states of the
Ethernet Segments of the EVI on the leaf PE, the ingress PE can
determines the state of the EVI on the leaf PE. That is, if there
exists one Ethernet Segment of the EVI which state is Active, it can
determine the state of the EVI on the leaf PE is Active. If there is
no Ethernet Segment of the EVI which state is Active, it can
determine the state of the EVI is Inactive.
6. Application
6.1. Ingress Replication
When a PE determines the multicast state of the EVI on the leaf PE
through the Multicast State Extended Community advertised along with
the Inclusive Multicast Ethernet Tag routes or Ethernet A-D routes,
it can only setup the P2P tunnels to the leaf PEs which states are
Active for Ingress Replication while it will not setup the P2P tunnel
to the leaf PE which EVI state is Inactive or it can stop the traffic
to be replicated on the existing P2P tunnel to this leaf PE. Thus
the bandwidth for the BUM traffic can be saved in the network.
Li & Zhang Expires August 18, 2014 [Page 5]
Internet-Draft Multicast State Advertisement in E-VPN February 2014
6.2. P2MP MPLS LSPs
When a PE determines the multicast state of the EVI on the leaf PE
through the Multicast State Extended Community advertised along with
the Inclusive Multicast Ethernet Tag routes or Ethernet A-D routes,
it can only setup the P2MP MPLS LSP to the leaf PEs which states are
Active. Thus the bandwidth for the BUM traffic can be saved in the
network.
[I-D.chen-mpls-p2mp-egress-protection] proposes a mechanism for
locally protecting egress nodes of an MPLS TE P2MP LSP. In the
mechanism, 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 multicast state advertisement proposed by the
document can facilitate the provision of the local protection
mechanism. The ingress PE of a specific EVI can learn the multicast
state of egress PEs of the EVI through the advertised Multicast State
Extended Community. Through the Ethernet A-D routes per EVI the
ingress PE can also learn the information on which pair of PEs are
multi-homed by one CE. Based on the information, the ingress PE can
determine which egress PE can be used as the backup node to protect
the primary egress node for a P2MP LSP using for the EVI. So the
ingress PE can trigger to setup P2MP LSP with locally protecting
egress nodes. The method saves much provision effort for this type
of local protection through the auto-discovery mechanism since it
need not statically designate the protection between the backup
egress node and the primary egress node for a P2MP LSP.
7. IANA Considerations
This document defines a new BGP Extended Community called as
Multicast State Extended Community. The sub-type value for this
extended community is to be assigned by IANA.
8. Security Considerations
There are no additional security aspects beyond those of E-VPN
([I-D.ietf-l2vpn-evpn]).
9. References
9.1. Normative References
Li & Zhang Expires August 18, 2014 [Page 6]
Internet-Draft Multicast State Advertisement in E-VPN February 2014
[I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
draft-ietf-l2vpn-evpn-04 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.chen-mpls-p2mp-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-chen-mpls-p2mp-egress-protection-11
(work in progress), February 2014.
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Junlin Zhang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: jackey.zhang@huawei.com
Li & Zhang Expires August 18, 2014 [Page 7]
