< draft-ietf-trill-oam-req-01.txt   draft-ietf-trill-oam-req-02.txt >
TRILL Working Group Tissa Senevirathne TRILL Working Group Tissa Senevirathne
Internet Draft CISCO Internet Draft CISCO
Intended status: Informational David Bond Intended status: Informational David Bond
IBM IBM
Sam Aldrin Sam Aldrin
Yizhou Li Yizhou Li
Huawei Huawei
Rohit Watve Rohit Watve
CISCO CISCO
Anoop Ghanwani
DELL
Jon Hudson
Brocade
Naveen Nimmu
Broadcom
Radia Perlman
Intel
Tal Mizrahi
Marvell
August 22, 2012 October 20, 2012
Expires: February 2013 Expires: April 2013
Requirements for Operations, Administration and Maintenance (OAM) in Requirements for Operations, Administration and Maintenance (OAM) in
TRILL TRILL
draft-ietf-trill-oam-req-01.txt draft-ietf-trill-oam-req-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 4 skipping to change at page 1, line 36
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 22,2013. This Internet-Draft will expire on April 20,2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 34 skipping to change at page 2, line 25
Abstract Abstract
OAM (Operations, Administration and Maintenance) is a general term OAM (Operations, Administration and Maintenance) is a general term
used to identify functions and toolsets to troubleshoot and monitor used to identify functions and toolsets to troubleshoot and monitor
networks. This document presents, OAM Requirements applicable to networks. This document presents, OAM Requirements applicable to
TRILL. TRILL.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Contributors..............................................3 1.1. Scope.....................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Terminology....................................................4 3. Terminology....................................................3
4. OAM Requirements...............................................5 4. OAM Requirements...............................................4
4.1. Data Plane................................................5 4.1. Data Plane................................................4
4.2. Connectivity Verification.................................5 4.2. Connectivity Verification.................................5
4.2.1. Unicast..............................................5 4.2.1. Unicast..............................................5
4.2.2. Multicast............................................6 4.2.2. Multicast............................................5
4.3. Continuity Check..........................................6 4.3. Continuity Check..........................................5
4.4. Path Tracing..............................................6 4.4. Path Tracing..............................................6
4.5. General Requirements......................................7 4.5. General Requirements......................................6
4.6. Performance Monitoring....................................7 4.6. Performance Monitoring....................................7
4.6.1. Packet Loss..........................................7 4.6.1. Packet Loss..........................................7
4.6.2. Packet Delay.........................................8 4.6.2. Packet Delay.........................................8
4.7. ECMP Utilization..........................................8
4.7. ECMP Utilization..........................................9 4.8. Security and Operational considerations...................8
4.8. Security and Operational considerations...................9
4.9. Fault Indications.........................................9 4.9. Fault Indications.........................................9
4.10. Defect Indications.......................................9 4.10. Defect Indications.......................................9
4.11. Live Traffic monitoring.................................10 4.11. Live Traffic monitoring..................................9
5. Security Considerations.......................................10 5. Security Considerations.......................................10
6. IANA Considerations...........................................10 6. IANA Considerations...........................................10
7. References....................................................10 7. References....................................................10
7.1. Normative References.....................................10 7.1. Normative References.....................................10
7.2. Informative References...................................11 7.2. Informative References...................................10
8. Acknowledgments...............................................11 8. Acknowledgments...............................................11
9. Contributing Authors..........................................11
1. Introduction 1. Introduction
OAM (Operations, Administration and Maintenance) generally covers OAM (Operations, Administration and Maintenance) generally covers
various production aspects of a network. In this document we use the various production aspects of a network. In this document we use the
term OAM as defined in [RFC6291]. term OAM as defined in [RFC6291].
Success of any mission critical network depends on the ability to Success of any mission critical network depends on the ability to
proactively monitor networks for faults, performance, etc. as well proactively monitor networks for faults, performance, etc. as well
as its ability to efficiently and quickly troubleshoot defects and as its ability to efficiently and quickly troubleshoot defects and
failures. A well-defined OAM toolset is a vital requirement for failures. A well-defined OAM toolset is a vital requirement for
wider adoption of TRILL as the next generation data forwarding wider adoption of TRILL as the next generation data forwarding
technology in larger networks such as data centers. technology in larger networks such as data centers.
In this document we define the Requirements for TRILL OAM. It is In this document we define the Requirements for TRILL OAM. It is
assumed that the readers are familiar with the OAM concepts and assumed that the readers are familiar with the OAM concepts and
terminologies defined in other OAM standards such as [8021ag], terminologies defined in other OAM standards such as [8021ag],
[RFC5860]. This document does not attempt to redefine the terms and [RFC5860]. This document does not attempt to redefine the terms and
concepts specified elsewhere. concepts specified elsewhere.
1.1. Contributors 1.1. Scope
The following members were part of the design team that produced
this document. Their names are listed below in alphabetical order.
Anoop Ghanwani, David Bond, Donald Eastlake, Jon Hudson, Naveen The scope of this document is OAM between RBridges of a TRILL campus
Nimmu, Radia Perlman, Rohit Watve, Sam Aldrin, Shivakumar Sundaram, over links selected by TRILL routing.
Tal Mizrahi, Thomas Narten, Tissa Senevirathne, Yizhou Li.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Although this document is not a protocol specification, the use of Although this document is not a protocol specification, the use of
this language clarifies the instructions to protocol designers this language clarifies the instructions to protocol designers
producing solutions that satisfy the requirements set out in this producing solutions that satisfy the requirements set out in this
document. document.
3. Terminology 3. Terminology
Section: The term Section refers to a partial segment of a path Section: The term Section refers to a partial segment of a path
between any two given RBridges. As an example, consider the case between any two given RBridges. As an example, consider the case
where RB1 is connected to RBx via RB2,RB3 and RB4. The segment where RB1 is connected to RBx via RB2,RB3 and RB4. The segment
skipping to change at page 4, line 28 skipping to change at page 4, line 12
Flow: The term Flow indicates a set of packets that share the same Flow: The term Flow indicates a set of packets that share the same
path and per-hop behavior (such as priority). A flow is typically path and per-hop behavior (such as priority). A flow is typically
identified by a portion of the inner payload that affects the hop-by identified by a portion of the inner payload that affects the hop-by
hop forwarding decisions. This may contain Layer 2 through Layer 4 hop forwarding decisions. This may contain Layer 2 through Layer 4
information. information.
All Selectable Least Cost Paths: The term "all selectable least cost All Selectable Least Cost Paths: The term "all selectable least cost
paths" refers to a subset of all potentially available least cost paths" refers to a subset of all potentially available least cost
paths to a specified destination RBridge that are available (and paths to a specified destination RBridge that are available (and
usable) for forwarding of frames. It is important to note, in usable) for forwarding of frames. It is important to note, in
practice, not all available least cost paths are selectable for practice, due to limitations in implementations, not all available
forwarding due to limitations in implementations. least cost paths may be selectable for forwarding.
Connectivity: The term connectivity indicates reachability between Connectivity: The term connectivity indicates reachability between
an arbitrary RBridge RB1 and any other RBridge RB2. The specific an arbitrary RBridge RB1 and any other RBridge RB2. The specific
path can be either explicit (i.e. associated with a specific flow) path can be either explicit (i.e. associated with a specific flow)
or unspecified. Unspecified means that messages used for or unspecified. Unspecified means that messages used for
connectivity verification take whatever that path the RBs happen to connectivity verification take whatever that path the RBs happen to
select. select.
Continuity Verification: Continuity Verification refers to proactive Continuity Verification: Continuity Verification refers to proactive
verification of Connectivity between two RBridges at periodic verification of Connectivity between two RBridges at periodic
skipping to change at page 6, line 32 skipping to change at page 6, line 14
OAM MUST provide functions that allow any arbitrary RBridge RB1 to OAM MUST provide functions that allow any arbitrary RBridge RB1 to
perform a Continuity Check to any other RBridge using a path perform a Continuity Check to any other RBridge using a path
associated with a specified flow. associated with a specified flow.
OAM SHOULD provide functions that allow any arbitrary RBridge to OAM SHOULD provide functions that allow any arbitrary RBridge to
perform a Continuity Check to any other RBridge over all selectable perform a Continuity Check to any other RBridge over all selectable
least cost paths. least cost paths.
OAM SHOULD provide the ability to perform a Continuity Check on OAM SHOULD provide the ability to perform a Continuity Check on
sections of any path within the network. sections of any selectable path within the network.
OAM SHOULD provide the ability to perform a multicast Continuity OAM SHOULD provide the ability to perform a multicast Continuity
Check for specified multi-destination tree(s) as well as specified Check for specified multi-destination tree(s) as well as specified
multi-destination tree and flow combinations. The former is referred multi-destination tree and flow combinations. The former is referred
to as an un-pruned multi-destination tree Continuity Check and the to as an un-pruned multi-destination tree Continuity Check and the
latter is referred to as a pruned tree Continuity Check. latter is referred to as a pruned tree Continuity Check.
4.4. Path Tracing 4.4. Path Tracing
OAM MUST provide the ability to trace a path between any two OAM MUST provide the ability to trace a path between any two
skipping to change at page 7, line 19 skipping to change at page 6, line 48
OAM MUST provide the ability to initiate and maintain multiple OAM MUST provide the ability to initiate and maintain multiple
concurrent sessions for multiple OAM functions between any arbitrary concurrent sessions for multiple OAM functions between any arbitrary
RBridge RB1 to any other RBridge. In general, multiple OAM RBridge RB1 to any other RBridge. In general, multiple OAM
operations will run concurrently. For example, proactive continuity operations will run concurrently. For example, proactive continuity
checks may take place between RB1 and RB2 at the same time an checks may take place between RB1 and RB2 at the same time an
operator decides to test connectivity between the same two RBs. operator decides to test connectivity between the same two RBs.
Multiple OAM functions and instances of those functions MUST be able Multiple OAM functions and instances of those functions MUST be able
to run concurrently without interfering with each other. to run concurrently without interfering with each other.
OAM MUST provide a single OAM framework for all TRILL OAM functions OAM MUST provide a single OAM framework for all TRILL OAM functions
within the scope of this document.
OAM, as practical and as possible, SHOULD provide a single framework OAM, as practical and as possible, SHOULD provide a single framework
between TRILL and other similar standards. between TRILL and other similar standards.
OAM MUST maintain related error and operational counters. Such OAM MUST maintain related error and operational counters. Such
counters MUST be accessible via network management applications counters MUST be accessible via network management applications
(e.g. SNMP). (e.g. SNMP).
OAM functions related to continuity and connectivity checks MUST be OAM functions related to continuity and connectivity checks MUST be
able to be invoked either proactively or on-demand. able to be invoked either proactively or on-demand.
OAM SHOULD NOT require extensions to the TRILL header.OAM MAY be OAM SHOULD NOT require extensions to the TRILL header. OAM MAY be
required to provide the ability to specify a desired response mode required to provide the ability to specify a desired response mode
for a specific OAM message. The desired response mode can be either for a specific OAM message. The desired response mode can be either
in-band, out-of band or none. in-band, out-of band or none.
The OAM Framework MUST be extensible to future needs of TRILL and The OAM Framework MUST be extensible to future needs of TRILL and
the needs of other standard organizations. the needs of other standard organizations.
OAM MAY provide methods to verify control plane and forwarding plane OAM MAY provide methods to verify control plane and forwarding plane
alignments. alignments.
OAM SHOULD leverage existing OAM technologies, where practical. OAM SHOULD leverage existing OAM technologies, where practical.
4.6. Performance Monitoring 4.6. Performance Monitoring
4.6.1. Packet Loss 4.6.1. Packet Loss
In this document, term loss of a packet is used as defined in In this document, term loss of a packet is used as defined in
[RFC2680] (see Section 2.4 of RFC2680). [RFC2680] (see Section 2.4 of RFC2680).
NOTE: Term simulated flow below indicates a flow that is generated NOTE: The term simulated flow below indicates a flow that is
by an RBRidge RB1 for OAM purposes. The fields of the simulated flow generated by an RBRidge RB1 for OAM purposes. The fields of the
may or may not be identical to the actual data. However, simulated simulated flow may or may not be identical to the actual data.
flow is required to follow the intended path. However, simulated flow is required to follow the intended path.
OAM SHOULD provide the ability to measure packet loss statistics for OAM SHOULD provide the ability to measure packet loss statistics for
a simulated flow from any arbitrary RBridge RB1 to any other a simulated flow from any arbitrary RBridge RB1 to any other
RBridge. RBridge.
OAM SHOULD provide the ability to measure packet loss statistics OAM SHOULD provide the ability to measure packet loss statistics
over a segment, for a simulated flow between any arbitrary RBridge over a segment, for a simulated flow between any arbitrary RBridge
RB1 to any other RBridge. RB1 to any other RBridge.
OAM SHOULD provide the ability to measure simulated packet loss OAM SHOULD provide the ability to measure simulated packet loss
skipping to change at page 9, line 31 skipping to change at page 9, line 13
shaping or rate limiting SHOULD be utilized. shaping or rate limiting SHOULD be utilized.
4.9. Fault Indications 4.9. Fault Indications
The term Fault refers to an inability to perform a required action, The term Fault refers to an inability to perform a required action,
e.g., an unsuccessful attempt to deliver a packet [OAMOVER]. The e.g., an unsuccessful attempt to deliver a packet [OAMOVER]. The
unsuccessful attempt may be due to Hop Count expiry, invalid unsuccessful attempt may be due to Hop Count expiry, invalid
nickname, etc. nickname, etc.
OAM MUST provide a Fault Indication framework to notify faults to OAM MUST provide a Fault Indication framework to notify faults to
the ingress RBRidge of the flow or other interested parties (such as the ingress RBRidge of the packet or other interested parties (such
syslog servers). as syslog servers).
OAM MUST provide functions to selectively enable or disable OAM MUST provide functions to selectively enable or disable
different types of Fault Indications. different types of Fault Indications.
4.10. Defect Indications 4.10. Defect Indications
[OAMOVER] defines "The term Defect refers to an interruption in the [OAMOVER] defines "The term Defect refers to an interruption in the
normal operation, such as a consecutive period of time where no normal operation, such as a consecutive period of time where no
packets are delivered successfully." packets are delivered successfully."
skipping to change at page 10, line 26 skipping to change at page 10, line 10
4.11. Live Traffic monitoring 4.11. Live Traffic monitoring
OAM implementations MAY provide methods to utilize live traffic for OAM implementations MAY provide methods to utilize live traffic for
troubleshooting and performance monitoring. troubleshooting and performance monitoring.
Implementations MAY leverage Data Driven CFM [8021Q] or IPFIX Implementations MAY leverage Data Driven CFM [8021Q] or IPFIX
[RFC5101] for the purpose of performance monitoring. [RFC5101] for the purpose of performance monitoring.
5. Security Considerations 5. Security Considerations
Security Requirements are specified in section 4.8. Security Requirements are specified in section 4.8. For general
TRILL security considerations please refer to [RFC6325]
6. IANA Considerations 6. IANA Considerations
None None
7. References 7. References
7.1. Normative References 7.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[OAMOVER] Mizrahi, T, et.al., "An Overview of Operations, 7.2. Informative References
Administration, and Maintenance (OAM) Mechanisms", draft-
ietf-opsawg-oam-overview-06, Work in Progress, March 2012.
[RFC5860] Vigoureux, M., et.al., "Requirements for Operations,
Administration and Maintenance (OAM) in MPLS Transport
Networks", RFC5860, May 2010.
[RFC4377] Nadeau, T., et.al., "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006.
7.2. Informative References
[RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base
Protocol Specification", RFC 6325, July 2011. Protocol Specification", RFC 6325, July 2011.
[RFC5101] Claise, B., "Specification of the IP Flow Information [RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC5101, January 2008. Flow Information", RFC5101, January 2008.
[RFC2680] Almes, G., et.al. "A One-way Packet Loss Metric for IPPM", [RFC2680] Almes, G., et.al. "A One-way Packet Loss Metric for IPPM",
RFC 2680, September 1999. RFC 2680, September 1999.
skipping to change at page 11, line 33 skipping to change at page 11, line 5
[RFC6291] Anderson, L., et.al. "Guidelines for the Use of the "OAM" [RFC6291] Anderson, L., et.al. "Guidelines for the Use of the "OAM"
Acronym in the IETF", RFC 6291, June 2011. Acronym in the IETF", RFC 6291, June 2011.
[8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: [8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5:
Connectivity Fault Management", 802.1ag, 2007. Connectivity Fault Management", 802.1ag, 2007.
[8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q-2011, Bridged Local Area Networks", IEEE Std 802.1Q-2011,
August, 2011. August, 2011.
[RFC791] "Internet Protocol", RFC 791, September 1981.
[RFC4379] Kompela, K., et.al. "Detecting Multi-protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February
2006.
[RFC4377] Nadeau, T., et.al. "Operations and Management (OAM) [RFC4377] Nadeau, T., et.al. "Operations and Management (OAM)
Requirements for Multi-protocol Label Switched Requirements for Multi-protocol Label Switched
(MPLS)Networks", RFC 4377, February 2006. (MPLS)Networks", RFC 4377, February 2006.
[OAMOVER] Mizrahi, T, et.al., "An Overview of Operations,
Administration, and Maintenance (OAM) Mechanisms", draft-
ietf-opsawg-oam-overview-06, Work in Progress, March 2012.
[RFC5860] Vigoureux, M., et.al., "Requirements for Operations,
Administration and Maintenance (OAM) in MPLS Transport
Networks", RFC5860, May 2010.
8. Acknowledgments 8. Acknowledgments
Special acknowledgments to IEEE 802.1 chair, Tony Jeffree for Special acknowledgments to IEEE 802.1 chair, Tony Jeffree for
allowing us to solicit comments from IEEE 802.1 group. Also allowing us to solicit comments from IEEE 802.1 group. Also
recognized are the comments received from IEEE group, Ayal Loir and recognized are the comments received from IEEE group, Ayal Lior and
others. others.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses 9. Contributing Authors
Tissa Senevirathne Tissa Senevirathne
CISCO Systems CISCO Systems
375 East Tasman Drive 375 East Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA. USA.
Phone: +1-408-853-2291 Phone: +1-408-853-2291
Email: tsenevir@cisco.com Email: tsenevir@cisco.com
skipping to change at page 13, line 22 skipping to change at page 12, line 30
Rohit Watve Rohit Watve
CISCO Systems CISCO Systems
375 East Tasman Drive 375 East Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA. USA.
Phone: +1-408-424-2091 Phone: +1-408-424-2091
Email: rwatve@cisco.com Email: rwatve@cisco.com
Thomas Narten
IBM Corporation
3039 Cornwallis Avenue,
PO Box 12195
Research Triangle Park, NC 27709
USA
Email:narten@us.ibm.com
Donald Eastlake
Huawei Technologies
155 Beaver Street,
Milford, MAC 01757
USA.
Email: d3e3e3@gmail.com
Anoop Ghanwani Anoop Ghanwani
DELL DELL
350 Holger Way 350 Holger Way
San Jose, CA 95134 San Jose, CA 95134
USA. USA.
Phone: +1-408-571-3500 Phone: +1-408-571-3500
Email: Anoop@duke.alumni.duke.edu Email: Anoop@alumni.duke.edu
John Hudson Jon Hudson
Brocade Brocade
120 Holger Way 120 Holger Way
San Jose, CA 95134 San Jose, CA 95134
USA. USA.
Email: jon.hudson@gmail.com Email: jon.hudson@gmail.com
Naveen Nimmu Naveen Nimmu
Broadcom Broadcom
9th Floor, Building no 9, Raheja Mind space 9th Floor, Building no 9, Raheja Mind space
 End of changes. 31 change blocks. 
68 lines changed or deleted 63 lines changed or added

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