idnits 2.17.1 draft-wang-bess-evpn-control-word-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group H. Wang 3 Internet-Draft D. Eastlake 4 Intended status: Experimental Huawei Technologies 5 Expires: April 25, 2019 October 22, 2018 7 EVPN ELAN use of Control Words 8 draft-wang-bess-evpn-control-word-00 10 Abstract 12 This document describes a method for negotiating and using EVPN 13 control words for ELAN service. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Control word Next-Hop Dependent Capability . . . . . . . . . 2 57 3. The Control Plane Process . . . . . . . . . . . . . . . . . . 3 58 4. The Data Plane Process . . . . . . . . . . . . . . . . . . . 3 59 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 66 1. Introduction 68 The usage of control words for Layer 2 services is described in RFC 69 7432 [RFC7432] and in some drafts on traditional VPLS but these 70 documents do not explain how to deploy and negotiate control words. 71 According to these documents, control words can only be used if all 72 devices have control words enabled. If one of the devices does not 73 have the control word enabled, that device cannot communicate with 74 the other devices. 76 RFC 8214 [RFC8214] defines the EVPN VPWS service and describes the 77 negotiation process for the use of control words. However, the 78 negotiation process described is only applicable to a P2P service 79 such as VPWS, and is not applicable to an MP2MP service such as VPLS. 81 This documents aims to define a control word negotiation and usage 82 mechanism in an EVPN ELAN scenario. 84 2. Control word Next-Hop Dependent Capability 86 The Control Word Next-Hop Capability has type code TBD and a length 87 of 0 or 3 octet. 89 The inclusion of the "Control word" Next-Hop Capability indicates 90 that the BGP Next-Hop can be sent packets, for all routes indicated 91 in the NRLI, with a control word added immediately after the label 92 stack advertised with the NLRI. 94 When the receiver receives a route that carries the capability, it 95 can decide whether to add the control word to the packet according to 96 its local capability. 98 3. The Control Plane Process 100 The egress router needs to use the control word indicator label to 101 determine whether there is a control word in the packet. 103 There are two methods to specified the control word indicator label: 105 The first method is to apply for a reserved label to indicate 106 whether the packet contains a control word; 108 The second method is to apply for a new label when the sending 109 router advertises the control word capability, which is used to 110 indicate whether the control word is included in the packet. 112 When the value of the control word capability length is 0, it means 113 we should use a reserved label as the control word indication label, 114 which needs be assigned by IANA. 116 If the value of the control word capability length is 3, the sending 117 router must apply a new label to act as the control word indication 118 label. 120 Either of the above two methods can be used, and the first method is 121 recommended. 123 4. The Data Plane Process 125 The ingress router receives the routes with the control word 126 capability attribute and, if the ingress router supports the control 127 word capability and allows the control word capability to be carried 128 when forwarding traffic to the egress router, a control word 129 indicator label is added at the label stacks' bottom and then a 130 4-byte control word is added. If the ingress router does not support 131 the control word capability or does not recognize the control word 132 capability, the ingress router maintains the message consistent with 133 the previous behavior when forwarding the packet to the egress 134 router. 136 When the egress router receives a packet from the MPLS network and 137 finds a control word indication label in the packet, it means that 138 the packet contains a control word, so the egress router does the 139 control word process. 141 5. Other Considerations 143 For the VXLAN and SRv6 networks, the current hash rule does not have 144 the problem of Layer 2 services in the MPLS network. Therefore, no 145 support is required. If the attribute is received, it can be 146 ignored. 148 6. IANA Considerations 150 TBD 152 7. Security Considerations 154 TBD 156 8. Acknowledgements 158 TBD 160 9. Normative References 162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, 164 DOI 10.17487/RFC2119, March 1997, 165 . 167 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 168 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 169 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 170 2015, . 172 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 173 Rabadan, "Virtual Private Wire Service Support in Ethernet 174 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 175 . 177 Authors' Addresses 179 Haibo (Rainsword) Wang 180 Huawei Technologies 181 Huawei Bld., No.156 Beiqing Road 182 Beijing 100085 183 China 185 Email: rainsword.wang@huawei.com 186 Donald Eastlake 3rd 187 Huawei Technologies 188 1424 Pro Shop Court 189 Davenport, FL 33896 190 USA 192 Phone: +1-508-333-2270 193 Email: d3e3e3@gmail.com