draft-ietf-bfd-rfc5884-clarifications-00.txt | draft-ietf-bfd-rfc5884-clarifications-01.txt | |||
---|---|---|---|---|
Internet Engineering Task Force V. Govindan | Internet Engineering Task Force V. Govindan | |||
Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
Updates: 5884 (if approved) K. Rajaraman | Updates: 5884 (if approved) K. Rajaraman | |||
Intended status: Standards Track G. Mirsky | Intended status: Standards Track G. Mirsky | |||
Expires: July 19, 2015 Ericsson | Expires: September 06, 2015 Ericsson | |||
N. Akiya | N. Akiya | |||
Cisco Systems | ||||
S. Aldrin | S. Aldrin | |||
Huawei Technologies | Huawei Technologies | |||
January 15, 2015 | March 05, 2015 | |||
Clarifications to RFC 5884 | Clarifications to RFC 5884 | |||
draft-ietf-bfd-rfc5884-clarifications-00 | draft-ietf-bfd-rfc5884-clarifications-01 | |||
Abstract | Abstract | |||
This document clarifies the procedures for establishing, maintaining | This document clarifies the procedures for establishing, maintaining | |||
and removing multiple, concurrent BFD sessions for a given <MPLS LSP, | and removing multiple, concurrent BFD sessions for a given <MPLS LSP, | |||
FEC> described in RFC5884. | FEC> described in RFC5884. | |||
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 | |||
skipping to change at page 1, line 38 | skipping to change at page 1, line 37 | |||
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 July 19, 2015. | This Internet-Draft will expire on September 06, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 16 | skipping to change at page 2, line 15 | |||
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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 | |||
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 | 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Procedures for establishment of multiple BFD sessions . . 3 | 2.1. Procedures for establishment of multiple BFD sessions . . 3 | |||
2.2. Procedures for maintenance of multiple BFD sessions . . . 3 | 2.2. Procedures for maintenance of multiple BFD sessions . . . 3 | |||
2.3. Procedures for removing BFD sessions at the egress LSR . 3 | 2.3. Procedures for removing BFD sessions at the egress LSR . 4 | |||
2.4. Changing discriminators for a BFD session . . . . . . . . 4 | 2.4. Changing discriminators for a BFD session . . . . . . . . 4 | |||
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 4 | 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 4 | |||
4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . 5 | 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1. Background | 1. Background | |||
[RFC5884] defines the procedures to bootstrap and maintain BFD | [RFC5884] defines the procedures to bootstrap and maintain BFD | |||
sessions for a <MPLS FEC, LSP> using LSP ping. While Section 4 of | sessions for a <MPLS FEC, LSP> using LSP ping. While Section 4 of | |||
[RFC5884] specifies that multiple BFD sessions can be established for | [RFC5884] specifies that multiple BFD sessions can be established for | |||
a <MPLS FEC, LSP> tuple, the procedures to bootstrap and maintain | a <MPLS FEC, LSP> tuple, the procedures to bootstrap and maintain | |||
multiple BFD sessions concurrently over a <MPLS FEC, LSP> are not | multiple BFD sessions concurrently over a <MPLS FEC, LSP> are not | |||
clearly specified. Additionally, the procedures of removing BFD | clearly specified. Additionally, the procedures of removing BFD | |||
sessions bootstrapped on the egress LSR are unclear. This document | sessions bootstrapped on the egress LSR are unclear. This document | |||
skipping to change at page 3, line 34 | skipping to change at page 3, line 34 | |||
given <MPLS FEC, LSP>. Each LSP ping MUST carry a different | given <MPLS FEC, LSP>. Each LSP ping MUST carry a different | |||
discriminator value in the BFD discriminator TLV [RFC4379]. | discriminator value in the BFD discriminator TLV [RFC4379]. | |||
The egress LSR needs to perform the following: | The egress LSR needs to perform the following: | |||
If the validation of the FEC in the MPLS Echo request message | If the validation of the FEC in the MPLS Echo request message | |||
succeeds, check the discriminator specified in the BFD | succeeds, check the discriminator specified in the BFD | |||
discriminator TLV of the MPLS Echo request. If there is no local | discriminator TLV of the MPLS Echo request. If there is no local | |||
session that corresponds to the discriminator (remote) received in | session that corresponds to the discriminator (remote) received in | |||
the MPLS Echo request, a new session is bootstrapped and a local | the MPLS Echo request, a new session is bootstrapped and a local | |||
discriminator is allocated. Since the BFD local discriminator of | discriminator is allocated. The validation of a FEC is a | |||
either ends cannot change as long as the session is in the UP | necessary condition to be satisfied to create a new BFD session at | |||
state, a new discriminator received in the LSP ping unambiguously | the egress LSR. However, the policy or procedure if any, to be | |||
conveys the intent of the LSR ingress to bootstrap a new BFD | applied by the egress LSR before allowing a new BFD session to be | |||
session for the FEC specified in the LSP ping. | created is outside the scope of this document. Such policies or | |||
procedures could consider availability of system resources before | ||||
allowing a session to be created. When the egress LSR disallows | ||||
the creation of a BFD session due to policy, it MUST drop the MPLS | ||||
Echo request message. | ||||
Ensure the uniqueness of the <MPLS FEC, LSP, Remote | Ensure the uniqueness of the <MPLS FEC, LSP, Remote | |||
Discriminiator> tuple. | Discriminiator> tuple. | |||
The remaining procedures of session establishment are as specified | The remaining procedures of session establishment are as specified | |||
in [RFC5884]. | in [RFC5884]. | |||
2.2. Procedures for maintenance of multiple BFD sessions | 2.2. Procedures for maintenance of multiple BFD sessions | |||
Both the ingress LSR and egress LSR use the YourDiscriminator of the | Both the ingress LSR and egress LSR use the YourDiscriminator of the | |||
received BFD packet to demultiplex BFD sessions. | received BFD packet to demultiplex BFD sessions. | |||
2.3. Procedures for removing BFD sessions at the egress LSR | 2.3. Procedures for removing BFD sessions at the egress LSR | |||
[RFC5884] does not specify an explicit procedure for deleting BFD | [RFC5884] does not specify an explicit procedure for deleting BFD | |||
sessions. The procedure for removing a BFD session established by an | sessions. The procedure for removing a BFD session established by an | |||
out-of-band discriminator exchange using the MPLS LSP ping can | out-of-band discriminator exchange using the MPLS LSP ping can | |||
improve resource management (like memory etc.) especially in | improve resource management (like memory etc.) especially in | |||
scenarios involving thousands or more of such sessions. A few | scenarios involving thousands or more of such sessions. A few | |||
skipping to change at page 4, line 17 | skipping to change at page 4, line 21 | |||
out-of-band discriminator exchange using the MPLS LSP ping can | out-of-band discriminator exchange using the MPLS LSP ping can | |||
improve resource management (like memory etc.) especially in | improve resource management (like memory etc.) especially in | |||
scenarios involving thousands or more of such sessions. A few | scenarios involving thousands or more of such sessions. A few | |||
options are possible here: | options are possible here: | |||
The BFD session MAY be removed in the egress LSR if the BFD | The BFD session MAY be removed in the egress LSR if the BFD | |||
session transitions from UP to DOWN. This can be done after the | session transitions from UP to DOWN. This can be done after the | |||
expiry of a configurable timer started after the BFD session state | expiry of a configurable timer started after the BFD session state | |||
transitions from UP to DOWN at the egress LSR. | transitions from UP to DOWN at the egress LSR. | |||
The BFD session on the egress LSR MAY be gracefully removed by the | The BFD session on the egress LSR MAY be removed by the ingress | |||
ingress LSR by using the BFD diagnostic code AdminDown(7) | LSR by using the BFD diagnostic code AdminDown(7) as specified in | |||
specified in [RFC5880]. When the ingress LSR wants to gracefully | [RFC5880]. When the ingress LSR wants to remove a session without | |||
remove a session, it MAY transmit BFD packets containing the | triggering any state change at the egress, it MAY transmit BFD | |||
diagnostic code AdminDown(7) detectMultiplier number of times. | packets indicating the State as Down(1), diagnostic code | |||
Upon receiving such a packet, the egress LSR MAY remove the BFD | AdminDown(7) detectMultiplier number of times. Upon receiving | |||
session gracefully, without triggering a change of state. | such a packet, the egress LSR MAY remove the BFD session, without | |||
triggering a change of state. | ||||
Ed Note: The procedures to be followed at the egress LSR when the BFD | The procedures to be followed at the egress LSR when BFD | |||
session never transitions to UP from DOWN state are yet to be | session(s) remain in the DOWN state for a significant amount of | |||
clarified | time is a local matter. Such procedures are outside the scope of | |||
this document. | ||||
Regardless of the option chosen to proceed, all BFD sessions | All BFD sessions established with the FEC MUST be removed | |||
established with the FEC MUST be removed automatically if the FEC is | automatically if the FEC is removed. | |||
removed. | ||||
2.4. Changing discriminators for a BFD session | 2.4. Changing discriminators for a BFD session | |||
The discriminators of a BFD session established over an MPLS LSP | The discriminators of a BFD session established over an MPLS LSP | |||
cannot be changed when it is in UP state. The BFD session could be | cannot be changed when it is in UP state. The BFD session could be | |||
removed after a graceful transition to AdminDown state using the BFD | removed after a graceful transition to AdminDown state using the BFD | |||
diagnostic code AdminDown. A new session could be established with a | diagnostic code AdminDown. A new session could be established with a | |||
different discriminator. The initiation of the transition from the | different discriminator. The initiation of the transition from the | |||
Up to Down state can be done either by the ingress LSR or the egress | Up to Down state can be done either by the ingress LSR or the egress | |||
LSR. | LSR. | |||
skipping to change at page 5, line 26 | skipping to change at page 5, line 32 | |||
sessions are provisioned per FEC, and bootstrapped BFD sessions are | sessions are provisioned per FEC, and bootstrapped BFD sessions are | |||
properly deleted when no longer required. Additionally security | properly deleted when no longer required. Additionally security | |||
measures described in [RFC4379] and [RFC5884] are to be followed. | measures described in [RFC4379] and [RFC5884] are to be followed. | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document does not make any requests to IANA. | This document does not make any requests to IANA. | |||
7. Acknowledgements | 7. Acknowledgements | |||
The authors would like to thank Marc Binderberger for performing | ||||
thorough reviews and providing valuable suggestions. | ||||
The authors would like to thank Mudigonda Mallik, Rajaguru Veluchamy | The authors would like to thank Mudigonda Mallik, Rajaguru Veluchamy | |||
and Carlos Pignataro of Cisco Systems for their review comments. | and Carlos Pignataro of Cisco Systems for their review comments. | |||
8. Normative References | 8. 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. | |||
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol | [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol | |||
Label Switched (MPLS) Data Plane Failures", RFC 4379, | Label Switched (MPLS) Data Plane Failures", RFC 4379, | |||
skipping to change at page 6, line 15 | skipping to change at page 6, line 27 | |||
Ericsson | Ericsson | |||
Email: kalyani.rajaraman@ericsson.com | Email: kalyani.rajaraman@ericsson.com | |||
Gregory Mirsky | Gregory Mirsky | |||
Ericsson | Ericsson | |||
Email: gregory.mirsky@ericsson.com | Email: gregory.mirsky@ericsson.com | |||
Nobo Akiya | Nobo Akiya | |||
Cisco Systems | ||||
Email: nobo@cisco.com | Email: nobo.akiya.dev@gmail.com | |||
Sam Aldrin | Sam Aldrin | |||
Huawei Technologies | Huawei Technologies | |||
Email: aldrin.ietf@gmail.com | Email: aldrin.ietf@gmail.com | |||
End of changes. 15 change blocks. | ||||
28 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |