< draft-yu-bess-evpn-l2-attributes-04.txt   draft-yu-bess-evpn-l2-attributes-05.txt >
BESS Workgroup T. Yu, Ed. BESS Workgroup T. Yu, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track H. Wang Updates: RFC7432, RFC8214 (if approved) H. Wang
Expires: September 11, 2019 Huawei Technologies Intended status: Standards Track Huawei Technologies
March 10, 2019 Expires: October 5, 2019 April 3, 2019
Usage of Layer 2 Attributes Extended Community in EVPN Usage of Layer 2 Attributes Extended Community in EVPN
draft-yu-bess-evpn-l2-attributes-04 draft-yu-bess-evpn-l2-attributes-05
Abstract Abstract
This document adopts Layer 2 Attributes Extended Community defined in This document adopts Layer 2 Attributes Extended Community defined in
[RFC8214] to EVPN allowing signalling L2 information in control [RFC8214] to EVPN allowing negotiate Layer2 information in the
plane. control plane.
An interoperability mechanism of control word is described for EVPN An interoperability mechanism between PEs with and without control
and VPWS in this document. word capability is described for EVPN and VPWS in this document.
Also flow label signalling mechanism is described for EVPN and VPWS. Flow label signaling mechanism is also described for EVPN ELAN and
VPWS with interoperability capability considered.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 11, 2019. This Internet-Draft will expire on October 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 14 skipping to change at page 2, line 15
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . 3 2. Specification of Requirements . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. EVPN Layer 2 Attributes Extended Community . . . . . . . . . 3 4. EVPN Layer 2 Attributes Extended Community . . . . . . . . . 4
4.1. Control Flag Attribute . . . . . . . . . . . . . . . . . 4 4.1. Control Flag Attribute . . . . . . . . . . . . . . . . . 6
4.2. L2 MTU Attribute . . . . . . . . . . . . . . . . . . . . 6 4.2. L2 MTU Attribute . . . . . . . . . . . . . . . . . . . . 7
5. Control Word Indicator Extended Community . . . . . . . . . . 6 5. Control Word Indicator Extended Community . . . . . . . . . . 7
6. Usage of Control Word . . . . . . . . . . . . . . . . . . . . 7 6. Usage of Control Word . . . . . . . . . . . . . . . . . . . . 8
6.1. EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. EVPN ELAN . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.1. Deterministic mode . . . . . . . . . . . . . . . . . 7 6.1.1. Deterministic mode . . . . . . . . . . . . . . . . . 8
6.1.2. Interoperable mode . . . . . . . . . . . . . . . . . 7 6.1.2. Interoperable mode . . . . . . . . . . . . . . . . . 9
6.2. EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. EVPN VPWS . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Deterministic mode . . . . . . . . . . . . . . . . . 8 6.2.1. Deterministic mode . . . . . . . . . . . . . . . . . 9
6.2.2. Interoperable mode . . . . . . . . . . . . . . . . . 8 6.2.2. Interoperable mode . . . . . . . . . . . . . . . . . 9
7. Usage of Flow Label . . . . . . . . . . . . . . . . . . . . . 8 7. Usage of Flow Label . . . . . . . . . . . . . . . . . . . . . 10
8. Instructions on Using Control Word and Flow Label . . . . . . 9 8. Instructions on Using Control Word and Flow Label . . . . . . 10
9. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 9. Other Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Example of using Layer 2 Attributes Extended
Community . . . . . . . . . . . . . . . . . . . . . 13
A.1. Example 1: ELAN Control Word Deterministic mode . . . . . 13
A.2. Example 2: ELAN Control Word Interoperable mode . . . . . 13
A.3. Example 3: Usage of Flow Label . . . . . . . . . . . . . 14
A.4. Example 4: Combination of Control Word and Flow Label . . 14
A.5. Example 5: Combination of CW Interoperable mode and FL . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
EVPN [RFC7432] lacks of a negotiation mechanism on L2 capabilities. EVPN [RFC7432] lacks a negotiation mechanism on L2 capabilities.
Lacking of such capabilities will lead to malformed packets on Lacking such capabilities will lead to malformed packets on
forwarding plane without any prevention from control plane forwarding plane without any prevention from the control plane
signalling. [RFC8214] defines Layer 2 Attributes Extended Community signaling. Issues caused due to mismatch of Layer 2 capabilities are
but there is no defination on how it can used in EVPN ELAN. This listed below:
document aims to describe how Layer 2 Attributes Extended Community
to be used in EVPN ELAN.
To achieve better load balancing on EVPN ELAN and VPWS services, flow o Mismatching of MTU across interfaces attached within one EVPN ELAN
label function in EVPN is described in this document. or VPWS leads to consistent packet loss on the interface with
smaller MTU than the other interfaces, due to fragmentation is not
possible in the Layer 2 network.
o Mismatching of control word enable status between PEs within the
same EVPN ELAN or VPWS leads to control word being treated as
payload of the EVPN instead of being stripped off.
[RFC8214] defines Layer 2 Attributes Extended Community but there is
no definition on how it is used in EVPN ELAN.
There are scenarios that PEs are deployed in a mixed environment
where some PEs support Control Word but others not. The behavior and
interoperate mechanism of such scenario is needed.
There is also a requirement on flow label capability on EVPN ELAN and
VPWS in absence of entropy label. The signaling capability of flow
label on the control plane is also necessary.
In summary, this document aims to describe how Layer 2 Attributes
Extended Community to be used in EVPN ELAN, with targets listed
below:
o MTU consistency validation for EVPN ELAN.
o CW (Control Word) consistency validation for EVPN ELAN.
o Introduce a CW interoperate mechanism in case not all devices
within the EVPN ELAN or VPWS support Control Word.
o Introduce flow label signaling mechanism allowing EVPN ELAN and
VPWS to achieve better load balancing, with interoperability
capability considered.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432]. EVPN: BGP MPLS-Based Ethernet VPN defined in [RFC7432].
EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN specifies EVPN ELAN: In order to distinguish EVPN VPWS, EVPN ELAN specifies
EVPN defined in [RFC7432]. EVPN defined in [RFC7432].
EVI: An EVPN Instance spanning the Provider Edge (PE) devices EVI: An EVPN ELAN Instance.
participating in that EVPN ELAN.
EVPN VPWS: EVPN Virtual Private Wire Service, refers to [RFC8214]. EVPN VPWS: EVPN Virtual Private Wire Service, refers to [RFC8214].
EVPN E-Tree: Ethernet VPN Ethernet-Tree defined in [RFC8317]. EVPN E-Tree: Ethernet VPN Ethernet-Tree defined in [RFC8317].
CW: Control Word defined in [RFC4448]. CW: Control Word defined in [RFC4448].
CI: Control Word Indicator, defined in Section 4 of this document. CI: Control Word Indicator, defined in Section 4 of this document.
PE: Provider Edge device. PE: Provider Edge device.
FL: Flow-Aware Transport Label, defined in [RFC6391]. FL: Flow-Aware Transport Label, defined in [RFC6391].
BUM: Broadbast, Unknown-Unicast, Multicast. BUM: Broadcast, Unknown-Unicast, Multicast.
P2MP: Point to Multi-Point. P2MP: Point to Multi-Point.
MP2P: Multi-Point to Point. MP2P: Multi-Point to Point.
MP2MP: Multi-Point to Multi-Point.
LSP: Label-Switched Path. LSP: Label-Switched Path.
EAD Route: Ethernet Auto-discovery Route Route defined in [RFC7432].
IMET Route: Inclusive Multicast Ethernet Tag Route defined in
[RFC7432].
BoS: Bottom-of-Stack.
4. EVPN Layer 2 Attributes Extended Community 4. EVPN Layer 2 Attributes Extended Community
The definition of EVPN Layer 2 Attributes Extended Community is same The definition of EVPN Layer 2 Attributes Extended Community is the
with [RFC8214]. it is listed as below for convenience. same with [RFC8214]. it is listed as below for convenience.
+-------------------------------------------+ +-------------------------------------------+
| Type (0x06) / Sub-type (0x04) (2 octets) | | Type (0x06) / Sub-type (0x04) (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
| Control Flags (2 octets) | | Control Flags (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
| L2 MTU (2 octets) | | L2 MTU (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
| Reserved (2 octets) | | Reserved (2 octets) |
+-------------------------------------------+ +-------------------------------------------+
Figure 1: EVPN Layer 2 Attributes Extended Community Figure 1: EVPN Layer 2 Attributes Extended Community
Layer 2 Attributes Extended Community SHOULD be included in Ethernet Layer 2 Attributes Extended Community SHOULD be included in Ethernet
Auto-discovery Route route and Inclusive Multicast Ethernet Tag Auto-discovery Route route and Inclusive Multicast Ethernet Tag
Route. Route. Layer 2 Attributes Extended Community is necessary for per
Ethernet Segment based EAD (section 8.2.1 of [RFC7432]) and optional
for per EVPN instance based EAD (section 8.4.1 of [RFC7432]).
For a single-homed ES in ELAN, the Layer 2 Attributes Extended
Community is advertised along with a per EVI based EAD route with an
all-zero ESI and a set of RTs corresponding to the EVI on the PE.
This updates the behavior defined in section 8.2.1 of [RFC7432],
which says "The Ethernet A-D route is not needed when the Segment
Identifier is set to 0".
For an EVPN ELAN, Layer 2 Attributes Extended Community included in For an EVPN ELAN, Layer 2 Attributes Extended Community included in
Auto-discovery route applies to unicast traffic and Inclusive EAD route applies to unicast traffic and IMET Route applies to BUM
Multicast Ethernet Tag Route applies to BUM traffic. traffic.
Layer 2 Attributes Extended Community for unicast MUST be same across Layer 2 Attributes Extended Community for unicast SHOULD be same
all Ethernet Segments in Auto-discovery routes within one EVI on a across all Ethernet Segments in EAD routes within one EVI on a local
local PE when used in EVPN ELAN. Layer 2 Attributes Extended PE when used in EVPN ELAN.
Community for BUM MUST be same across EVIs sharing the same P-Tunnel
within a PE. Layer 2 Attributes Extended Community MAY be different
between Auto-discovery route and Inclusive Multicast Ethernet Tag
Route.
When a PE recieves routes without L2 Attributes Extended Community, Layer 2 Attributes Extended Community for BUM SHOULD be same across
local PE SHOULD assume the values of Layer 2 Attributes Extended EVIs in IMET route sharing the same P-Tunnel within a PE.
Any inconsistency on L2 Attributes Extended Community of interfaces
attached to the same EVI (EAD route) MUST or EVIs sharing same
P-tunnel (IMET route) SHOULD be resolved before the corresponding
route being advertised.
Layer 2 Attributes Extended Community MAY be different between EAD
route and IMET Route for one EVI. For example, EAD route advertises
control word capability but IMET route advertises no control word
capability. This means, the validation of Layer 2 Attributes
Extended Community in EAD and IMET route are independent.
When a PE receives routes without L2 Attributes Extended Community,
the local PE SHOULD assume the values of Layer 2 Attributes Extended
Community of all corresponding PEs are same with local. This allows Community of all corresponding PEs are same with local. This allows
backward compatibility of introducing L2 Attributes Extended backward compatibility of introducing L2 Attributes Extended
Community into EVPN ELAN. Community into EVPN ELAN.
If a local PE does not support EVPN Layer 2 Attributes Extended If a local PE does not support EVPN Layer 2 Attributes Extended
Community, this community MUST be ignored. Community, this community MUST be ignored.
4.1. Control Flag Attribute 4.1. Control Flag Attribute
The definition of Control Flags is as below: The definition of Control Flags is as below:
skipping to change at page 5, line 4 skipping to change at page 6, line 24
4.1. Control Flag Attribute 4.1. Control Flag Attribute
The definition of Control Flags is as below: The definition of Control Flags is as below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+
| MBZ |CI|F|C|P|B| (MBZ = MUST Be Zero) | MBZ |CI|F|C|P|B| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+
Figure 2: Control Flags in EVPN Layer 2 Attributes Extended Community Figure 2: Control Flags in EVPN Layer 2 Attributes Extended Community
The P bit and B bit defined in [RFC8214] must be zero when used in The P bit and B bit defined in [RFC8214] must be zero when used in
EVPN ELAN mode. This is because [RFC7432] has defined ESI Label EVPN ELAN mode.
Extended Community to achieve single-active redundancy mode.
C bit indicates the control word enable status: C bit indicates the control word enable status:
o When C bit is set to 1, the PE announces it has the capability of o When C bit is set to 1, the PE announces it has the capability of
both sending and receiving CW. both sending and receiving CW.
o C bit MUST set 0 if PE has no capability of sending or receiving o C bit MUST set 0 if PE has no capability of sending or receiving
control word. control word.
o C bit SHOULD not set 1 if Layer 2 Attributes Extended Community is o C bit SHOULD not set 1 if Layer 2 Attributes Extended Community is
used on P2MP or MP2MP LSPs. used in IMET route for P2MP or MP2MP LSPs.
F bit is defined to achieve flow label signalling capability in EVPN: F bit is defined to achieve flow label signaling capability in EVPN:
o When F bit is set to 1, the PE announces it has the capability of o When F bit is set to 1, the PE announces it has the capability of
both sending and receiving flow label. both sending and receiving flow label.
o F bit MUST set 0 if PE has no capability of sending or receiving o F bit MUST set 0 if PE has no capability of sending or receiving
flow label. flow label.
o F bit SHOULD not set 1 if Layer 2 Attributes Extended Community is o F bit SHOULD not set 1 if Layer 2 Attributes Extended Community is
used on P2MP or MP2MP LSPs. used in IMET route for P2MP or MP2MP LSPs.
CI bit is defined to achieve interoperability between devices with CI bit is defined to achieve interoperability between devices with
and without control word capability. Control Word Indicator is a and without control word capability. Control Word Indicator is a
MPLS label. CI bit MUST NOT set 1 if C bit is set 0. MPLS label. CI bit MUST NOT set 1 if C bit is set 0. The target of
CI is to allow equipments with CW capability and a higher level of
programmability to be able to communicate together with equipments
has and does not have CW capability together in an MP2MP ELAN
network.
CI label MUST NOT be a MPLS reserved label [RFC3032], MUST be with CI label MUST NOT be a MPLS reserved label [RFC3032], MUST be with
TTL=1 and MUST be Bottom-of-Stack. CI label MUST NOT be used to TTL=1. CI label MUST NOT be used to direct forwarding behavior in
direct forwarding behavior in any cases. any cases.
When a PE sends packets with CI label, it MUST keep value CI labels When a PE sends packets with CI label, it MUST keep value CI labels
consistent for traffic towards the same ES. Due to CI usage is to consistent for traffic towards the same ES.
indicate the existance of CW and will never direct fowarding, CI MPLS
label can be any none-reserved MPLS label.
There are two ways of filling CWI label value: There are two ways of filling CWI label value:
o Use the label value advertised in Control Word Indicator Extended o Use the label value advertised in Control Word Indicator Extended
Community (refer to section 5). Community (refer to section 5).
o In case absense of Control Word Indicator Extended Community, EVPN o In case absence of Control Word Indicator Extended Community, EVPN
service label MAY be copied into CWI. service label MAY be copied into CWI.
The usage of CI bit is described in Section 6. The usage of CI bit is described in Section 6.
Other bits in Control Flag are reserved for future investigation and Other bits in Control Flag are reserved for future investigation and
MUST be zero. MUST be zero.
When a PE receives Auto-discovery routes with C or F bit enabled, the When a PE receives Auto-discovery routes with C or F bit enabled, the
behavior SHOULD be spread to all MAC tables towards the corresponding behavior SHOULD be spread to all MAC tables towards the corresponding
ES. ES.
4.2. L2 MTU Attribute 4.2. L2 MTU Attribute
L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes. If L2 MTU is a 2-octet value indicating the CE-PE link MTU in bytes. If
a non-zero MTU attribute is received, it MUST be checked against a non-zero MTU attribute is received, it MUST be checked against
local MTU value if the local value is not zero. If there is a local MTU value if the local value is not zero. If there is a
mismatch, the local PE MUST NOT add the remote PE as the EVPN ELAN or mismatch, the local PE SHOULD NOT add the remote PE as the EVPN ELAN
VPWS destination. or VPWS destination. The process described is applicable to both EAD
and IMET routes.
5. Control Word Indicator Extended Community 5. Control Word Indicator Extended Community
This extended community is a new transitive extended community having This extended community is a new transitive extended community having
a Type field value of 0x06 (EVPN) and the Sub-Type TBD. It is used a Type field value of 0x06 (EVPN) and the Sub-Type TBD. It is used
for Control Word Indicator of known unicast and BUM traffic. It to indicate that the frame contains a CW after MPLS Bottom-of-Stack.
indicates that the frame contains a CW after MPLS Bottom-of-Stack.
This extended community MAY be advertised along Ethernet Auto- This extended community MAY be advertised along Ethernet Auto-
discovery Route route and Inclusive Multicast Ethernet Tag Route when discovery Route route and Inclusive Multicast Ethernet Tag Route when
CI bit is 1 in EVPN Layer 2 Attributes Extended Community. When a PE CI bit is 1 in EVPN Layer 2 Attributes Extended Community.
advertising the communnity, it MUST ensure CWI label same across
Ethernet Segments within one EVI and EVIs sharing the same P-Tunnel. When a PE advertising the community, it MUST ensure value of CWI
CI label value advertised SHOULD NOT be same with EVPN service label same across Ethernet Segments within one EVI in EAD route and
lables. Control Word Indicator Extended Community MUST NOT be EVIs sharing the same P-Tunnel in IMET route. CI label value
included if CI is 0. advertised SHOULD NOT be same with EVPN service labels. Control Word
Indicator Extended Community MUST NOT be included if CI is 0.
If a PE contains Control Word Indicator Extended Community when If a PE contains Control Word Indicator Extended Community when
establishing the MP2P LSP, when receiving packets from MP2P LSP, it establishing the MP2P LSP, when receiving packets from MP2P LSP, it
uses the CI label value been advertised to identify existance of CW. uses the CI label value been advertised to identify existence of CW.
If a PE does not contain Control Word Indicator Extended Community If a PE does not contain Control Word Indicator Extended Community
when establishing the MP2P LSP, it relies on the MPLS Bottom-of-Stack when establishing the MP2P LSP, it relies on the MPLS Bottom-of-Stack
bit to identify existance of CW. bit to identify existence of CW.
When CI bit and F bit set 1 together, Control Word Indicator Extended When CI bit and F bit set 1 together, Control Word Indicator Extended
Community MUST be included. The packet encapulation from ingress PE Community MUST be included. The packet encapsulation from ingress PE
is: transport label(s) + EVPN service label(s) + FL + CI + CW + is: transport label(s) + EVPN service label(s) + CI + FL (BoS) + CW +
payload. Forwarding plane on egress PE MUST use CI value in the payload. Forwarding plane on egress PE MUST use CI value in the
extended community to identify CW and identify FL in between if extended community to identify CW and identify FL in between if
exits. When working in such mode, source PE MUST ensure FL value exits. When working in such mode, source PE MUST ensure FL value
calaulated locally does not equal CI value learnt from EVPN routes. calculated locally does not equal CI value learnt from EVPN routes.
0 1 2 3 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 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 | Flags(1 Octet)| Reserved=0 | | Type=0x06 | Sub-Type=TBD | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | CI Label | | Reserved=0 | CI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Control Word Indicator Extended Community Figure 3: Control Word Indicator Extended Community
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |C| (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
Figure 4: Flags in Control Word Indicator Extended Community
6. Usage of Control Word 6. Usage of Control Word
6.1. EVPN ELAN 6.1. EVPN ELAN
6.1.1. Deterministic mode 6.1.1. Deterministic mode
PE advertises CW local enable status via Layer 2 Attributes Extended PE advertises CW local enable status via Layer 2 Attributes Extended
Community. A validation procedure is added in procedure of Auto- Community. A validation procedure is added in procedure of Auto-
discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit
status in L2 attribute of recieved routes are same with local statue, status in L2 attribute of received routes are same with local statue,
the recieved routes are treated valid. CI bit is not used in this the received routes are treated valid. CI bit is not used in this
mode. mode.
6.1.2. Interoperable mode 6.1.2. Interoperable mode
1. Disable CW function on all devices and keep CW status consistent 1. Disable CW function on all devices and keep CW status consistent
within EVI, then the EVI can work in the deterministic mode. within EVI, then the EVI can work in the deterministic mode.
2. An interoperable mode based on CI MAY be implemented to achieve 2. An interoperable mode based on CI MAY be implemented to achieve
interoperability with such devices. interoperability with such devices.
skipping to change at page 8, line 7 skipping to change at page 9, line 26
CI is introduced to allow a PE identifying CW status on forwarding CI is introduced to allow a PE identifying CW status on forwarding
plane. plane.
When an EVPN ELAN working in interoperable mode, if CW on a PE is When an EVPN ELAN working in interoperable mode, if CW on a PE is
enabled, the PE MUST set both C and CI bit = 1. If CW on a PE is enabled, the PE MUST set both C and CI bit = 1. If CW on a PE is
disabled or the PE is not capable to add CW, the PE MUST set both C disabled or the PE is not capable to add CW, the PE MUST set both C
and CI bit = 0. and CI bit = 0.
In this mode, A validation procedure is added in procedure of Auto- In this mode, A validation procedure is added in procedure of Auto-
discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit discovery and Inclusive Multicast Ethernet Tag Route. Only if C bit
= CI bit in L2 attribute of recieved routes, recieved routes are = CI bit in L2 attribute of received routes, received routes are
treated valid. treated valid.
With such procedure, an egress PE is able to identify existance of CW With such procedure, an egress PE is able to identify existence of CW
on fowarding plane via CI for packets recieved from MP2P LSP. on forwarding plane via CI for packets received from MP2P LSP.
6.2. EVPN VPWS 6.2. EVPN VPWS
6.2.1. Deterministic mode 6.2.1. Deterministic mode
When an EVPN VPWS working in deterministic mode, each PE advertises When an EVPN VPWS working in deterministic mode, each PE advertises
CW capability based on local status in Auto-discovery route via l2 CW capability based on local status in Auto-discovery route via l2
attribute. After a PE receives EVPN Auto-discovery route, it attribute. After a PE receives EVPN Auto-discovery route, it
compares the value of C bit with local control word enable status. compares the value of C bit with local control word enable status.
If not same, local PE MUST NOT bring up the EVPN VPWS. If not same, local PE MUST NOT bring up the EVPN VPWS.
skipping to change at page 8, line 36 skipping to change at page 10, line 6
there are two ways to interoperate such devices: there are two ways to interoperate such devices:
1. Disable CW function on PE1 and keep CW status consistent within 1. Disable CW function on PE1 and keep CW status consistent within
EVPN VPWS towards PE3, then the EVPN VPWS can work in the EVPN VPWS towards PE3, then the EVPN VPWS can work in the
deterministic mode. deterministic mode.
2. An interoperable mode MAY be implemented to achieve 2. An interoperable mode MAY be implemented to achieve
interoperability with such devices. interoperability with such devices.
When an EVPN VPWS working in interoperable mode, in case of C bit When an EVPN VPWS working in interoperable mode, in case of C bit
status is not consistent on both ends, VPWS MUST tear up. status is not consistent on both ends, VPWS MUST tear up with control
word disabled on both ends.
When working in interoperable mode, impact of lacking complete CW When working in interoperable mode, impact of lacking complete CW
between PEs SHOULD be evaluated based on section 8 of this document. between PEs SHOULD be evaluated based on section 8 of this document.
7. Usage of Flow Label 7. Usage of Flow Label
PE advertises FL local enable status via Layer 2 Attributes Extended PE advertises FL local enable status via Layer 2 Attributes Extended
Community. Different from CW, flow label signalling on control plane Community. Different from CW, flow label signaling on control plane
uses a loose validation procedure, which means FL status in received uses a loose validation procedure, which means FL status in received
routes MAY be different from local. routes MAY be different from local.
For MP2P LSP, when sending packet towards remote PE, FL is added if For MP2P LSP, when sending packet towards remote PE, FL is added if
both local and remote PEs are enabled. If a PE has no FL capability, both local and remote PEs are enabled. If a PE has no FL capability,
it will not receive packets with FL from MP2P LSP as all source PEs it will not receive packets with FL from MP2P LSP as all source PEs
will not send packets with FL towards this PE. If a PE has FL will not send packets with FL towards this PE. If a PE has FL
capability, it MAY receive packets with and without FL from MP2P LSP capability, it MAY receive packets with and without FL from MP2P LSP
as source PEs MAY have or haven't FL capability. In such case, the as source PEs MAY have or haven't FL capability. In such case, the
PE SHOULD treat packet without FL valid on forwarding plane even PE SHOULD treat packet without FL valid on forwarding plane even
though local FL status is enabled. MPLS Bottom-of-Stack bit is used though local FL status is enabled. MPLS Bottom-of-Stack bit is used
to identify whether FL is containted in the packets. to identify whether FL is contained in the packets.
The flow label mechanism described above is applicable to both EVPN The flow label mechanism described above is applicable to both EVPN
ELAN, E-Tree and EVPN VPWS. ELAN, E-Tree and EVPN VPWS.
8. Instructions on Using Control Word and Flow Label 8. Instructions on Using Control Word and Flow Label
In EVPN, CW is used avoid misordering caused by transit node using In EVPN, CW is used to avoid misordering caused by transit node using
MPLS payload as hash factor. The detailed reason for this refers to MPLS payload as hash factor. The detailed reason for this refers to
[RFC8469]. CW is mandatory for an EVPN carrying misordering [RFC8469]. CW is mandatory for an EVPN carrying misordering
sensitive service, when CW is not available, mitigations described in sensitive service, when CW is not available, mitigations described in
section 6 of [RFC8469] also apply to EVPN. section 6 of [RFC8469] also apply to EVPN.
Flow Label MAY be used to achieve better load-balancing in network, Flow Label MAY be used to achieve better load-balancing in network,
when transit node has no capability to look inside MPLS payload as when transit node has no capability to look inside MPLS payload as
hash factor. hash factor.
It has been recognized that some transit nodes treat payload after It has been recognized that some transit nodes treat payload after
skipping to change at page 9, line 36 skipping to change at page 11, line 11
it is bearing services sensitive to misordering, such load balancing it is bearing services sensitive to misordering, such load balancing
function SHOULD be disabled, otherwise control word will be treated function SHOULD be disabled, otherwise control word will be treated
as part of MAC address mistakenly. as part of MAC address mistakenly.
9. Other Considerations 9. Other Considerations
When data plane is not using MPLS, C, F and CI bits in control flags When data plane is not using MPLS, C, F and CI bits in control flags
MUST be 0. Control word and Flow Label are only applicable to MPLS MUST be 0. Control word and Flow Label are only applicable to MPLS
data plane. data plane.
10. Security Considerations 10. Acknowledgements
TBD
11. Security Considerations
This document updates the behavior specified in [RFC7432] and This document updates the behavior specified in [RFC7432] and
[RFC8214]. The security considerations listed in these two documents [RFC8214]. The security considerations listed in these two documents
apply. However, there are no new security considerations due to the apply. However, there are no new security considerations due to the
text of this document. text of this document.
11. IANA Considerations 12. IANA Considerations
IANA is requested to allocate a new "EVPN Extended Community Sub- IANA is requested to allocate a new "EVPN Extended Community Sub-
Types" registry defined in [RFC7153] as follow: Types" registry defined in [RFC7153] as follow:
SUB-TYPE VALUE NAME Reference SUB-TYPE NAME Reference
-------------------------------------------------------------------
------------------------------------------------------------------- TBD Control Word Indicator Extended Community This document
TBD Control Word Indicator Extended Community This document
12. References 13. References
12.1. Normative References 13.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>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>. 2015, <https://www.rfc-editor.org/info/rfc7432>.
skipping to change at page 10, line 40 skipping to change at page 12, line 16
Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree) Boutros, S., and J. Rabadan, "Ethernet-Tree (E-Tree)
Support in Ethernet VPN (EVPN) and Provider Backbone Support in Ethernet VPN (EVPN) and Provider Backbone
Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317, Bridging EVPN (PBB-EVPN)", RFC 8317, DOI 10.17487/RFC8317,
January 2018, <https://www.rfc-editor.org/info/rfc8317>. January 2018, <https://www.rfc-editor.org/info/rfc8317>.
[RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to [RFC8469] Bryant, S., Malis, A., and I. Bagdonas, "Recommendation to
Use the Ethernet Control Word", RFC 8469, Use the Ethernet Control Word", RFC 8469,
DOI 10.17487/RFC8469, November 2018, DOI 10.17487/RFC8469, November 2018,
<https://www.rfc-editor.org/info/rfc8469>. <https://www.rfc-editor.org/info/rfc8469>.
12.2. Informative References 13.2. Informative References
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>. <https://www.rfc-editor.org/info/rfc4448>.
skipping to change at page 11, line 16 skipping to change at page 13, line 5
Regan, J., and S. Amante, "Flow-Aware Transport of Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network", Pseudowires over an MPLS Packet Switched Network",
RFC 6391, DOI 10.17487/RFC6391, November 2011, RFC 6391, DOI 10.17487/RFC6391, November 2011,
<https://www.rfc-editor.org/info/rfc6391>. <https://www.rfc-editor.org/info/rfc6391>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
Appendix A. Example of using Layer 2 Attributes Extended Community
The procedures described below are applicable to both EAD and IMET
routes, if the applicable route is not explicitly specified.
A.1. Example 1: ELAN Control Word Deterministic mode
Assume PE1 and PE2 have CW capability and announce C=1, PE3 has no CW
capability and announces C=0. When working in control word
deterministic mode, CI is announced with 0.
After validation of Layer2 Attribute Extended community, PE1 and PE2
treat each other as valid destination, and PE3 as invalid
destination.
Packet encapsulation is as below:
o PE1 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE2
o PE1 <-- Not allowed --> PE3
o PE2 <-- Not allowed --> PE3
A.2. Example 2: ELAN Control Word Interoperable mode
Assume PE1 and PE2 have CW capability and announce C=1, CI=1, PE3 has
no CW capability and announces C=0 and CI=0.
After validation of Layer2 Attribute Extended community, PE1, PE2 and
PE3 treat each other as valid destination.
Packet encapsulation is as below:
o PE1 <-- Transport label(s) + EVPN label(s) + CI (BoS) + CW +
Payload --> PE2
o PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
In this scenario, CI label can be either the EVPL label closest to
the BoS, or signaled via Control Word Indicator Extended Community.
existence of CI can be identified via EVPN labels not being BoS or CI
label being advertised.
A.3. Example 3: Usage of Flow Label
Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL
capability and announces F=0. Assume control word of PE1, PE2 and
PE3 are disabled and C=0.
After validation of Layer2 Attribute Extended community, PE1, PE2 and
PE3 treat each other as valid destination.
Packet encapsulation is as below:
o PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + Payload
--> PE2
o PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
A.4. Example 4: Combination of Control Word and Flow Label
Considering it is possible that transit node looks into flow label
(BoS), parse the first nibble of payload wrongly and lead to
misordering, control word mechanism is still applicable when flow
label being used.
Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL
capability and announces F=0. Assume control word of PE1, PE2 and
PE3 are enabled and C=1.
After validation of Layer2 Attribute Extended community, PE1, PE2 and
PE3 treat each other as valid destination.
Packet encapsulation is as below:
o PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + CW +
Payload --> PE2
o PE1 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE3
o PE2 <-- Transport label(s) + EVPN label(s) + CW + Payload --> PE3
A.5. Example 5: Combination of CW Interoperable mode and FL
Assume PE1 and PE2 have FL capability and announce F=1, PE3 has no FL
capability and announces F=0. Assume control word of PE1 and PE2 are
enabled and C=1, CI=1, control word of PE3 is disabled and C=0 CI=0.
After validation of Layer2 Attribute Extended community, PE1, PE2 and
PE3 treat each other as valid destination.
Packet encapsulation is as below:
o PE1 <-- Transport label(s) + EVPN label(s) + CI + FL (BoS) + CW +
Payload --> PE2
o PE1 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
In this scenario, when F=1 and CI=1, value of CI MUST be signaled via
Control Word Indicator Extended Community. existence of CI is
identified via CI value being advertised instead of BoS. existence of
FL is identified via CI not being BoS.
Another possibility is: PE1 and PE2 announce F=1, PE3 announces F=0.
PE1 and PE3 announce C=1 and CI=1, PE2 announces C=0.
After validation of Layer2 Attribute Extended community, PE1, PE2 and
PE3 treat each other as valid destination.
Packet encapsulation is as below:
o PE1 <-- Transport label(s) + EVPN label(s) + FL (BoS) + Payload
--> PE2
o PE1 <-- Transport label(s) + EVPN label(s) + CI (BoS) + CW +
Payload --> PE3
o PE2 <-- Transport label(s) + EVPN label(s) + Payload --> PE3
In this scenario, when F=1 and CI=1 on PE1, value of CI on PE1 MUST
be signaled via Control Word Indicator Extended Community. existence
of CI is identified via CI value being advertised instead of BoS.
Authors' Addresses Authors' Addresses
Tianpeng Yu (editor) Tianpeng Yu (editor)
EMail: yutianpeng.ietf@gmail.com EMail: yutianpeng.ietf@gmail.com
Haibo Wang Haibo Wang
Huawei Technologies Huawei Technologies
EMail: rainsword.wang@huawei.com EMail: rainsword.wang@huawei.com
 End of changes. 49 change blocks. 
108 lines changed or deleted 303 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/