< draft-ietf-bfd-stability-05.txt | draft-ietf-bfd-stability-06.txt > | |||
---|---|---|---|---|
Network Working Group A. Mishra | Network Working Group A. Mishra | |||
Internet-Draft SES | Internet-Draft SES | |||
Intended status: Standards Track M. Jethanandani | Intended status: Standards Track M. Jethanandani | |||
Expires: August 30, 2020 | Expires: January 14, 2021 Kloud Services | |||
A. Saxena | A. Saxena | |||
Ciena Corporation | Ciena Corporation | |||
S. Pallagatti | S. Pallagatti | |||
VmWare | VmWare | |||
M. Chen | M. Chen | |||
Huawei | Huawei | |||
P. Fan | P. Fan | |||
China Mobile | China Mobile | |||
February 27, 2020 | July 13, 2020 | |||
BFD Stability | BFD Stability | |||
draft-ietf-bfd-stability-05 | draft-ietf-bfd-stability-06 | |||
Abstract | Abstract | |||
This document describes extensions to the Bidirectional Forwarding | This document describes extensions to the Bidirectional Forwarding | |||
Detection (BFD) protocol to measure BFD stability. Specifically, it | Detection (BFD) protocol to measure BFD stability. Specifically, it | |||
describes a mechanism for detection of BFD frame loss. | describes a mechanism for detection of BFD packet loss. | |||
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 | 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). 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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 August 30, 2020. | This Internet-Draft will expire on January 14, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
3. BFD Null-Authentication TLV . . . . . . . . . . . . . . . . . 3 | 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Theory of Operations . . . . . . . . . . . . . . . . . . . . 3 | 4. BFD Null-Authentication Type . . . . . . . . . . . . . . . . 3 | |||
4.1. Loss Measurement . . . . . . . . . . . . . . . . . . . . 3 | 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 5.1. Loss Measurement . . . . . . . . . . . . . . . . . . . . 3 | |||
6. Security Consideration . . . . . . . . . . . . . . . . . . . 4 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 | 7. Security Consideration . . . . . . . . . . . . . . . . . . . 4 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
9. Normative References . . . . . . . . . . . . . . . . . . . . 4 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 4 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
1. Introduction | 1. Introduction | |||
The Bidirectional Forwarding Detection ( BFD) [RFC5880] protocol | The Bidirectional Forwarding Detection ( BFD) [RFC5880] protocol | |||
operates by transmitting and receiving control frames, generally at | operates by transmitting and receiving BFD control packets, generally | |||
high frequency, over the datapath being monitored. In order to | at high frequency, over the datapath being monitored. In order to | |||
prevent significant data loss due to a datapath failure, the | prevent significant data loss due to a datapath failure, BFD session | |||
tolerance for lost or delayed frames in the Detection Time, as | detection time as defined in BFD [RFC5880] is set to the smallest | |||
defined in BFD [RFC5880] is set to the smallest feasible value. | feasible value. | |||
This document proposes a mechanism to detect lost frames in a BFD | This document proposes a mechanism to detect lost packet in a BFD | |||
session in addition to the datapath fault detection mechanisms of | session in addition to the datapath fault detection mechanisms of | |||
BFD. Such a mechanism presents significant value to measure the | BFD. Such a mechanism presents significant value to measure the | |||
stability of BFD sessions and provides data to the operators for the | stability of BFD sessions and provides data to the operators for the | |||
cause of a BFD failure. | cause of a BFD failure. | |||
This document does not propose BFD extension to measure data traffic | This document does not propose any BFD extension to measure data | |||
loss or delay on a link or tunnel and the scope is limited to BFD | traffic loss or delay on a link or tunnel and the scope is limited to | |||
frames. | BFD packets. | |||
2. Use Cases | 2. Terminology | |||
Legacy BFD cannot detect any BFD frame loss if loss does not last for | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
dead interval. This draft proposes a method to detect a dropped | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
frame on the receiver. For example, if the receiver receives BFD CC | document are to be interpreted as described in RFC 2119 [RFC2119] and | |||
frame k at time t but receives frame k+3 at time t+10ms, and never | RFC 8174 [RFC8174]. | |||
receives frame k+1 and/or k+2, then it has experienced a drop. | ||||
This proposal enables BFD engine to generate diagnostic information | The reader is expected to be familiar with the BFD [RFC5880], | |||
on the health of each BFD session that could be used to preempt a | Optimizing BFD Authentication | |||
failure on a link that BFD was monitoring by allowing time for a | [I-D.ietf-bfd-optimizing-authentication] and BFD Secure Sequence | |||
corrective action to be taken. | Numbers [I-D.ietf-bfd-secure-sequence-numbers]. | |||
In a faulty datapath scenario, operator can use BFD health | 3. Use Cases | |||
Bidirectional Forwarding Detection as defined in BFD [RFC5880] cannot | ||||
detect any BFD packet loss if loss does not last for detection time. | ||||
This document proposes a method to detect a dropped packet on the | ||||
receiver. For example, if the receiver receives BFD control packet k | ||||
at time t but receives packet k+3 at time t+10ms, and never receives | ||||
packet k+1 and/or k+2, then it has experienced a drop. | ||||
This proposal enables BFD implementation to generate diagnostic | ||||
information on the health of each BFD session that could be used to | ||||
preempt a failure on a link that BFD was monitoring by allowing time | ||||
for a corrective action to be taken. | ||||
In a faulty datapath scenario, an operator can use BFD health | ||||
information to trigger delay and loss measurement OAM protocol | information to trigger delay and loss measurement OAM protocol | |||
(Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay | (Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay | |||
Measurement (DM)) to further isolate the issue. | Measurement (DM)) to further isolate the issue. | |||
3. BFD Null-Authentication TLV | 4. BFD Null-Authentication Type | |||
The functionality proposed for BFD stability measurement is achieved | The functionality proposed for BFD stability measurement is achieved | |||
by appending the Null-Authentication TLV (as defined in Optimizing | by appending the Null-Authentication type (as defined in Optimizing | |||
BFD Authentication [I-D.ietf-bfd-optimizing-authentication] ) to the | BFD Authentication [I-D.ietf-bfd-optimizing-authentication] ) to the | |||
BFD control frame that do not have authentication enabled. | BFD control packets that do not have authentication enabled. | |||
4. Theory of Operations | 5. Theory of Operation | |||
This mechanism allows operator to measure the loss of BFD CC frames. | This mechanism allows operators to measure the loss of BFD control | |||
packets. | ||||
When using MD5 or SHA authentication, BFD uses authentication TLV | When using MD5 or SHA authentication, BFD uses authentication TLV | |||
that carries the Sequence Number. However, if non-meticulous | that carries the Sequence Number. However, if non-meticulous | |||
authentication is being used, or no authentication is in use, then | authentication is being used, or no authentication is in use, then | |||
the non-authenticated BFD frames MUST include NULL-Auth TLV. | the non-authenticated BFD packets MUST include NULL-Auth TLV. | |||
4.1. Loss Measurement | 5.1. Loss Measurement | |||
Loss measurement counts the number of BFD control frames missed at | Loss measurement counts the number of BFD control packets missed at | |||
the receiver during any Detection Time period. The loss is detected | the receiver during any Detection Time period. The loss is detected | |||
by comparing the Sequence Number field in the Auth TLV (NULL or | by comparing the Sequence Number field in the Auth TLV (NULL or | |||
otherwise) in successive BFD CC frames. The Sequence Number in each | otherwise) in successive BFD control packets. The Sequence Number in | |||
successive control frame generated on a BFD session by the | each successive control packet generated on a BFD session by the | |||
transmitter is incremented by one. | transmitter is incremented by one. | |||
The first BFD NULL-Auth TLV processed by the receiver that has a non- | The first BFD NULL-Auth type processed by the receiver that has a | |||
zero sequence number is used for bootstrapping the logic. When using | non-zero sequence number is used for bootstrapping the logic. When | |||
secure sequence numbers, if the expected values are pre-calculated, | using secure sequence numbers, if the expected values are pre- | |||
the matched value must be appropriately recorded to detect lost | calculated, the value must be matched to detect lost packets as | |||
frames. | defined in BFD secure sequence numbers | |||
[I-D.ietf-bfd-secure-sequence-numbers]. | ||||
5. IANA Considerations | 6. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
6. Security Consideration | 7. Security Consideration | |||
Other than concerns raised in BFD [RFC5880] there are no new concerns | Other than concerns raised in BFD [RFC5880], Optimizing BFD | |||
with this proposal. | Authentication [I-D.ietf-bfd-optimizing-authentication] and BFD | |||
Secure Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. | ||||
There are no new concerns with this proposal. | ||||
7. Contributors | 8. Contributors | |||
Manav Bhatia | Manav Bhatia | |||
8. Acknowledgements | 9. Acknowledgements | |||
Authors would like to thank Nobo Akiya, Jeffery Haas, Peng Fan, | Authors would like to thank Nobo Akiya, Jeffery Haas, Peng Fan, | |||
Dileep Singh, Basil Saji, Sagar Soni and Mallik Mudigonda who also | Dileep Singh, Basil Saji, Sagar Soni and Mallik Mudigonda who also | |||
contributed to this document. | contributed to this document. | |||
9. Normative References | 10. Normative References | |||
[I-D.ietf-bfd-optimizing-authentication] | [I-D.ietf-bfd-optimizing-authentication] | |||
Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, | Jethanandani, M., Mishra, A., Saxena, A., and M. Bhatia, | |||
"Optimizing BFD Authentication", draft-ietf-bfd- | "Optimizing BFD Authentication", draft-ietf-bfd- | |||
optimizing-authentication-09 (work in progress), December | optimizing-authentication-09 (work in progress), December | |||
2019. | 2019. | |||
[I-D.ietf-bfd-secure-sequence-numbers] | ||||
Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and | ||||
A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- | ||||
secure-sequence-numbers-05 (work in progress), February | ||||
2020. | ||||
[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-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5880>. | <https://www.rfc-editor.org/info/rfc5880>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
Authors' Addresses | Authors' Addresses | |||
Ashesh Mishra | Ashesh Mishra | |||
SES | SES | |||
Email: mishra.ashesh@gmail.com | Email: mishra.ashesh@gmail.com | |||
Mahesh Jethanandani | Mahesh Jethanandani | |||
Kloud Services | ||||
CA | CA | |||
USA | USA | |||
Email: mjethanandani@gmail.com | Email: mjethanandani@gmail.com | |||
Ankur Saxena | Ankur Saxena | |||
Ciena Corporation | Ciena Corporation | |||
3939 North 1st Street | 3939 North 1st Street | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
USA | USA | |||
End of changes. 33 change blocks. | ||||
63 lines changed or deleted | 87 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |