Internet DRAFT - draft-akiya-bfd-seamless-alert-discrim
draft-akiya-bfd-seamless-alert-discrim
Internet Engineering Task Force N. Akiya
Internet-Draft C. Pignataro
Intended status: Standards Track D. Ward
Expires: April 24, 2015 Cisco Systems
October 21, 2014
Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discriminator
draft-akiya-bfd-seamless-alert-discrim-03
Abstract
This document defines the Alert Discriminator which operates on the
Seamless Bidirectional Forwarding Detection (S-BFD), and Alert
Discriminator Diagnostic Codes which operates on the Alert
Discriminator.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 April 24, 2015.
Copyright Notice
Copyright (c) 2014 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
Akiya, et al. Expires April 24, 2015 [Page 1]
Internet-Draft S-BFD Alert Discriminator October 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extended S-BFD Use Cases . . . . . . . . . . . . . . . . . . 2
2.1. Target S-BFD Discriminator Discovery . . . . . . . . . . 3
2.2. S-BFD Path Tracing . . . . . . . . . . . . . . . . . . . 3
3. Alert Discriminator . . . . . . . . . . . . . . . . . . . . . 4
4. Alert Discriminator Diagnostic Codes . . . . . . . . . . . . 4
4.1. Diagnostic Code: Target S-BFD Discriminator Discovery . . 4
4.2. Diagnostic Code: S-BFD Path Tracing . . . . . . . . . . . 5
4.3. Diagnostic Code: Not Supported . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Alert Discriminator Diagnostic Codes Registry . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[I-D.ietf-bfd-seamless-base] defines the Seamless Bidirectional
Forwarding Detection (S-BFD): a simplified mechanism which uses
Bidirectional Forwarding Detection (BFD) with large portions of
negotiation aspects eliminated.
This document defines the Alert Discriminator which operates on the
S-BFD, and the Alert Discriminator Diagnostic Codes which operates on
the Alert Discriminator, for extended S-BFD use cases described in
Section 2.
2. Extended S-BFD Use Cases
This section describes extended S-BFD use cases.
Akiya, et al. Expires April 24, 2015 [Page 2]
Internet-Draft S-BFD Alert Discriminator October 2014
2.1. Target S-BFD Discriminator Discovery
IS-IS ([I-D.ietf-isis-sbfd-discriminator]) and OSPF
([I-D.ietf-ospf-sbfd-discriminator]) protocols have been extended to
advertise S-BFD discriminator values. These extensions will suffice
for number of scenarios where S-BFD is used to verify the network
reachability to other network devices. Other protocols may be
extended to support S-BFD in further scenarios.
There are, however, some scenarios where it is desirable to have a
mechanism within the S-BFD protocol to discover the target S-BFD
discriminator value.
o In some scenarios, direct protocol communications are
intentionally kept minimal for reasons such as administrative
policy. One such example is the usage of S-BFD across Autonomous
System (AS) boundaries (i.e. inter-AS).
o In some scenarios, there is no control plane which can easily
advertise S-BFD discriminators. MPLS-TP and static routes are
such examples.
o In some scenarios, defining and standardizing protocol extensions
to advertise S-BFD discriminator values may be more work than the
value it brings.
To accommodate the two scenarios described, it is desirable to have a
mechanism within the S-BFD protocol to discover the target S-BFD
discriminator value.
2.2. S-BFD Path Tracing
When a multihop S-BFD session, IP based or MPLS based, determines a
loss of reachability to the target entity, the responsibility of
identifying the problematic point in the paths is often left to
operators. ICMP echo request/reply (IP Ping/Trace) [RFC0792] and
MPLS echo request/reply (LSP Ping/Trace) [RFC4379] allow for tracing
of hops to a specific target, and these are often used by operators,
manually or automatically, to attempt to isolate faults. However,
when it comes to identifying the problematic point that caused the
S-BFD session to declare the failure, there are couple of issues.
o Usage of non-S-BFD packets can result in them being load balanced
differently along the paths, causing those packets to traverse
different paths than S-BFD packets did.
o Usage of non-S-BFD packets may not identify the problematic points
which only affect specific flows (which affects S-BFD packets).
Akiya, et al. Expires April 24, 2015 [Page 3]
Internet-Draft S-BFD Alert Discriminator October 2014
o In order to isolate short lived transient issues, it is desirable
to immediately perform the task of fault isolation. IP/MPLS Ping/
Trace implementations often require more processing overhead than
S-BFD. Usage of heavier tool to attempt to isolate fault can
result in missing more instances of identifying short lived
transient issues.
Although the task of "fault isolation" does not belong in the BFD/
S-BFD protocols, if the task of "fault isolation" can be done with
simple extensions within the S-BFD protocol, the result does provide
additional benefit to operators.
3. Alert Discriminator
This document reserves the value zero of the S-BFD discriminator pool
as the Alert Discriminator. A reflector BFD session is to monitor
incoming S-BFD packets with value zero in the "Your Discriminator"
field. The reflector BFD session is to process the S-BFD packets
according to the value specified in the received "Diagnostic" field.
Procedures specific to each "Diagnostic" code are described in
Section 4.
4. Alert Discriminator Diagnostic Codes
This section defines the Alert Discriminator Diagnostic Codes, and
procedures for each defined code point. The Alert Discriminator
Diagnostic Codes MUST operate on the Alert Discriminator.
Specifically:
o In the direction from an SBFDInitiator to an SBFDReflector, the
Alert Discriminator Diagnostic Codes MUST only be used with "Your
Discriminator" field set to the Alert Discriminator.
o In the direction from an SBFDReflector to an SBFDInitiator, the
Alert Discriminator Diagnostic Code MUST only be used in a reply
S-BFD packet if received S-BFD packet contained "Your
Discriminator" field set to the Alert Discriminator.
4.1. Diagnostic Code: Target S-BFD Discriminator Discovery
The Alert Discriminator Diagnostic Code 29 is defined for the purpose
of discovering the target S-BFD discriminator.
Value Alert Discriminator Diagnostic Code Name
------ ----------------------------------------
29 Target S-BFD Discriminator Discovery
Akiya, et al. Expires April 24, 2015 [Page 4]
Internet-Draft S-BFD Alert Discriminator October 2014
When a reflector BFD session receives an S-BFD packet containing the
Alert Discriminator and the Alert Discriminator Diagnostic Code of
29, then the reflector BFD session SHOULD send a reply S-BFD packet.
The format and the contents of the generated reply S-BFD packet MUST
follow the definition in the S-BFD protocol documents, except for
following fields:
o "My Discriminator" field MUST be set to one of local S-BFD
discriminators.
o "Diagnostic" field MUST be set to value 29.
4.2. Diagnostic Code: S-BFD Path Tracing
The Alert Discriminator Diagnostic Code 30 is defined for the purpose
of S-BFD path tracing.
Value Alert Discriminator Diagnostic Code Name
------ ----------------------------------------
30 S-BFD Path Trace
When a reflector BFD session receives an S-BFD packet containing the
Alert Discriminator and the Alert Discriminator Diagnostic Code of
30, then the reflector BFD session SHOULD send a reply S-BFD packet.
The format and the contents of the generated reply S-BFD packet MUST
follow the definition in the S-BFD protocol documents, except for
following fields:
o "My Discriminator" field MUST be set to zero.
o "Diagnostic" field MUST be set to value 30.
4.3. Diagnostic Code: Not Supported
The Alert Discriminator Diagnostic Code 31 is defined for a reflector
BFD session to communicate, in reply S-BFD packet, that specified
Alert Discriminator Diagnostic Code in received S-BFD packet is not
understood or is not supported.
Value Alert Discriminator Diagnostic Code Name
------ ----------------------------------------
31 Not Supported
When a reflector BFD session receives an S-BFD packet containing the
Alert Discriminator and an Alert Discriminator Diagnostic Code which
is not understood or supported by the reflector BFD session, then the
reflector BFD session SHOULD send a reply S-BFD packet. The format
and the contents of the generated reply S-BFD packet MUST follow the
Akiya, et al. Expires April 24, 2015 [Page 5]
Internet-Draft S-BFD Alert Discriminator October 2014
definition in the S-BFD protocol documents, except for following
fields:
o "My Discriminator" field MUST be set to zero.
o "Diagnostic" field MUST be set to value 31.
Note that in the direction from an SBFDInitiator to an SBFDReflector,
the Alert Discriminator Diagnostic Code 31 MUST NOT be used. If a
reflector BFD session receives an S-BFD packet with the Alert
Discriminator and the Alert Discriminator Diagnostic Code 31, then
the reflector BFD session MUST drop the packet.
5. Security Considerations
Conceptually the Alert Discriminator is similar to an IP Router Alert
Option or an MPLS Router Alert Label. The Alert Discriminator
introduces a way which remote network devices can instruct a
reflector BFD sessions to perform specific tasks corresponding to
specified Alert Discriminator Diagnostic Codes, and without remote
network devices knowing a valid S-BFD discriminator on the target
device. Hence, it is very critical that reflector BFD session
services the Alert Discriminator only from trusted sources and for
allowed Alert Diagnostic Codes for those sources. Therefore, this
document RECOMMENDS following security procedures to be implemented:
o S-BFD packets with Alert Discriminator is accepted only from
trusted sources. An implementation SHOULD provide a mechanism for
operators to specify an access-list to describe the trusted
sources.
o An implementation SHOULD provide a mechanism for operators to
specify the Alert Discriminator Diagnostic Codes which are
supported on the device. If required, such configuration should
be set per a trusted source.
Additionally, it is RECOMMENDED that implementations supporting the
Alert Discriminator considers the security considerations described
in [I-D.ietf-bfd-seamless-base], [I-D.ietf-bfd-seamless-ip] and
[I-D.akiya-bfd-seamless-sr] documents.
6. IANA Considerations
This document requests IANA to create a new registry within
[IANA-BFD] protocol to maintain "Alert Discriminator Diagnostic
Codes" field. Initial values are described in immediate sub-section
to follow.
Akiya, et al. Expires April 24, 2015 [Page 6]
Internet-Draft S-BFD Alert Discriminator October 2014
6.1. Alert Discriminator Diagnostic Codes Registry
The IANA is requested to create and maintain a registry entitled
"Alert Discriminator Diagnostic Codes" with the following
registration procedures:
Registry Name: Alert Discriminator Diagnostic Codes
Value Alert Discriminator Diagnostic Code Name Reference
------ ---------------------------------------- -------------
0-7 Experimental This document
8-28 Reserved This document
29 Target S-BFD Discriminator Discovery This document
30 S-BFD Path Trace This document
31 Not Supported This document
Assignments of Alert Discriminator Diagnostic Codes are via Standards
Action [RFC5226].
7. Acknowledgements
Authors would like to thank Srihari Raghavan and Girija Raghavendra
Rao for reviewing and providing comments on this document.
8. Contributing Authors
Nagendra Kumar
Cisco Systems
Email: naikumar@cisco.com
Mallik Mudigonda
Cisco Systems
Email: mmudigon@cisco.com
Aswatnarayan Raghuram
AT&T
Email: ar2521@att.com
Glenward D. Hayden
AT&T
Email: gh1691@att.com
9. References
Akiya, et al. Expires April 24, 2015 [Page 7]
Internet-Draft S-BFD Alert Discriminator October 2014
9.1. Normative References
[I-D.akiya-bfd-seamless-sr]
Akiya, N., Pignataro, C., and N. Kumar, "Seamless
Bidirectional Forwarding Detection (S-BFD) for Segment
Routing", draft-akiya-bfd-seamless-sr-03 (work in
progress), August 2014.
[I-D.ietf-bfd-seamless-base]
Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
Networks, "Seamless Bidirectional Forwarding Detection
(S-BFD)", draft-ietf-bfd-seamless-base-03 (work in
progress), August 2014.
[I-D.ietf-bfd-seamless-ip]
Akiya, N., Pignataro, C., and D. Ward, "Seamless
Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6
and MPLS", draft-ietf-bfd-seamless-ip-00 (work in
progress), September 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.ietf-isis-sbfd-discriminator]
Ginsberg, L., Akiya, N., and M. Chen, "Advertising S-BFD
Discriminators in IS-IS", draft-ietf-isis-sbfd-
discriminator-01 (work in progress), October 2014.
[I-D.ietf-ospf-sbfd-discriminator]
Bhatia, M., Pignataro, C., Aldrin, S., and T. Ranganath,
"OSPF extensions to advertise S-BFD Target Discriminator",
draft-ietf-ospf-sbfd-discriminator-00 (work in progress),
September 2014.
[IANA-BFD]
IANA, "Bidirectional Forwarding Detection (BFD)
Parameters", <http://www.iana.org/assignments/bfd-
parameters/bfd-parameters.xhtml>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
Akiya, et al. Expires April 24, 2015 [Page 8]
Internet-Draft S-BFD Alert Discriminator October 2014
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
Nobo Akiya
Cisco Systems
Email: nobo@cisco.com
Carlos Pignataro
Cisco Systems
Email: cpignata@cisco.com
Dave Ward
Cisco Systems
Email: wardd@cisco.com
Akiya, et al. Expires April 24, 2015 [Page 9]
