MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-03
|
| Document |
Type |
|
Active Internet-Draft (bess WG)
|
|
Last updated |
|
2019-10-24
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
| Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
I-D Exists
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
BESS Z. Zhang
Internet-Draft E. Rosen
Updates: 7432, 6514, 7582 (if approved) W. Lin
Intended status: Standards Track Juniper Networks
Expires: April 26, 2020 Z. Li
Huawei Technologies
I. Wijnands
Cisco Systems
October 24, 2019
MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-03
Abstract
The MVPN specifications allow a single Point-to-Multipoint (P2MP)
tunnel to carry traffic of multiple VPNs. The EVPN specifications
allow a single P2MP tunnel to carry traffic of multiple Broadcast
Domains (BDs). These features require the ingress router of the P2MP
tunnel to allocate an upstream-assigned MPLS label for each VPN or
for each BD. A packet sent on a P2MP tunnel then carries the label
that is mapped to its VPN or BD. (In some cases, a distinct
upstream-assigned is needed for each flow.) Since each ingress
router allocates labels independently, with no coordination among the
ingress routers, the egress routers may need to keep track of a large
number of labels. The number of labels may need to be as large (or
larger) than the product of the number of ingress routers times the
number of VPNs or BDs. However, the number of labels can be greatly
reduced if the association between a label and a VPN or BD is made by
provisioning, so that all ingress routers assign the same label to a
particular VPN or BD. New procedures are needed in order to take
advantage of such provisioned labels. These new procedures also
apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document
updates RFCs 6514, 7432 and 7582 by specifying the necessary
procedures.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Zhang, et al. Expires April 26, 2020 [Page 1]
Internet-Draft mvpn-evpn-aggregation-label October 2019
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 https://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 26, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://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. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Problem Description . . . . . . . . . . . . . . . . . . . 4
2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 5
2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 7
2.2.3. Summary of Label Allocation Methods . . . . . . . . . 9
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Context Label Space ID Extended Community . . . . . . . . 9
3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Show full document text