draft-ietf-idr-sla-exchange-11.txt   draft-ietf-idr-sla-exchange-12.txt 
IDR S. Shah IDR S. Shah
Internet-Draft Internet-Draft
Intended status: Standards Track K. Patel Intended status: Standards Track K. Patel
Expires: February 2, 2018 Arrcus, Inc Expires: February 23, 2018 Arrcus, Inc
S. Bajaj S. Bajaj
Viptela Viptela
L. Tomotaki L. Tomotaki
Verizon Verizon
M. Boucadair M. Boucadair
Orange Orange
August 1, 2017 August 22, 2017
Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute Inter-domain Traffic Conditioning Agreement (TCA) Exchange Attribute
draft-ietf-idr-sla-exchange-11.txt draft-ietf-idr-sla-exchange-12.txt
Abstract Abstract
Network administrators typically enforce Quality of Service (QoS) Network administrators typically enforce Quality of Service (QoS)
policies according to Traffic Conditioning Agreement (TCA) with their policies according to Traffic Conditioning Agreement (TCA) 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 TCA, either vendor-specific configuration language. Both learning of TCA, either
thru TCA documents or via some other out-of-band method, and thru TCA 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 49 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, 2018. This Internet-Draft will expire on February 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
This document defines a new optional BGP transitive attribute, This document defines a new optional BGP transitive attribute,
referred as QoS Attribute, which has as one of its sub-types the TCA referred as QoS Attribute, which has as one of its sub-types the TCA
policy. The BGP node of the originating AS sends this QoS Attribute, policy. The BGP node of the originating AS sends this QoS Attribute,
for prefixes this QoS TCA Policy applies to, in a BGP UPDATE message for prefixes this QoS TCA Policy applies to, in a BGP UPDATE message
that will be distributed to a list of destination ASes. The QoS TCA that will be distributed to a list of destination ASes. The QoS TCA
policy can be for inbound traffic to the advertising AS or outbound policy can be for inbound traffic to the advertising AS or outbound
traffic from the advertising AS, or both. traffic from the advertising AS, or both.
Protocols and data models are being created to standardize setting Protocols and data models are being created to standardize setting
routing configuration parameters within networks. YANG data models routing configuration parameters within networks. YANG data models
[RFC6020] are being developed so that NETCONF ([RFC6241]) or RESTConf [RFC6020] are being developed so that NETCONF ([RFC6241]) or RESTCONF
[RFC8040] can set these standardize in configuration mechanisms. For [RFC8040] can set these standardize in configuration mechanisms. For
ephemeral state, the I2RS protocol is being developed to set ephemeral state, the I2RS protocol is being developed to set
ephemeral state. While these protocols provide valid configuration ephemeral state. While these protocols provide valid configuration
within a domain or across domains, some providers desire to exchange within a domain or across domains, some providers desire to exchange
QoS parameters in- band utilizing BGP peering relationships. This is QoS parameters in- band utilizing BGP peering relationships. This is
similar to the distribution of Flow Specification information via BGP similar to the distribution of Flow Specification information via BGP
peering relationships (see [RFC5575] and [RFC7674]). peering relationships (see [RFC5575] and [RFC7674]).
2. Terminology 2. Terminology
skipping to change at page 12, line 22 skipping to change at page 12, line 22
0x04 = COMMITTED_OUT_PROFILE_MARKING 0x04 = COMMITTED_OUT_PROFILE_MARKING
0x05 = PEAK_OUT_PROFILE_MARKING 0x05 = PEAK_OUT_PROFILE_MARKING
0x06 = DROP_THRESHOLD 0x06 = DROP_THRESHOLD
0x07 = RELATIVE_PRIORITY 0x07 = RELATIVE_PRIORITY
0x08 = EFFECTIVE_MAX_RATE 0x08 = EFFECTIVE_MAX_RATE
0x09 = SUB_TRAFFIC_CLASSES
Length of Value field - 08-bits field that specifies the length of Length of Value field - 08-bits field that specifies the length of
the value field. The length of the value is expressed in octets. the value field. The length of the value is expressed in octets.
Value - a variable length field that specifies the value Value - a variable length field that specifies the value
appropriate for each of the Service Types. It is an error, if appropriate for each of the Service Types. It is an error, if
this field does not contain the appropriate format, which should this field does not contain the appropriate format, which should
be handled as described in Section 6. The format of the value for be handled as described in Section 6. The format of the value for
each of the service types is described in Section 3.3.2 each of the service types is described in Section 3.3.2
3.3.1. Supported IPFIX identifiers for Traffic Class Elements 3.3.1. Supported IPFIX identifiers for Traffic Class Elements
skipping to change at page 20, line 34 skipping to change at page 20, line 34
List of code-points - each code-point value is specified in size List of code-points - each code-point value is specified in size
of 8 bits and thus total size for this field is 8 bits multiplied of 8 bits and thus total size for this field is 8 bits multiplied
by as many number of code-points specified. by as many number of code-points specified.
Burst value - This is a fixed size 32-bits IEEE floating point Burst value - This is a fixed size 32-bits IEEE floating point
number that specifies burst value in unit of bytes. number that specifies burst value in unit of bytes.
All advertised drop thresholds, for a specific traffic class, are All advertised drop thresholds, for a specific traffic class, are
applicable to a single queue associated with that traffic class. A applicable to a single queue associated with that traffic class. A
threshold for a set of code-points is a logical marker where an threshold for a set of code-points is a logical marker where an
arrived packet is to be tail dropped if overall depth of a queue is arrived packet is to be dropped if overall depth of a queue is beyond
beyond a threshold of a code-point set, a packet is classified into. a threshold of a code-point set a packet is classified into. Choice
If a packet can not be classified into any of the advertised code- of dropping discipline is implementation specific. If a packet can
point set then that means the TCA Producer is not defining any not be classified into any of the advertised code-point set then that
specific tail drop behavior and thus dropping behavior is subject to means the TCA Producer is not defining any specific dropping behavior
implementation specific of the TCA Consumer. and thus dropping behavior is subject to implementation specific of
the TCA Consumer.
+-----+---------------------+ +-----+---------------------+
| ID | Name | | ID | Name |
+-----+---------------------+ +-----+---------------------+
| 195 | ipDiffServCodePoint | | 195 | ipDiffServCodePoint |
| 203 | mplsTopLabelExp | | 203 | mplsTopLabelExp |
| 244 | dot1qPriority | | 244 | dot1qPriority |
+-----+---------------------+ +-----+---------------------+
Table 3 Table 3
skipping to change at page 21, line 23 skipping to change at page 21, line 23
this specification, the length of the value field MUST be limited this specification, the length of the value field MUST be limited
to and thus MUST be specified exactly as 1 octet. to and thus MUST be specified exactly as 1 octet.
Value - A value from range of 0 - 255. Lower the value means Value - A value from range of 0 - 255. Lower the value means
higher the priority higher the priority
Relative priority indicates scheduling priority of this traffic Relative priority indicates scheduling priority of this traffic
class. Voice traffic, for example, which requires lowest latency class. Voice traffic, for example, which requires lowest latency
compared to any other traffic, may have lowest value advertised in compared to any other traffic, may have lowest value advertised in
relative priority. For two different traffic classification groups relative priority. For two different traffic classification groups
where one application group may be considered more important than the where one classification group may be considered more important than
other but from a scheduling perspective does not require to be the other, but from a scheduling perspective does not require to be
distinguished with a different priority, relative priority for those distinguished with a different priority, relative priority for those
classification groups may be advertised with the same value. classification groups should be advertised with the same value.
A higher priority class of traffic to be served without pre-empted by A higher priority class of traffic to be served without pre-empted by
lower priority class of traffic for more than a packet time at the lower priority class of traffic for more than a packet time at the
configured rate. configured rate.
In the system that implements WRR only (no priority queuing), it is For a system that implements WRR only (i.e., no priority queuing), it
possible to use a single queue from a group of queues serviced by WRR is possible to use a hierarchical WRR scheduling to achieve a
scheduler, where the share of the output bandwidth assigned to that behavior close to priority queueing where a root scheduling node has
queue is equal to advertised rate for that priority. two child nodes. One child node is a queue assigned with a maximum
possible value of a weight and advertised rate of highest priority
Traffic Class as output bandwidth. The other child node is a
scheduling node serving group of rest other advertised Traffic
Classes (in the form of queues or yet another level of hierarchical
WRR scheduler). Note that implementation specifics are out of the
scope of this specification and this is an example to highlight how
relative priority attribute can be relevant and treated by a system
that implements only WRR. A system may choose to implement alternate
methods to achieve a similar behavior.
3.3.2.8. EFFECTIVE_MAX_RATE 3.3.2.8. EFFECTIVE_MAX_RATE
The EFFECTIVE_MAX_RATE TLV definition: The EFFECTIVE_MAX_RATE TLV definition:
Type - 0x02 Type - 0x02
Length - 8-bits field that specifies length, expressed in octets, Length - 8-bits field that specifies length, expressed in octets,
of the value field. The length of the value field MUST be of the value field. The length of the value field MUST be
specified to be 5 octets to hold the value defined as per format specified to be 5 octets to hold the value defined as per format
below. below.
Value - Contains value of rate and per packet overhead Value - Contains value of rate and per packet overhead
Aggregate max rate - 32-bits IEEE floating point number Aggregate max rate - 32-bits IEEE floating point number
Per packet overhead - 8-bits specifying value of overhead Per packet overhead - 8-bits specifying value of overhead
octets octets
Aggregate max rate indicates rate measured based on combined octets Aggregate max rate indicates rate measured based on combined octets
of packet's IP datagram size and advertised per packet overhead. of packet's IP datagram size and advertised per packet overhead.
A packet traversing from the TCA Producer to the TCA Consumer or A packet traversing from the TCA Producer to the TCA Consumer or
vice-versa may see packet overhead, additional octets on top of IP vice-versa may see packet overhead, additional octets on top of IP
skipping to change at page 22, line 23 skipping to change at page 22, line 30
vice-versa may see packet overhead, additional octets on top of IP vice-versa may see packet overhead, additional octets on top of IP
datagram size, difference between the Producer and the Consumer sent datagram size, difference between the Producer and the Consumer sent
or received over a physical link. In cases, where advertised TCA is or received over a physical link. In cases, where advertised TCA is
for a Consumer where total traffic between Consumer and Producer is for a Consumer where total traffic between Consumer and Producer is
to be capped to a specific sub-rate of a physical link, due to packet to be capped to a specific sub-rate of a physical link, due to packet
overhead differences between Producer and Consumer, sum of traffic overhead differences between Producer and Consumer, sum of traffic
from each TRAFFIC CLASS may overrun that total cap causing undesired from each TRAFFIC CLASS may overrun that total cap causing undesired
behavior. In such cases, Producer can explicitly notify this TLV in behavior. In such cases, Producer can explicitly notify this TLV in
advertised TCA. advertised TCA.
3.3.2.9. SUB_TRAFFIC_CLASSES
The SUB_TRAFFIC_CLASSES TLV definition:
Type - 0x09
Length - 16-bits field that specifies total length, expressed in
octets, of a Traffic Class TLVs encoded in the value field
Value - A subset of Traffic Class TLVs
For TCAs where a specific Traffic Class may further be defined by a
subset of more granular Traffic Classes, with its own set of Traffic
Class TLVs, SUB_TRAFFIC_CLASSES service type SHOULD be used to
specify them.
4. Originating TCA Notification 4. Originating TCA Notification
The QoS Attribute for the TCA SubType MUST only be added to the BGP The QoS Attribute for the TCA SubType MUST only be added to the BGP
UPDATE message at the node that is TCA Producer. Any QoS Attribute UPDATE message at the node that is TCA Producer. Any QoS Attribute
Speaker, in the path to the TCA Consumer MUST NOT modify content of Speaker, in the path to the TCA Consumer MUST NOT modify content of
that attribute except modification of the Destination AS list. that attribute except modification of the Destination AS list.
QoS Attribute with the TCA SubType SHOULD NOT be advertised QoS Attribute with the TCA SubType SHOULD NOT be advertised
periodically just for the purpose of KEEPALIVE between TCA Producer periodically just for the purpose of KEEPALIVE between TCA Producer
and TCA Consumer. Some sort of TCA policy change, at the TCA and TCA Consumer. Some sort of TCA policy change, at the TCA
skipping to change at page 28, line 37 skipping to change at page 28, line 25
============================ ====== ============================ ======
Reserved 0x00 Reserved 0x00
COMMITTED_TSPEC 0x01 COMMITTED_TSPEC 0x01
PEAK_TSPEC 0x02 PEAK_TSPEC 0x02
COMMITTED_IN_PROFILE_MARKING 0x03 COMMITTED_IN_PROFILE_MARKING 0x03
COMMITTED_OUT_PROFILE_MARKING 0x04 COMMITTED_OUT_PROFILE_MARKING 0x04
PEAK_OUT_PROFILE_MARKING 0x05 PEAK_OUT_PROFILE_MARKING 0x05
DROP_THRESHOLD 0x06 DROP_THRESHOLD 0x06
RELATIVE_PRIORITY 0x07 RELATIVE_PRIORITY 0x07
EFFECTIVE_MAX_RATE 0x08 EFFECTIVE_MAX_RATE 0x08
SUB_TRAFFIC_CLASSES 0x09 Standards Action 0x09 - 0x3FFF
Standards Action 0x0A - 0x3FFF
FCFS 0x4000 - 0x4FF0 FCFS 0x4000 - 0x4FF0
9. Security Considerations 9. Security Considerations
BGP security vulnerabilities analysis is documented in [RFC4272], BGP security vulnerabilities analysis is documented in [RFC4272],
while BGP-related security considerations are discussed in [RFC4271]. while BGP-related security considerations are discussed in [RFC4271].
Also, the reader may refer to [RFC7132] for more details about BGP Also, the reader may refer to [RFC7132] for more details about BGP
path threat model. Means to prevent route hijacking SHOULD be path threat model. Means to prevent route hijacking SHOULD be
enabled. Such means include RPKI based origin validation [RFC7115] enabled. Such means include RPKI based origin validation [RFC7115]
and BGP Path validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]). and BGP Path validation (e.g., [I-D.ietf-sidr-bgpsec-protocol]).
skipping to change at page 29, line 41 skipping to change at page 29, line 31
Alvaro Retana for their suggestions and to Christian Jacquenet, Ken Alvaro Retana for their suggestions and to Christian Jacquenet, Ken
Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand Briley, Rahul Patel, Fred Yip, Lou Berger, Brian Carpenter, Bertrand
Duvivier, Bruno Decraene, David Black, and Ron Bonica for the review. Duvivier, Bruno Decraene, David Black, and Ron Bonica for the review.
11. References 11. References
11.1. Normative References 11.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-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, of Guaranteed Quality of Service", RFC 2212,
DOI 10.17487/RFC2212, September 1997, DOI 10.17487/RFC2212, September 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2212>. editor.org/info/rfc2212>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4271>. editor.org/info/rfc4271>.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation [RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May Standard", STD 67, RFC 4506, DOI 10.17487/RFC4506, May
2006, <http://www.rfc-editor.org/info/rfc4506>. 2006, <https://www.rfc-editor.org/info/rfc4506>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012, for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7012>. editor.org/info/rfc7012>.
[RFC7115] Bush, R., "Origin Validation Operation Based on the [RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185, Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014, RFC 7115, DOI 10.17487/RFC7115, January 2014,
<http://www.rfc-editor.org/info/rfc7115>. <https://www.rfc-editor.org/info/rfc7115>.
[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>. <https://www.rfc-editor.org/info/rfc7606>.
11.2. Informative References 11.2. Informative References
[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-22 (work Specification", draft-ietf-sidr-bgpsec-protocol-22 (work
in progress), January 2017. 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>. <https://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, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4086>. editor.org/info/rfc4086>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>. <https://www.rfc-editor.org/info/rfc5575>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6020>. editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6793>. editor.org/info/rfc6793>.
[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", [RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014, RFC 7132, DOI 10.17487/RFC7132, February 2014,
<http://www.rfc-editor.org/info/rfc7132>. <https://www.rfc-editor.org/info/rfc7132>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297, Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7297>. 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, <https://www.rfc-editor.org/info/rfc7674>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
Authors' Addresses Authors' Addresses
Shitanshu Shah Shitanshu Shah
Email: shitanshu_shah@hotmail.com Email: shitanshu_shah@hotmail.com
Keyur Patel Keyur Patel
Arrcus, Inc Arrcus, Inc
 End of changes. 33 change blocks. 
66 lines changed or deleted 57 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/