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/