idnits 2.17.00 (12 Aug 2021) /tmp/idnits6498/draft-wu-idr-flowspec-rpd-impl-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 date (March 15, 2016) is 2258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-idr-registered-wide-bgp-communities' is defined on line 222, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-idr-wide-bgp-communities-01 == Outdated reference: A later version (-05) exists of draft-li-idr-flowspec-rpd-01 == Outdated reference: A later version (-02) exists of draft-ietf-idr-registered-wide-bgp-communities-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Wu 3 Internet-Draft S. Devadiga 4 Intended status: Informational Huawei 5 Expires: September 16, 2016 March 15, 2016 7 Implementation Report for BGP FlowSpec RPD 8 draft-wu-idr-flowspec-rpd-impl-00 10 Abstract 12 BGP FlowSpec Extensions for Routing Policy Distribution (RPD) has 13 provided a mechanism to use BGP Flowspec address family as routing- 14 policy distribution protocol. 16 This document provides an implementation report for RPD mechanism on 17 inbound-traffic and outbound-traffic adjustment scenarios. What's 18 more, it gives some details and consideration for exceptions during 19 development and verification. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 16, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Implementation Detail . . . . . . . . . . . . . . . . . . . . 2 63 2.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.3. Platforms . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Exception Consideration . . . . . . . . . . . . . . . . . . . 3 67 3.1. Transitive Wide Community . . . . . . . . . . . . . . . . 4 68 3.2. Unnecessary Flowspec Population . . . . . . . . . . . . . 4 69 3.3. Network Route Selection . . . . . . . . . . . . . . . . . 4 70 4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 8.2. Informative References . . . . . . . . . . . . . . . . . 5 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 79 1. Introduction 81 To facilitate the traffic optimization in a traditional IP network, 82 an automatic mechanism called BGP Flowspec RPD 83 [I-D.li-idr-flowspec-rpd] is introduced. This document provides an 84 implementation report for this RPD mechanism on inbound-traffic and 85 outbound-traffic adjustment scenarios. What's more, it gives some 86 details and consideration for exceptions during development and 87 verification. 89 2. Implementation Detail 91 2.1. Roles 93 o Policy Makers: sender, encode and populate BGP Flowspec routes 94 based on policies input from manual configuration or automatic 95 generated rules. 97 o Routers: receiver, decode BGP Flowspec routes from Policy Makers 98 and behave accordingly. 100 2.2. Features 102 o FlowSpec Traffic Actions, covered section 5.1 of 103 [I-D.li-idr-flowspec-rpd]. 105 o BGP Policy Attribute, NOT covered section 5.2 of 106 [I-D.li-idr-flowspec-rpd]. 108 o BGP Wide Community, covered section 5.3 of 109 [I-D.li-idr-flowspec-rpd]. 111 o Capability Negotiation, covered section 5.4 of 112 [I-D.li-idr-flowspec-rpd]. 114 2.3. Platforms 116 o VRP 118 * Release: VRPV800R010C00 120 * Vendor: Huawei 122 * Role: Router 124 * Contact: Eric Wu, Shankara 126 * Email: eric.wu@huawei.com, shankara@huawei.com 128 o SNC 130 * Release: SNCV100R001C50 132 * Vendor: Huawei 134 * Role: Policy Maker 136 * Contact: Eric Wu, Shankara 138 * Email: eric.wu@huawei.com, shankara@huawei.com 140 3. Exception Consideration 141 3.1. Transitive Wide Community 143 As specified in [I-D.ietf-idr-wide-bgp-communities], "The Wide BGP 144 Community Attribute is an optional, transitive BGP attribute, and may 145 be present only once in the BGP UPDATE message." In RPD's cases, the 146 policy maker can only have access to those routers in its domain. 147 And it is unnecessary and not safe for the border routers(IGW) to 148 populate RPD route(BGP Flowspec) into another AS. In our 149 implementation, a "NO_ADVERTISE" community is attached by the policy 150 maker to make sure that. So in RPD's cases the wide community will 151 not be "transitive" even when the Flowspec Address Family has been 152 enabled on the inter-AS session. 154 3.2. Unnecessary Flowspec Population 156 In RPD's cases, all border routers (IGW) will get BGP Flowspec routes 157 update from the policy maker even though only one of them is the real 158 receiver. Because of BGP's P2MP route population style, IGWs will 159 receive unnecessary updates which will consume extra resource to 160 maintain them. In our implementation, more information is attached 161 with routes to identify who is the corresponding executor. Better 162 solution SHOULD be sending the route to the real receiver only. 164 3.3. Network Route Selection 166 RPD mechanism changes traffic behavior through affecting the decision 167 in control plane. In both inbound and outbound scenarios, those 168 newly preferred routes will be propagated to other BGP peers, which 169 may impact route selection of the whole network in the end. Even 170 though this is the basic protocol behavior, it may generate 171 unexpected consequence on network forwarding. Better solution SHOULD 172 consider how to eliminate this negative impact. 174 4. Future Work 176 1. More platform. More implementation will be available on 177 different platforms, including open source. 179 2. Interoperability. Plan to do interoperation test on different 180 platforms when they are ready. 182 3. Operator Deployment. Operators are interested in testing and 183 deploy RPD mechanism. Deployment report may be available in 184 future. 186 5. IANA Considerations 188 This draft has no request to IANA. 190 6. Security Considerations 192 This draft has no security issue introduced. 194 7. Acknowledgements 196 The authors would like to thank Weisu Qi, Haijun Xu, Shunwan Zhuang 197 for their constructive help to this work. 199 8. References 201 8.1. Normative References 203 [I-D.ietf-idr-wide-bgp-communities] 204 Raszuk, R., Haas, J., Lange, A., Amante, S., Decraene, B., 205 Jakma, P., and R. Steenbergen, "Wide BGP Communities 206 Attribute", draft-ietf-idr-wide-bgp-communities-01 (work 207 in progress), November 2015. 209 [I-D.li-idr-flowspec-rpd] 210 Li, Z., Ou, L., Luo, Y., Lu, S., Zhuang, S., and N. Wu, 211 "BGP FlowSpec Extensions for Routing Policy Distribution 212 (RPD)", draft-li-idr-flowspec-rpd-01 (work in progress), 213 October 2015. 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, 217 DOI 10.17487/RFC2119, March 1997, 218 . 220 8.2. Informative References 222 [I-D.ietf-idr-registered-wide-bgp-communities] 223 Raszuk, R. and J. Haas, "Registered Wide BGP Community 224 Values", draft-ietf-idr-registered-wide-bgp-communities-01 225 (work in progress), November 2015. 227 Authors' Addresses 228 Nan Wu 229 Huawei 230 Huawei Campus., No.156 Beiqing Rd. 231 Beijing 100095 232 China 234 Email: eric.wu@huawei.com 236 Shankara Devadiga 237 Huawei 238 Bangalore 560037 239 India 241 Email: shankara@huawei.com