draft-ietf-idr-sla-exchange-09.txt   draft-ietf-idr-sla-exchange-10.txt 
IDR S. Shah IDR S. Shah
Internet-Draft K. Patel Internet-Draft
Intended status: Standards Track Cisco Systems Intended status: Standards Track K. Patel
Expires: February 2, 2017 S. Bajaj Expires: August 1, 2017 Arrcus, Inc
Juniper Network S. Bajaj
Viptela
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
Orange Orange
August 1, 2016 January 28, 2017
Inter-domain SLA Exchange Attribute Inter-domain SLA Exchange Attribute
draft-ietf-idr-sla-exchange-09.txt draft-ietf-idr-sla-exchange-10.txt
Abstract Abstract
Network administrators typically enforce Quality of Service (QoS) Network administrators typically enforce Quality of Service (QoS)
policies according to Service Level Agreement (SLA) with their policies according to Service Level Agreement (SLA) with their
providers. The enforcement of such policies often relies upon providers. The enforcement of such policies often relies upon
vendor-specific configuration language. Both learning of SLA, either vendor-specific configuration language. Both learning of SLA, either
thru SLA documents or via some other out-of-band method, and thru SLA documents or via some other out-of-band method, and
translating them to vendor specific configuration language is a translating them to vendor specific configuration language is a
complex, often manual, process and prone to errors. complex, often manual, process and prone to errors.
skipping to change at page 1, line 48 skipping to change at page 1, line 49
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 2, 2017. This Internet-Draft will expire on August 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 26, line 9 skipping to change at page 26, line 9
====================== ======================
Reserved 0x00 Reserved 0x00
SLA 0x01 SLA 0x01
Reserved 0x02-0xf0 (Standards Action) Reserved 0x02-0xf0 (Standards Action)
Private use 0xf1-0xff Private use 0xf1-0xff
IANA is requested to create a registry for QoS Attribute SLA SubType IANA is requested to create a registry for QoS Attribute SLA SubType
flags. This is registry for 8-bits. The initial assignments are as flags. This is registry for 8-bits. The initial assignments are as
shown below. shown below.
QoS Attribute SLA SubType Flags QoS Attribute SLA SubType Flags
=============================== ===============================
Highest order bit (bit 0) - to indicate source and destination AS context Highest order bit (bit 0) - to indicate source and destination
Reserved - bits 1 to 15 (Standards Action) AS context
Reserved - bits 1 to 15 (Standards Action)
IANA is requested to create a registry for QoS Attribute SLA Event IANA is requested to create a registry for QoS Attribute SLA Event
Types. This is a registry of 4-bits value, divided into two pools. Types. This is a registry of 4-bits value, divided into two pools.
One pool of numbers to be assigned on a standards action/early One pool of numbers to be assigned on a standards action/early
allocation basis. One pool of numbers to be assigned on a standards allocation basis. One pool of numbers to be assigned on a standards
action/early allocation basis. The initial assignments are as shown action/early allocation basis. The initial assignments are as shown
below. The other pool is for the private use, available range for below. The other pool is for the private use, available range for
which is as shown below. which is as shown below.
QoS Attribute SLA Event Types QoS Attribute SLA Event Types
skipping to change at page 27, line 44 skipping to change at page 27, line 44
Provider). It is NOT RECOMMENDED to enable this attribute at the Provider). It is NOT RECOMMENDED to enable this attribute at the
scale of the Internet unless if means to prevent leaking sensitive scale of the Internet unless if means to prevent leaking sensitive
information are enforced. information are enforced.
The attribute may be advertised by a misbehaving node to communicate The attribute may be advertised by a misbehaving node to communicate
SLA parameters that are not aligned with the SLA agreements. Though SLA parameters that are not aligned with the SLA agreements. Though
the enforcement of SLA parameters is outside the scope of this the enforcement of SLA parameters is outside the scope of this
document, it is RECOMMENDED that the SLA Consumer to enforce a set of document, it is RECOMMENDED that the SLA Consumer to enforce a set of
validation checks before translating the SLA parameters conveyed in validation checks before translating the SLA parameters conveyed in
the QoS attributes into provisioning actions. Such validations MAY the QoS attributes into provisioning actions. Such validations MAY
rely on SLA parameters lime the origin AS or SLA ID, like generating rely on SLA parameters like the origin AS or SLA ID, like generating
SLA ID using pseudo-random schemes [RFC4086]. SLA ID using pseudo-random schemes [RFC4086].
Means to prevent route hijacking SHOULD BE considered. Such means Means to prevent route hijacking SHOULD BE considered. Such means
include RPKI based origin validation [RFC7115] and BGP Path include RPKI based origin validation [RFC7115] and BGP Path
validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]). validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]).
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 29, line 23 skipping to change at page 29, line 23
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>. <http://www.rfc-editor.org/info/rfc7606>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-15 (work in Protocol", draft-ietf-netconf-restconf-18 (work in
progress), July 2016. progress), October 2016.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M. and K. Sriram, "BGPsec Protocol Lepinski, M. and K. Sriram, "BGPsec Protocol
Specification", draft-ietf-sidr-bgpsec-protocol-17 (work Specification", draft-ietf-sidr-bgpsec-protocol-22 (work
in progress), June 2016. in progress), January 2017.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
skipping to change at page 30, line 22 skipping to change at page 30, line 22
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014,
<http://www.rfc-editor.org/info/rfc7297>. <http://www.rfc-editor.org/info/rfc7297>.
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect
Extended Community", RFC 7674, DOI 10.17487/RFC7674, Extended Community", RFC 7674, DOI 10.17487/RFC7674,
October 2015, <http://www.rfc-editor.org/info/rfc7674>. October 2015, <http://www.rfc-editor.org/info/rfc7674>.
Authors' Addresses Authors' Addresses
Shitanshu Shah Shitanshu Shah
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Email: svshah@cisco.com Email: shitanshu_shah@hotmail.com
Keyur Patel Keyur Patel
Cisco Systems Arrcus, Inc
170 W. Tasman Drive
San Jose, CA 95134
US
Email: keyupate@cisco.com Email: keyur@arrcus.com
Sandeep Bajaj Sandeep Bajaj
Juniper Network Viptela
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
US
Email: sbajaj@juniper.net
Luis Tomotaki Luis Tomotaki
Verizon Verizon
400 International 400 International
Richardson, TX 75081 Richardson, TX 75081
US US
Email: luis.tomotaki@verizon.com Email: luis.tomotaki@verizon.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
 End of changes. 15 change blocks. 
32 lines changed or deleted 23 lines changed or added

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