Internet DRAFT - draft-ietf-idr-sla-exchange-impl
draft-ietf-idr-sla-exchange-impl
Network Working Group S. Shah
Internet-Draft K. Patel
Intended status: Informational Cisco Systems
Expires: February 17, 2017 August 16, 2016
Inter-domain SLA Exchange Implementation Report-02
draft-ietf-idr-sla-exchange-impl-02
Abstract
This document is a report of implementations based on [IDR-SLA].
[IDR-SLA] introduces a new BGP attribute to exchange QoS SLA
parameters between BGP peers. Current status of the implementation
report covers Cisco implementation on 2 different OS, ExaBGP
implementation and inter-operability results between them.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Shah & Patel Expires February 17, 2017 [Page 1]
Internet-Draft IDR SLA Exchange Implementation Report August 2016
Table of Contents
1. Implementations and interoperability . . . . . . . . . . . . 2
1.1. Survey of Operations . . . . . . . . . . . . . . . . . . 2
2. Suggestions for the future . . . . . . . . . . . . . . . . . 4
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Implementations and interoperability
Cisco IOS Cisco NX-OS ExaBGP
Cisco IOS Y Y Y
Cisco NX-OS Y Y
The ExaBGP implementation report is based on a version that is
implemented as a receiver.
1.1. Survey of Operations
Optional transitive attribute:
Is QoS attribute implemented as an optional transitive attribute
- Yes
Local QoS SLA policy enablement:
When QoS SLA policy enablement triggers an explicit BGP update
message with QoS attribute and SLA sub-type content, has an
attribute's highest order bit, in the QoS attribute flag,
set to 1? This is to indicate receiver to drop the message
on reception.
- Yes
Is implementation capable of QoS SLA advertisement in the context
of advertised NLRI? with source AS = 0 in the QoS SLA attribute
- did not implement
Is implementation capable of advertising QoS SLA with explicit
source and destination AS encoded?
- Yes, Current ExaBGP version of implementation ignores
encoded AS
Shah & Patel Expires February 17, 2017 [Page 2]
Internet-Draft IDR SLA Exchange Implementation Report August 2016
First trigger for QoS SLA advertisement:
At the first trigger for SLA advertisement, a sender advertises
SLA parameters with an unique SLA id?
- Yes
Acting as a receiver, is implementation capable to learn an
advertised QoS attribute and SLA parameters
- Yes
Updating previously advertised QoS SLA:
On an event detecting update to earlier advertised SLA, sender
picks the same SLA id, advertised before, and signals new
SLA parameters in its entirety. No delta updates.
- Yes
Acting as a receiver, is implementation capable to replace SLA
parameters learned previously?
- Yes, ExaBGP implementation validated to interpret received
SLA parameters. It is not implemented with persistent
state to map to next BGP update with the same SLA
identifier
Invalidation of previously advertised SLA:
On an event to invalidate previously advertised SLA parameters,
a BGP update message is sent to the same destination AS with
the same SLA id, advertised before, with SLA message
containing 0 Traffic Class count.
- Yes
Acting as a receiver, is implementation capable to remove
previously learned QoS SLA parameters?
- Yes, This capability not yet implemented in ExaBGP
QoS SLA advertisement for point to point connection:
Is implementation capable to advertise SLA for the destination
that is next hop
- Yes
QoS SLA advertisement for destination multiple hops away:
Is implementation capable to advertise SLA for the destination
that is multiple hops away?
- Yes
Shah & Patel Expires February 17, 2017 [Page 3]
Internet-Draft IDR SLA Exchange Implementation Report August 2016
None of the forwarding nodes modify the content of the QoS SLA
parameters?
- Yes
Inter-operability with nodes not supporting this attribute:
Is interoperability tested to make sure this optional transitive
attribute is forwarded without any impact through the nodes
that do not implement support of this attribute
- Yes
Attributes implemented:
Cisco:
Direction
incoming
outgoing
Traffic Class Count
Traffic Class Description
Traffic Class Elements Count
Classifier Element values
ipDiffServCodePoint
Traffic Class Service Count
Service Attributes:
Traffic_CLASS_TSPEC
MINRATE_IN_PROFILE_MARKING
MINRTE_OUT_PROFILE_MARKING
RELATIVE_PRIORITY
2. Suggestions for the future
The proposed draft is to define message to exchange SLA parameters
between two nodes. The SLA specification does not make any
assumption about provisioning. It is not required though it would be
nice if provisioning is aligned with SLA specification [IDR-SLA] and
thus providing a consistent way of mapping between provisioning and
messaging.
3. Acknowledgements
Thanks to Ruta Vaidya for providing data on Cisco implementation.
Thanks To Thomas Mangin for his guidance during ExaBGP
implementation.
Shah & Patel Expires February 17, 2017 [Page 4]
Internet-Draft IDR SLA Exchange Implementation Report August 2016
4. Security Considerations
No Security considerations are required for the report presented in
this document.
5. Normative References
[IDR-SLA] Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M.
Boucadair, "Inter-domain SLA Exchange, I-D.draft-ietf-idr-
sla-exchange", April 2015.
Authors' Addresses
Shitanshu Shah
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Email: svshah@cisco.com
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
US
Email: keyupate@cisco.com
Shah & Patel Expires February 17, 2017 [Page 5]
