< draft-ietf-bess-mvpn-evpn-aggregation-label-05.txt   draft-ietf-bess-mvpn-evpn-aggregation-label-06.txt >
BESS Z. Zhang BESS Z. Zhang
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 7432, 6514, 7582 (if approved) E. Rosen Updates: 7432, 6514, 7582 (if approved) E. Rosen
Intended status: Standards Track Individual Intended status: Standards Track Individual
Expires: July 15, 2021 W. Lin Expires: October 18, 2021 W. Lin
Juniper Networks Juniper Networks
Z. Li Z. Li
Huawei Technologies Huawei Technologies
I. Wijnands I. Wijnands
Individual Individual
January 11, 2021 April 16, 2021
MVPN/EVPN Tunnel Aggregation with Common Labels MVPN/EVPN Tunnel Aggregation with Common Labels
draft-ietf-bess-mvpn-evpn-aggregation-label-05 draft-ietf-bess-mvpn-evpn-aggregation-label-06
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 20 skipping to change at page 2, line 20
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 July 15, 2021. This Internet-Draft will expire on October 18, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 49 skipping to change at page 2, line 49
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 . . . . . . . . . . . . . . . . . . 7 2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 7
2.2.3. Summary of Label Allocation Methods . . . . . . . . . 9 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. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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.
skipping to change at page 4, line 7 skipping to change at page 4, line 8
with an Unknown address, or Multicast traffic), across the provider with an Unknown address, or Multicast traffic), across the provider
network. Often a P2MP tunnel carries the traffic of only a single network. Often a P2MP tunnel carries the traffic of only a single
BD. However, there are procedures defined that allow a single P2MP BD. However, there are procedures defined that allow a single P2MP
tunnel to be an "aggregate tunnel" that carries traffic of multiple tunnel to be an "aggregate tunnel" that carries traffic of multiple
BDs. The procedures are analogous to the MVPN procedures -- the PE BDs. The procedures are analogous to the MVPN procedures -- the PE
router that is the ingress node of an aggregate P2MP tunnel allocates router that is the ingress node of an aggregate P2MP tunnel allocates
an upstream-assigned MPLS label for each BD, and each packet sent on an upstream-assigned MPLS label for each BD, and each packet sent on
the P2MP tunnel carries the upstream-assigned MPLS label that the the P2MP tunnel carries the upstream-assigned MPLS label that the
ingress PE has bound to the packet's BD. ingress PE has bound to the packet's BD.
MVPN and EVPN can also use BIER [RFC 8279] to transmit multicast MVPN and EVPN can also use BIER [RFC8279] to transmit multicast
traffic or BUM traffic [I-D.ietf-bier-mvpn] [I-D.ietf-bier-evpn]. traffic or BUM traffic [RFC8556] [I-D.ietf-bier-evpn]. Although BIER
Although BIER does not explicitly set up P2MP tunnels, from the does not explicitly set up P2MP tunnels, from the perspective of
perspective of MVPN/EVPN, the use of BIER transport is very similar MVPN/EVPN, the use of BIER transport is very similar to the use of
to the use of aggregate P2MP tunnels. When BIER is used, the PE aggregate P2MP tunnels. When BIER is used, the PE transmitting a
transmitting a packet (the "BFIR" [RFC 8279]) must allocate an packet (the "BFIR" [RFC8279]) must allocate an upstream-assigned MPLS
upstream-assigned MPLS label for each VPN or BD, and the packets label for each VPN or BD, and the packets transmitted using BIER
transmitted using BIER transport always carry the label that transport always carry the label that identifies their VPN or BD.
identifies their VPN or BD. (See [BIER-MVPN] and [BIER-EVPN] for the (See [RFC8556] and [I-D.ietf-bier-evpn] for the details.) In the
details.) In the remainder of this document, we will use the term remainder of this document, we will use the term "aggregate tunnels"
"aggregate tunnels" to include both P2MP tunnels and BIER transport. to include both P2MP tunnels and BIER transport.
When an egress PE receives a packet from an aggregate tunnel, it must When an egress PE receives a packet from an aggregate tunnel, it must
look at the upstream-assigned label carried by the packet, and must look at the upstream-assigned label carried by the packet, and must
interpret that label in the context of the ingress PE. Essentially, interpret that label in the context of the ingress PE. Essentially,
each ingress PE has its own "context label space" [RFC5331] from each ingress PE has its own "context label space" [RFC5331] from
which it allocates its upstream-assigned labels. When an egress PE which it allocates its upstream-assigned labels. When an egress PE
looks up the upstream-assigned label carried by a given packet, it looks up the upstream-assigned label carried by a given packet, it
looks it up in the context label space owned by the packet's ingress looks it up in the context label space owned by the packet's ingress
PE. How an egress PE identifies the ingress PE of a given packet PE. How an egress PE identifies the ingress PE of a given packet
depends on the tunnel type. depends on the tunnel type.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
The number of labels could be greatly reduced if a central authority The number of labels could be greatly reduced if a central authority
assigned a label to each VPN, BD, or ES, and if all PEs used that assigned a label to each VPN, BD, or ES, and if all PEs used that
same label to represent a given VPN , BD, or ES. Then the number of same label to represent a given VPN , BD, or ES. Then the number of
total number of labels needed would just be the sum of the number of total number of labels needed would just be the sum of the number of
VPNs, BD, and/or ESes. VPNs, BD, and/or ESes.
One method of achieving this is to reserve a portion of the label One method of achieving this is to reserve a portion of the label
space for assignment by a central authority. We refer to this space for assignment by a central authority. We refer to this
reserved portion as the "Domain-wide Common Block" (DCB) of labels. reserved portion as the "Domain-wide Common Block" (DCB) of labels.
This is analogous to the "Segment Routing Global Block" (SRGB) that This is analogous to the "Segment Routing Global Block" (SRGB) that
is described in [I-D.ietf-spring-segment-routing]. The DCB is taken is described in [RFC8402]. The DCB is taken from the same label
from the same label space that is used for downstream-assigned space that is used for downstream-assigned labels, but each PE would
labels, but each PE would know not to allocate local labels from that know not to allocate labels from that block for other purposes (e.g.,
space. A PE that is attached (via L3VPN VRF interfaces or EVPN as a local label or for SRGB). A PE that is attached (via L3VPN VRF
Access Circuits) would know by provisioning which label from the DCB interfaces or EVPN Access Circuits) would know by provisioning which
corresponds to which of its locally attached VPNs, BDs, or ESes. The label from the DCB corresponds to which of its locally attached VPNs,
definition of "domain" is loose - it simply includes all the routers BDs, or ESes. The definition of "domain" is loose - it simply
that share the same DCB. In this document, it includes all PEs of an includes all the routers that share the same DCB. In this document,
MVPN/EVPN network. (Though if tunnel segmentation [RFC 6514] is it only needs to includes all PEs of an MVPN/EVPN network. (Though
used, each segmentation region could have its own DCB. This will be if tunnel segmentation [RFC6514] is used, each segmentation region
explained in more detail later.) If these PEs share other common could have its own DCB. This will be explained in more detail
label blocks (e.g. SRGB) with other routers, the DCB MUST not later.)
intersect with those common label blocks or those routers MUST be The "domain" could also include all routers in the provider network,
considered as part of the "domain". However, the labels advertised making it not much different from a common SRGB across all the
by PEs for the purposes defined in this document will only rise to routers. However, that is not necessarily as the labels used by PEs
the top of the label stack when traffic arrives the PEs. for the purposes defined in this document will only rise to the top
of the label stack when traffic arrives the PEs. Therefore, it is
better to not include internal P routers in the "domain". That way
they do not have to aside the same DCB used for the purposes in this
document.
In some deployments, it may be impractical to allocate a DCB that is In some deployments, it may be impractical to allocate a DCB that is
large enough to contain labels for all the VPNs/BDs/ESes. In this large enough to contain labels for all the VPNs/BDs/ESes. In this
case, it may be necessary to allocate those labels from a context case, it may be necessary to allocate those labels from a context
label space. However, it is not necessary for each ingress PE to label space. However, it is not necessary for each ingress PE to
have its own context label space. Instead, one (or some small have its own context label space. Instead, one (or some small
number) of context label spaces can be dedicated to such labels. number) of context label spaces can be dedicated to such labels.
Each ingress PE would be provisioned to know both the context label Each ingress PE would be provisioned to know both the context label
space identifier and the label for each VPN/BD/ES. space identifier and the label for each VPN/BD/ES.
skipping to change at page 7, line 8 skipping to change at page 7, line 12
that these labels are upstream-assigned, from the label space used by that these labels are upstream-assigned, from the label space used by
the root node for its upstream-assigned labels. the root node for its upstream-assigned labels.
It is REQUIRED by this document that the PE Distinguisher labels It is REQUIRED by this document that the PE Distinguisher labels
allocated by a particular node come from the same source that the allocated by a particular node come from the same source that the
node uses to allocate its VPN-identifying labels. node uses to allocate its VPN-identifying labels.
2.2.2. Segmented Tunnels 2.2.2. Segmented Tunnels
There are some additional issues to be considered when MVPN or EVPN There are some additional issues to be considered when MVPN or EVPN
is using "tunnel segmentation" (see [RFC6514], [RFC7524], and [EVPN- is using "tunnel segmentation" (see [RFC6514], [RFC7524], and
BUM] Sections 5 and 6). [I-D.ietf-bess-evpn-bum-procedure-updates] Sections 5 and 6).
2.2.2.1. Selective Tunnels 2.2.2.1. Selective Tunnels
For "selective tunnels" (see [RFC6513] Sections 2.1.1 and 3.2.1, and For "selective tunnels" (see [RFC6513] Sections 2.1.1 and 3.2.1, and
[EVPN-BUM] Section 4), the procedures outlined above work only if [I-D.ietf-bess-evpn-bum-procedure-updates] Section 4), the procedures
tunnel segmentation is not used. outlined above work only if tunnel segmentation is not used.
A selective tunnel carries one or more particular sets of flows to a A selective tunnel carries one or more particular sets of flows to a
particular subset of the PEs that attach to a given VPN or BD. Each particular subset of the PEs that attach to a given VPN or BD. Each
set of flows is identified by a Selective PMSI A-D route [RFC6514]. set of flows is identified by a Selective PMSI A-D route [RFC6514].
The PTA of the S-PMSI route identifies the tunnel used to carry the The PTA of the S-PMSI route identifies the tunnel used to carry the
corresponding set of flows. Multiple S-PMSI routes can identify the corresponding set of flows. Multiple S-PMSI routes can identify the
same tunnel. same tunnel.
When tunnel segmentation is applied to a S-PMSI, certain nodes are When tunnel segmentation is applied to a S-PMSI, certain nodes are
"segmentation points". A segmentation point is a node at the "segmentation points". A segmentation point is a node at the
skipping to change at page 10, line 35 skipping to change at page 10, line 39
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/re-advertises an x-PMSI/IMET route, the route When a PE originates/re-advertises an x-PMSI/IMET route, the route
MUST carry a DCB-flag if and only if the label in its PTA is assigned MUST carry a DCB-flag if and only if the label in its PTA is assigned
from the DCB. from the DCB.
skipping to change at page 11, line 9 skipping to change at page 11, line 13
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 MUST program its default MPLS forwarding table to map the
in the EC that identifies the context label space to a corresponding label in the EC that identifies the context label space to a
context label table in which the next label lookup is done for corresponding context label table in which the next label lookup is
traffic that this PE receives. done for traffic that this PE receives.
The receiving PE then programs the label in the PTA or ESI Label EC Then, the receiving PE MUST program the label in the PTA or ESI Label
into either the default mpls forwarding table (if the route carries EC into either the default mpls forwarding table (if the route
the DCB-flag) or the context label table (if the Context Label Space carries the DCB-flag) or the context label table (if the Context
ID EC is present) according to the x-PMSI/IMET route. Label Space ID EC is present) according to the x-PMSI/IMET route.
A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and
attach the Context Label Space ID EC in the route. A PE MUST ignore attach the Context Label Space ID EC in the route. A PE MUST ignore
a received route with both the DCB-flag and the Context Label Space a received route with both the DCB-flag and the Context Label Space
ID EC attached. If neither the DCB-flag nor the Context Label Space ID EC attached, treating as if it was not received. If neither the
ID EC is attached, the label in the PTA or ESI Label EC is treated as DCB-flag nor the Context Label Space ID EC is attached, the label in
the upstream allocated from the source PE's label space, and the PTA or ESI Label EC MUST be treated as the upstream allocated
procedures in [RFC6514][RFC7432] must be followed. from the source PE's label space, and 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 interpret 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 DCB-flag, 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 DCB-flag, 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. Security Considerations
This document introduces a DCB-bit in the "Additional PMSI Tunnel This document allows three methods (Section 2.2.3) of label
Attribute Flags" BGP Extended Community. An IANA request will be allocation for MVPN/EVPN PEs and specifies corresponding signaling
submitted for the DCB-bit in the Additional PMSI Tunnel Attribute and procedures. The first method is the equivalent of using common
Flags registry. SRGBs from the regular per platform label space. The second one is
the equivalent of using common SRGBs from a third party's label
space, which is also considered as an upstream-assigned label
allocation [RFC5331]. The third method is is a variation of the
second, in that the third party's label space is divided into
disjoint blocks for use by different PEs, who will use labels from
their respective block to send traffic. In all cases, a receiving PE
is able to identify one of a few LFIBs to forward incoming labeled
traffic.
This document introduces a new Transitive Opaque Extended Community Therefore, this document does not introduce new security issues
"Context Label Space ID Extended Community". An IANA request will be besides what have been discussed in existing specifications [RFC5331]
submitted for a sub-type value in the BGP Transitive Opaque Extended [RFC6514] [RFC7432] [RFC8402].
Community Sub-Types registry.
5. Acknowledgements 5. IANA Considerations
6. Contributors IANA is requested for the following assignments:
o Bit 47 (DCB-Bit) from the "Additional PMSI Tunnel Attribute Flags"
registry
Bit Name Reference
---- ---------------------- -------------
47 DCB-bit This document
o Sub-type 0x08 for "Context Label Space ID Extended Community" from
the "Transitive Opaque Extended Community Sub-Types" registry
Bit Name Reference
---- ---------------------- -------------
0x08 Context Label Space ID This document
6. Acknowledgements
The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie
for their review of, comments on and suggestions for this document.
7. Contributors
The following also contributed to this document. The following also contributed to this document.
Selvakumar Sivaraj Selvakumar Sivaraj
Juniper Networks Juniper Networks
Email: ssivaraj@juniper.net Email: ssivaraj@juniper.net
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
skipping to change at page 13, line 14 skipping to change at page 13, line 48
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags", P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016, RFC 7902, DOI 10.17487/RFC7902, June 2016,
<https://www.rfc-editor.org/info/rfc7902>. <https://www.rfc-editor.org/info/rfc7902>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 8.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-08 (work in progress), bess-evpn-bum-procedure-updates-08 (work in progress),
November 2019. November 2019.
[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,
"EVPN BUM Using BIER", draft-ietf-bier-evpn-04 (work in "EVPN BUM Using BIER", draft-ietf-bier-evpn-04 (work in
progress), December 2020. progress), December 2020.
[I-D.ietf-bier-mvpn]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", draft-ietf-bier-
mvpn-11 (work in progress), March 2018.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, DOI 10.17487/RFC5331, August 2008, RFC 5331, DOI 10.17487/RFC5331, August 2008,
<https://www.rfc-editor.org/info/rfc5331>. <https://www.rfc-editor.org/info/rfc5331>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>.
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Eric Rosen Eric Rosen
Individual Individual
EMail: erosen52@gmail.com EMail: erosen52@gmail.com
Wen Lin Wen Lin
Juniper Networks Juniper Networks
EMail: wlin@juniper.net EMail: wlin@juniper.net
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
EMail: lizhenbin@huawei.com EMail: lizhenbin@huawei.com
 End of changes. 25 change blocks. 
81 lines changed or deleted 120 lines changed or added

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