Internet DRAFT - draft-allan-l2vpn-mldp-evpn
draft-allan-l2vpn-mldp-evpn
L2VPN Working Group Dave Allan, Jeff Tantsura
Internet Draft Ericsson
Intended status: Standards Track Sam Aldrin
Expires: January 2015 Huawei
July 2014
mLDP extensions for integrating EVPN and multicast
draft-allan-l2vpn-mldp-evpn-03
Abstract
This document describes how mLDP FECs can be encoded to support both
service specific and shared multicast trees and describes the
associated procedures for EVPN PEs. Thus, mLDP can implement
multicast for EVPN.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2014.
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Allan et al., Expires January 2015 [Page 1]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
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
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
1.1. Authors......................................................2
1.2. Requirements Language........................................3
2. Changes since last version.....................................3
3. Conventions used in this document..............................3
3.1. Terminology..................................................3
4. Solution Overview..............................................4
5. Elements of Procedure..........................................4
6. FEC Encoding...................................................5
6.1. VLAN tagged FEC..............................................5
6.2. I-SID tagged FEC.............................................6
6.3. Shared FEC...................................................6
7. Acknowledgements...............................................7
8. Security Considerations........................................7
9. IANA Considerations............................................7
10. References....................................................7
10.1. Normative References........................................7
10.2. Informative References......................................8
11. Authors' Addresses............................................8
1. Introduction
This document describes how mLDP FECs can be encoded to permit mLDP
to implement multicast for EVPN. Such support can be applied to
interconnecting 802.1ad, 802.1ah, 802.1aq, and 802.1Qbp based
networks.
1.1. Authors
David Allan, Jeff Tantsura, Sam Aldrin
Allan et al., Expires January 2015 [Page 2]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
1.2. 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 RFC2119 [1].
2. Changes since last version
1) Added co-author.
3. Conventions used in this document
3.1. Terminology
BCB: Backbone Core Bridge
BEB: Backbone Edge Bridge
BU: Broadcast/Unknown
B-MAC: Backbone MAC Address
B-VID: Backbone VLAN ID
CE: Customer Edge
C-MAC: Customer/Client MAC Address
DF: Designated Forwarder
ESI: Ethernet segment identifier
EVPN: Ethernet VPN
FEC: Forwarding Equivalence Class
ISIS-SPB: IS-IS as extended for SPB
I-SID: Backbone Service Instance ID
mLDP: Multicast Label Distribution Protocol
MP2MP: Multipoint to Multipoint
MVPN: Multicast VPN
NLRI: Network layer reachability information
PBBN: Provider Backbone Bridged Network
BEB-PE: Co located BEB and PE
PE: provider edge
P2MP: Point to Multipoint
P2P: Point to Point
Allan et al., Expires January 2015 [Page 3]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
RD: Route Distinguisher
SPB: Shortest path bridging
SPBM: Shortest path bridging MAC mode
VID: VLAN ID
VLAN: Virtual LAN
4. Solution Overview
mLDP[6] permits arbitrary FEC encodings for the naming of multicast
trees to be defined. This property is leveraged to permit both
service specific trees and shared trees to be utilized to augment
EVPN unicast connectivity with network based multicast and avoid the
inefficiencies of edge replication.
The flooding of EVPN BGP NLRI and ISIS-SPB [7] provides each PE with
sufficient information to self elect as a DF, have knowledge of peer
DFs, and from that construct the identifiers for the required set of
multicast trees to support the current service set, which can then be
encoded as mLDP FECs, and used to originate label mapping and label
withdraw messages.
Both p2mp and mp2mp trees are supported with different FEC encodings
for each. Service specific tree FECs encode the VID or I-SID
associated with the service instance in the subtending network.
Shared tree FECs encode a sorted list of the IP addresses of the leaf
DFs.
5. Elements of Procedure
A PE advertises whether or not it supports shared tree (actual
mechanism is TBD). Support of both shared and service specific trees
is mandatory. Whether a PE supports shared trees is a network design
decision.
A PE is expected to maintain a list of current multicast memberships.
A PE, upon receipt of new information from BGP or ISIS-SPB:
1) Evaluates it"s DF roles (as described in [5]).
2) On the basis of the PE"s DF role, determines the set of services
it needs to support.
3) Determines the set of peer DFs for each service.
Allan et al., Expires January 2015 [Page 4]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
4) On the basis of requisite tree types and ESI multicast
registrations (p2mp or mp2mp/service specific or shared), determines
the name of the multicast tree needed for the service.
For example an ESI may only have source interest in an ISIS-SPB I-SID
in which case it would:
- require a p2mp tree to the set of DFs registering receive
interest in the I-SID for p2mp trees
- require an upstream label mapping to the set of DFs registering
receive interest in the I_SID for mp2mp trees
5) Upon completion of evaluating the set of services, de-duplicates
the required tree membership list.
6) Compares the required list with the existing list, and originates
the necessary label mapping and label withdraw transactions to the
network state up to date.
7) Configures the dataplane for the appropriate service to multicast
tree bindings.
6. FEC Encoding
6.1. VLAN tagged FEC
VLAN tagged FEC uses the mLDP p2mp (0x06) type FEC and the mLDP mp2mp
downstream (0x07) and upstream FECs (0x08)
The encoding of the opaque value is:
0 1 2 3
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 "x" | Length | <unused = 0> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype | VID | = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Allan et al., Expires January 2015 [Page 5]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
- RT is the route target for the EVPN instance
- Ethertype identifies the tag type (C 0x8100, S or B 0x88a8)
- VID is the VLAN ID tag value. If the VID=0, then this is the
default MDT for the RT and how VLAN unaware RTs are encoded, else it
permits MDTs to be defined for VLAN aware services.
6.2. I-SID tagged FEC
The encoding of the opaque value is:
0 1 2 3
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 "x+1" | Length | <unused = 0> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID | <unused = 0> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
- RT is the route target for the EVPN instance
- I-SID corresponds to the I-SID that will use the tree
6.3. Shared FEC
The encoding of the opaque value is:
0 1 2 3
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 "x+2" | Length | <unused = 0> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <sorted list of DF ip addresses> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Allan et al., Expires January 2015 [Page 6]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
Where:
- RT is the route target for the EVPN instance
- Sorted list of DF addresses identifies the set of leaves that have
registered interest in one or more Ethernet services (either C/S or I
tagged).
7. Acknowledgements
The authors would like to thank Panagiotis Saltsidis, Jakob Heitz,
Don Fedyk and Janos Farkas for their detailed review of this draft.
8. Security Considerations
For a future version of this document.
9. IANA Considerations
For a future version of this document.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq
Shortest Path Bridging", IETF RFC 6329, April 2012
[3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks
(VPNs)", IETF RFC 4364, February 2006
[4] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work
in progress, draft-ietf-l2vpn-evpn-01, July 2012
[5] Allan et.al. "802.1aq and 802.1Qbp Support over EVPN",
IETF work in progress, draft-allan-l2vpn-spb-evpn-03,
February 2013
[6] Wijnands et.al. "Label Distribution Protocol Extensions
for Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths". IETF RFC 6388, November 2011
Allan et al., Expires January 2015 [Page 7]
Internet-Draft draft-allan-l2vpn-mldp-evpn-03 July 2014
10.2. Informative References
[7] IEEE 802.1aq "IEEE Standard for Local and Metropolitan
Area Networks: Bridges and Virtual Bridged Local Area
Networks - Amendment 9: Shortest Path Bridging", June 2012
[8] IEEE 802.1Qbp "Draft IEEE Standard for Local and
Metropolitan Area Networks---Virtual Bridged Local Area
Networks - Amendment: Equal Cost Multiple Paths (ECMP),
802.1Qbp", draft 1.3, February 2013
[9] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft-
ietf-l2vpn-pbb-evpn-03, June 2012
[10] IEEE 802.1Q-2011 "IEEE Standard for Local and metropolitan
area networks--Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks", August 2011
11. Authors' Addresses
Dave Allan (editor)
Ericsson
300 Holger Way
San Jose, CA 95134
USA
Email: david.i.allan@ericsson.com
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
Email: jeff.tantsura@ericsson.com
Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95051
EMail: aldrin.ietf@gmail.com
Allan et al., Expires January 2015 [Page 8]
