idnits 2.17.1 draft-svshah-idr-sla-exchange-impl-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([IDR-SLA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 11, 2015) is 3354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Shah 3 Internet-Draft K. Patel 4 Intended status: Informational Cisco Systems 5 Expires: August 15, 2015 Feb 11, 2015 7 Inter-domain SLA Exchange Implementation Report 8 draft-svshah-idr-sla-exchange-impl-02 10 Abstract 12 This document is a report of implementations based on [IDR-SLA]. 13 [IDR-SLA] introduces a new BGP attribute to exchange QoS SLA 14 parameters between BGP peers. Current status of the implementation 15 report covers Cisco implementation on 2 different OS, ExaBGP 16 implementation and inter-operability results between them. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 15, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Implementations and interoperability . . . . . . . . . . . . . 3 53 1.1. Survey of Operations . . . . . . . . . . . . . . . . . . . 3 54 2. Suggestions for the future . . . . . . . . . . . . . . . . . . 5 55 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 60 1. Implementations and interoperability 62 Cisco IOS Cisco NX-OS ExaBGP 63 Cisco IOS Y Y Y 64 Cisco NX-OS Y Y 66 The ExaBGP implementation report is based on a version that is 67 implemented as a receiver. 69 1.1. Survey of Operations 71 Optional transitive attribute: 72 Is QoS attribute implemented as an optional transitive attribute 73 - Yes 75 Local QoS SLA policy enablement: 76 When QoS SLA policy enablement triggers an explicit BGP update 77 message with QoS attribute and SLA sub-type content, has an 78 attribute's highest order bit, in the QoS attribute flag, 79 set to 1? This is to indicate receiver to drop the message 80 on reception. 81 - Yes 83 Is implementation capable of QoS SLA advertisement in the context 84 of advertised NLRI? with source AS = 0 in the QoS SLA attribute 85 - did not implement 87 Is implementation capable of advertising QoS SLA with explicit 88 source and destination AS encoded? 89 - Yes, Current ExaBGP version of implementation ignores 90 encoded AS 92 First trigger for QoS SLA advertisement: 93 At the first trigger for SLA advertisement, a sender advertises 94 SLA parameters with an unique SLA id? 95 - Yes 97 Acting as a receiver, is implementation capable to learn an 98 advertised QoS attribute and SLA parameters 99 - Yes 101 Updating previously advertised QoS SLA: 102 On an event detecting update to earlier advertised SLA, sender 103 picks the same SLA id, advertised before, and signals new 104 SLA parameters in its entirety. No delta updates. 105 - Yes 107 Acting as a receiver, is implementation capable to replace SLA 108 parameters learned previously? 109 - Yes, ExaBGP implementation validated to interpret received 110 SLA parameters. It is not implemented with persistent 111 state to map to next BGP update with the same SLA 112 identifier 114 Invalidation of previously advertised SLA: 115 On an event to invalidate previously advertised SLA parameters, 116 a BGP update message is sent to the same destination AS with 117 the same SLA id, advertised before, with SLA message 118 containing 0 Traffic Class count. 119 - Yes 121 Acting as a receiver, is implementation capable to remove 122 previously learned QoS SLA parameters? 123 - Yes, This capability not yet implemented in ExaBGP 125 QoS SLA advertisement for point to point connection: 126 Is implementation capable to advertise SLA for the destination 127 that is next hop 128 - Yes 130 QoS SLA advertisement for destination multiple hops away: 131 Is implementation capable to advertise SLA for the destination 132 that is multiple hops away? 133 - Yes 135 None of the forwarding nodes modify the content of the QoS SLA 136 parameters? 137 - Yes 139 Inter-operability with nodes not supporting this attribute: 140 Is interoperability tested to make sure this optional transitive 141 attribute is forwarded without any impact through the nodes 142 that do not implement support of this attribute 143 - Yes 145 Attributes implemented: 146 Cisco: 147 Direction 148 incoming 149 outgoing 150 Traffic Class Count 151 Traffic Class Description 152 Traffic Class Elements Count 153 Classifier Element values 154 ipDiffServCodePoint 155 Traffic Class Service Count 156 Service Attributes: 157 Traffic_CLASS_TSPEC 158 MINRATE_IN_PROFILE_MARKING 159 MINRTE_OUT_PROFILE_MARKING 160 RELATIVE_PRIORITY 162 2. Suggestions for the future 164 The proposed draft is to define message to exchange SLA parameters 165 between two nodes. The SLA specification does not make any 166 assumption about provisioning. It is not required though it would be 167 nice if provisioning is aligned with SLA specification [IDR-SLA] and 168 thus providing a consistent way of mapping between provisioning and 169 messaging. 171 3. Acknowledgements 173 Thanks to Ruta Vaidya for providing data on Cisco implementation. 174 Thanks To Thomas Mangin for his guidance during ExaBGP 175 implementation. 177 4. Security Considerations 179 No Security considerations are required for the report presented in 180 this document. 182 5. Normative References 184 [IDR-SLA] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M. 185 Boucadair, "Inter-domain SLA Exchange, 186 I-D.draft-ietf-idr-sla-exchange", April 2015. 188 Authors' Addresses 190 Shitanshu Shah 191 Cisco Systems 192 170 W. Tasman Drive 193 San Jose, CA 95134 194 US 196 Email: svshah@cisco.com 198 Keyur Patel 199 Cisco Systems 200 170 W. Tasman Drive 201 San Jose, CA 95134 202 US 204 Email: keyupate@cisco.com