draft-ietf-bess-mvpn-evpn-aggregation-label-00.txt   draft-ietf-bess-mvpn-evpn-aggregation-label-01.txt 
BESS Z. Zhang BESS Z. Zhang
Internet-Draft E. Rosen Internet-Draft E. Rosen
Updates: 7432, 6514, 7582 (if approved) W. Lin Updates: 7432, 6514, 7582 (if approved) W. Lin
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: May 30, 2019 Z. Li Expires: June 10, 2019 Z. Li
Huawei Technologies Huawei Technologies
I. Wijnands I. Wijnands
Cisco Systems Cisco Systems
November 26, 2018 December 7, 2018
MVPN/EVPN Tunnel Aggregation with Common Labels MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-00 draft-ietf-bess-mvpn-evpn-aggregation-label-01
Abstract Abstract
The MVPN specifications allow a single Point-to-Multipoint (P2MP) The MVPN specifications allow a single Point-to-Multipoint (P2MP)
tunnel to carry traffic of multiple VPNs. The EVPN specifications tunnel to carry traffic of multiple VPNs. The EVPN specifications
allow a single P2MP tunnel to carry traffic of multiple Broadcast allow a single P2MP tunnel to carry traffic of multiple Broadcast
Domains (BDs). These features require the ingress router of the P2MP Domains (BDs). These features require the ingress router of the P2MP
tunnel to allocate an upstream-assigned MPLS label for each VPN or 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 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 that is mapped to its VPN or BD. (In some cases, a distinct
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2019. This Internet-Draft will expire on June 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Problem Description . . . . . . . . . . . . . . . . . . . 4 2.1. Problem Description . . . . . . . . . . . . . . . . . . . 4
2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 5 2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 5
2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 6 2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 6 2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 7
2.2.3. Summary of Label Allocation Methods . . . . . . . . . 8 2.2.3. Summary of Label Allocation Methods . . . . . . . . . 9
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Context Label Space ID Extended Community . . . . . . . . 9 3.1. Context Label Space ID Extended Community . . . . . . . . 9
3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Terminologies 1. Terminologies
Familiarity with MVPN/EVPN protocols and procedures is assumed. Some Familiarity with MVPN/EVPN protocols and procedures is assumed. Some
terminologies are listed below for convenience. terminologies are listed below for convenience.
o BUM: Broadcast, Unknown Unicast, or Multicast (traffic). o BUM: Broadcast, Unknown Unicast, or Multicast (traffic).
o BD: Broadcast Domain. o BD: Broadcast Domain.
o PMSI: Provider Multicast Service Interface - a pseudo interface o PMSI: Provider Multicast Service Interface - a pseudo interface
for a PE to send overlay/customer multicast traffic via underlay/ for a PE to send overlay/customer multicast traffic via underlay/
provider tunnels. Includes I/S-PMSI (often referred to as x-PMSI) provider tunnels. Includes I/S-PMSI (often referred to as x-PMSI)
for Inclusive/Selective-PMSI. for Inclusive/Selective-PMSI.
o IMET: Inclusive Multicast Ethernet Tag route. An EVPN specific o IMET: Inclusive Multicast Ethernet Tag route. An EVPN specific
name for I-PMSI A-D route. name for I-PMSI A-D route.
o PTA: PMSI Tunnel Attribute. A BGP attribute that may be attached
to an BGP-MVPN/EVPN A-D routes.
o ESI: Ethernet Segment Identifier. o ESI: Ethernet Segment Identifier.
2. Introduction 2. Introduction
MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to
transport customer multicast traffic across a service provider's transport customer multicast traffic across a service provider's
backbone network. Often, a given P2MP tunnel carries the traffic of backbone network. Often, a given P2MP tunnel carries the traffic of
only a single VPN. There are however procedures defined that allow a only a single VPN. There are however procedures defined that allow a
single P2MP tunnel to carry traffic of multiple VPNs. In this case, single P2MP tunnel to carry traffic of multiple VPNs. In this case,
the P2MP tunnel is called an "aggregate tunnel". The PE router that the P2MP tunnel is called an "aggregate tunnel". The PE router that
skipping to change at page 10, line 5 skipping to change at page 10, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o ID-Type: A 2-octet field that specifies the type of Label Space o ID-Type: A 2-octet field that specifies the type of Label Space
ID. In this document, the ID-Type is 0, indicating that the ID- ID. In this document, the ID-Type is 0, indicating that the ID-
Value field is a label. Value field is a label.
o ID-Value: A 4-octet field that specifies the value of Label Space o ID-Value: A 4-octet field that specifies the value of Label Space
ID. When it is a label (with ID-Value 0), the most significant ID. When it is a label (with ID-Value 0), the most significant
20-bit is set to the label value. 20-bit is set to the label value.
This document introduces a DCB-bit (to be assigned by IANA) in the
"Additional PMSI Tunnel Attribute Flags" BGP Extended Community
[RFC7902].
In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
route "carries DCB-flag" or "has DCB-flag attached" we mean the
following:
o The route carries a PMSI Tunnel Attribute (PTA) and its Flags
field has the Extension bit set
o The route carries an "Additional PMSI Tunnel Attribute Flags" EC
and its DCB-bit is set
3.2. Procedures 3.2. Procedures
The protocol and procedures specified in this section need not be The protocol and procedures specified in this section need not be
applied unless when BIER, or P2MP/MP2MP tunnel aggregation is used applied unless when BIER, or P2MP/MP2MP tunnel aggregation is used
for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN multi- for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN multi-
homing. homing.
By means outside the scope of this document, each VPN/BD/ES is By means outside the scope of this document, each VPN/BD/ES is
assigned a label from the DCB or one of those few context label assigned a label from the DCB or one of those few context label
spaces, and every PE that is part of the VPN/BD/ES is aware of the spaces, and every PE that is part of the VPN/BD/ES is aware of the
assignment. The ES label and the BD label MUST be assigned from the assignment. The ES label and the BD label MUST be assigned from the
same source. If PE Distinguisher labels are used [RFC7582], they same source. If PE Distinguisher labels are used [RFC7582], they
must be allocated from the same source as well. must be allocated from the same source as well.
In case of tunnel segmentation, each PE is also assigned a disjoint In case of tunnel segmentation, each PE is also assigned a disjoint
label block from one of those few context label spaces and it label block from one of those few context label spaces and it
allocates labels for its segmented PMSI routes from its assigned allocates labels for its segmented PMSI routes from its assigned
label block. label block.
When a PE originates an x-PMSI/IMET route, if the label is assigned When a PE originates/re-advertises an x-PMSI/IMET route, the route
from the DCB, a C-bit in the PTA's Flags field is set to indicate the MUST carry a DCB-flag if and only if the label in its PTA is assigned
label is from the DCB. from the DCB.
If the VPN/BD/PMSI label is assigned from one of those few context If the VPN/BD/PMSI label is assigned from one of those few context
label spaces, a Context Label Space ID Extended Community is attached label spaces, a Context Label Space ID Extended Community is attached
to the route. The ID-Type in the EC is set to 0 and the ID-Value is to the route. The ID-Type in the EC is set to 0 and the ID-Value is
set to a label allocated from the DCB and identifies the context set to a label allocated from the DCB and identifies the context
label space. When an ingress PE sends traffic, it imposes the DCB label space. When an ingress PE sends traffic, it imposes the DCB
label that identifies the context label space after it imposes the label that identifies the context label space after it imposes the
label (that is advertised in the PTA's Label field of the x-PMSI/IMET label (that is advertised in the PTA's Label field of the x-PMSI/IMET
route) for the VPN/BD and/or the label (that is advertised in the ESI route) for the VPN/BD and/or the label (that is advertised in the ESI
Label EC) for the ESI, and then imposes the encapsulation for the Label EC) for the ESI, and then imposes the encapsulation for the
transport tunnel. transport tunnel.
When a PE receives an x-PMSI/IMET route with the Context Label Space When a PE receives an x-PMSI/IMET route with the Context Label Space
ID EC, it programs its default MPLS forwarding table to map the label ID EC, it programs its default MPLS forwarding table to map the label
in the EC that identifies the context label space to a corresponding in the EC that identifies the context label space to a corresponding
context label table in which the next label lookup is done for context label table in which the next label lookup is done for
traffic that this PE receives. traffic that this PE receives.
The receiving PE then programs the label in the PTA or ESI Label EC The receiving PE then programs the label in the PTA or ESI Label EC
into either the default mpls forwarding table (if the C-bit is set) into either the default mpls forwarding table (if the route carries
or the context label table (if the Context Label Space ID EC is the DCB-flag) or the context label table (if the Context Label Space
present) according to the x-PMSI/IMET route. ID EC is present) according to the x-PMSI/IMET route.
A PE MUST NOT both set the C-bit in the PTA of an x-PMSI/IMET route A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and
and attach the Context Label Space ID EC in the route. A PE MUST attach the Context Label Space ID EC in the route. A PE MUST ignore
ignore a received route with both the C-bit set and the Context Label a received route with both the DCB-flag and the Context Label Space
Space ID EC attached. If neither C-bit is set nor the Context Label ID EC attached. If neither the DCB-flag nor the Context Label Space
Space ID EC is attached, the label in the PTA or ESI Label EC is ID EC is attached, the label in the PTA or ESI Label EC is treated as
treated as the upstream allocated from the source PE's label space, the upstream allocated from the source PE's label space, and
and procedures in [RFC6514][RFC7432] must be followed. procedures in [RFC6514][RFC7432] must be followed.
In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the
same tunnel, one of the following conditions MUST be met, so that a same tunnel, one of the following conditions MUST be met, so that a
receiving PE can correctly intrerpret the label that follows the receiving PE can correctly interpret the label that follows the
tunnel label in the right context. tunnel label in the right context.
o They MUST all have the C-bit set, or, o They MUST all have the DCB-flag, or,
o They MUST all carry the Context Label Space ID EC, or, o They MUST all carry the Context Label Space ID EC, or,
o None of them has the C-bit set, or, o None of them has the DCB-flag, or,
o None of them carry the Context Label Space ID EC. o None of them carry the Context Label Space ID EC.
4. IANA Considerations 4. IANA Considerations
This document introduces a C-bit in the Flags field of PTA. An IANA This document introduces a DCB-bit in the "Additional PMSI Tunnel
request will be submitted for bit 0x02 as the C-bit in the Attribute Flags" BGP Extended Community. An IANA request will be
P-Multicast Service Interface (PMSI) Tunnel Attribute Flags registry. submitted for bit 0 as the DCB-bit in the Additional PMSI Tunnel
This is subject to approval/change. Attribute Flags registry. This is subject to approval/change.
This document introduces a new Transitive Opaque Extended Community This document introduces a new Transitive Opaque Extended Community
"Context Label Space ID Extended Community". An IANA request will be "Context Label Space ID Extended Community". An IANA request will be
submitted for sub-type value 0x15 (subject to approval/change) in the submitted for sub-type value 0x15 (subject to approval/change) in the
BGP Transitive Opaqaue Extended Community Sub-Types registry. BGP Transitive Opaque Extended Community Sub-Types registry.
5. Acknowledgements 5. Acknowledgements
6. Contributors 6. Contributors
The following also contributed to this document. The following also contributed to this document.
Selvakumar Sivaraj Selvakumar Sivaraj
Juniper Networks Juniper Networks
skipping to change at page 12, line 35 skipping to change at page 13, line 5
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<https://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using "Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <https://www.rfc-editor.org/info/rfc7582>. July 2015, <https://www.rfc-editor.org/info/rfc7582>.
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016,
<https://www.rfc-editor.org/info/rfc7902>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-bess-evpn-bum-procedure-updates] [I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A.
Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- Sajassi, "Updates on EVPN BUM Procedures", draft-ietf-
bess-evpn-bum-procedure-updates-04 (work in progress), bess-evpn-bum-procedure-updates-04 (work in progress),
June 2018. June 2018.
[I-D.ietf-bier-evpn] [I-D.ietf-bier-evpn]
Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan,
 End of changes. 17 change blocks. 
32 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/