--- 1/draft-ietf-bfd-seamless-base-03.txt 2015-01-12 03:14:56.346664359 -0800 +++ 2/draft-ietf-bfd-seamless-base-04.txt 2015-01-12 03:14:56.426666327 -0800 @@ -1,23 +1,23 @@ Internet Engineering Task Force N. Akiya Internet-Draft C. Pignataro Updates: 5880 (if approved) D. Ward Intended status: Standards Track Cisco Systems -Expires: February 24, 2015 M. Bhatia +Expires: July 16, 2015 M. Bhatia Ionos Networks S. Pallagatti Juniper Networks - August 23, 2014 + January 12, 2015 Seamless Bidirectional Forwarding Detection (S-BFD) - draft-ietf-bfd-seamless-base-03 + draft-ietf-bfd-seamless-base-04 Abstract This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. @@ -36,25 +36,25 @@ 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 February 24, 2015. + This Internet-Draft will expire on July 16, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 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 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 @@ -66,64 +66,64 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Seamless BFD Overview . . . . . . . . . . . . . . . . . . . . 4 4. S-BFD Discriminators . . . . . . . . . . . . . . . . . . . . 5 4.1. S-BFD Discriminator Uniqueness . . . . . . . . . . . . . 5 4.2. Discriminator Pools . . . . . . . . . . . . . . . . . . . 6 5. Reflector BFD Session . . . . . . . . . . . . . . . . . . . . 7 6. State Variables . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. New State Variables . . . . . . . . . . . . . . . . . . . 7 6.2. State Variable Initialization and Maintenance . . . . . . 8 7. S-BFD Procedures . . . . . . . . . . . . . . . . . . . . . . 8 - 7.1. S-BFD Control Packet Demultiplexing . . . . . . . . . . . 8 - 7.2. Initiator Procedures . . . . . . . . . . . . . . . . . . 8 - 7.2.1. SBFDInitiator State Machine . . . . . . . . . . . . . 9 - 7.2.2. Details of S-BFD Control Packet Sent by SBFDInitiator 10 - 7.3. Responder Procedures . . . . . . . . . . . . . . . . . . 10 - 7.3.1. Responder Demultiplexing . . . . . . . . . . . . . . 11 - 7.3.2. Details of S-BFD Control Packet Sent by SBFDReflector 11 - 7.4. Diagnostic Values . . . . . . . . . . . . . . . . . . . . 11 - 7.5. The Poll Sequence . . . . . . . . . . . . . . . . . . . . 11 - 7.6. Control Plane Independent (C) . . . . . . . . . . . . . . 12 - 7.7. Additional SBFDInitiator Behaviors . . . . . . . . . . . 12 - 7.8. Additional SBFDReflector Behaviors . . . . . . . . . . . 12 - 8. Scaling Aspect . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Co-existence with Classical BFD Sessions . . . . . . . . . . 13 - 10. S-BFD Echo Function . . . . . . . . . . . . . . . . . . . . . 13 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 15.2. Informative References . . . . . . . . . . . . . . . . . 16 - Appendix A. Loop Problem . . . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.1. Demultiplexing of S-BFD Control Packet . . . . . . . . . 8 + 7.2. Initiator Procedures . . . . . . . . . . . . . . . . . . 9 + 7.2.1. SBFDInitiator State Machine . . . . . . . . . . . . . 10 + 7.2.2. Transmission of S-BFD Control Packet by SBFDInitiator 10 + 7.3. Responder Procedures . . . . . . . . . . . . . . . . . . 12 + 7.3.1. Responder Demultiplexing . . . . . . . . . . . . . . 12 + 7.3.2. Transmission of S-BFD Control Packet by SBFDReflector 13 + 7.4. Diagnostic Values . . . . . . . . . . . . . . . . . . . . 14 + 7.5. The Poll Sequence . . . . . . . . . . . . . . . . . . . . 14 + 7.6. Control Plane Independent (C) . . . . . . . . . . . . . . 15 + 7.7. Additional SBFDInitiator Behaviors . . . . . . . . . . . 15 + 7.8. Additional SBFDReflector Behaviors . . . . . . . . . . . 15 + 8. Scaling Aspect . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Co-existence with Classical BFD Sessions . . . . . . . . . . 16 + 10. S-BFD Echo Function . . . . . . . . . . . . . . . . . . . . . 16 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 15.2. Informative References . . . . . . . . . . . . . . . . . 19 + Appendix A. Loop Problem . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Bidirectional Forwarding Detection (BFD), [RFC5880] and related documents, has efficiently generalized the failure detection mechanism for multiple protocols and applications. There are some improvements which can be made to better fit existing technologies. There is a possibility of evolving BFD to better fit new technologies. This document focuses on several aspects of BFD in order to further improve efficiency, to expand failure detection coverage and to allow BFD usage for wider scenarios. This document extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case]. One key aspect of the mechanism described in this document eliminates the time between a network node wanting to perform a continuity test and completing the continuity test. In traditional BFD terms, the initial state changes from DOWN to UP are virtually nonexistent. - Removal of this seam (i.e. time delay) in BFD provides applications a - smooth and continuous operational experience. Therefore, "Seamless + Removal of this seam (i.e., time delay) in BFD provides applications + a smooth and continuous operational experience. Therefore, "Seamless BFD" (S-BFD) has been chosen as the name for this mechanism. 2. Terminology The reader is expected to be familiar with the BFD, IP and MPLS terminologies and protocol constructs. This section describes several new terminologies introduced by S-BFD. o Classical BFD - BFD session types based on [RFC5880]. @@ -131,21 +131,21 @@ o S-BFD control packet - a BFD control packet for the S-BFD mechanism. o S-BFD echo packet - a BFD echo packet for the S-BFD mechanism. o S-BFD packet - a BFD control packet or a BFD echo packet. o Entity - a function on a network node that S-BFD mechanism allows remote network nodes to perform continuity test to. An entity can - be abstract (ex: reachability) or specific (ex: IP addresses, + be abstract (e.g., reachability) or specific (e.g., IP addresses, router-IDs, functions). o SBFDInitiator - an S-BFD session on a network node that performs a continuity test to a remote entity by sending S-BFD packets. o SBFDReflector - an S-BFD session on a network node that listens for incoming S-BFD control packets to local entities and generates response S-BFD control packets. o Reflector BFD session - synonymous with SBFDReflector. @@ -177,26 +177,26 @@ | | | +--------+ | +---------------------+ +------------------------+ Figure 1: S-BFD Terminology Relationship 3. Seamless BFD Overview An S-BFD module on each network node allocates one or more S-BFD discriminators for local entities, and creates a reflector BFD session. Allocated S-BFD discriminators may be advertised by - applications (ex: OSPF/IS-IS). Required result is that applications, - on other network nodes, possess the knowledge of the mapping from - remote entities to S-BFD discriminators. The reflector BFD session - is to, upon receiving an S-BFD control packet targeted to one of - local S-BFD discriminator values, transmit a response S-BFD control - packet back to the initiator. + applications (e.g., OSPF/IS-IS). Required result is that + applications, on other network nodes, possess the knowledge of the + mapping from remote entities to S-BFD discriminators. The reflector + BFD session is to, upon receiving an S-BFD control packet targeted to + one of local S-BFD discriminator values, transmit a response S-BFD + control packet back to the initiator. Once above setup is complete, any network nodes, having the knowledge of the mapping from a remote entity to an S-BFD discriminator, can quickly perform a continuity test to the remote entity by simply sending S-BFD control packets with corresponding S-BFD discriminator value in the "your discriminator" field. For example: <------- IS-IS Network -------> @@ -263,51 +263,51 @@ o SBFDReflector is to allocate a discriminator from the S-BFD discriminator pool. The S-BFD discriminator pool SHOULD be a separate pool than the BFD discriminator pool. Remainder of this subsection describes the reasons for above suggestions. Locally allocated S-BFD discriminator values for entities, listened by SBFDReflector sessions, may be arbitrary allocated or derived from values provided by applications. These values may be protocol IDs - (ex: System-ID, Router-ID) or network targets (ex: IP address). To - avoid derived S-BFD discriminator values already being assigned to - other BFD sessions (i.e. SBFDInitiator sessions and classical BFD + (e.g., System-ID, Router-ID) or network targets (e.g., IP address). + To avoid derived S-BFD discriminator values already being assigned to + other BFD sessions (i.e., SBFDInitiator sessions and classical BFD sessions), it is RECOMMENDED that discriminator pool for SBFDReflector sessions be separate from other BFD sessions. Even when following the separate discriminator pool approach, collision is still possible between one S-BFD application to another S-BFD application, that may be using different values and algorithms to derive S-BFD discriminator values. If the two applications are - using S-BFD for a same purpose (ex: network reachability), then the + using S-BFD for a same purpose (e.g., network reachability), then the colliding S-BFD discriminator value can be shared. If the two applications are using S-BFD for a different purpose, then the collision must be addressed. How such collisions are addressed is outside the scope of this document. 5. Reflector BFD Session Each network node creates one or more reflector BFD sessions. This reflector BFD session is a session which transmits S-BFD control packets in response to received S-BFD control packets with "your discriminator" having S-BFD discriminators allocated for local entities. Specifically, this reflector BFD session is to have following characteristics: o MUST NOT transmit any S-BFD packets based on local timer expiry. o MUST transmit an S-BFD control packet in response to a received S-BFD control packet having a valid S-BFD discriminator in the "your discriminator" field, unless prohibited by local policies - (ex: administrative, security, rate-limiter, etc). + (e.g., administrative, security, rate-limiter, etc). o MUST be capable of sending only two states: UP and ADMINDOWN. One reflector BFD session may be responsible for handling received S-BFD control packets targeted to all locally allocated S-BFD discriminators, or few reflector BFD sessions may each be responsible for subset of locally allocated S-BFD discriminators. This policy is a local matter, and is outside the scope of this document. Note that incoming S-BFD control packets may be IPv4, IPv6 or MPLS @@ -345,38 +345,57 @@ Some state variables defined in section 6.8.1 of the BFD base specification need to be initialized or manipulated differently depending on the session type. o bfd.DemandMode: This variable MUST be initialized to 1 for session type SBFDInitiator, and MUST be initialized to 0 for session type SBFDReflector. 7. S-BFD Procedures -7.1. S-BFD Control Packet Demultiplexing +7.1. Demultiplexing of S-BFD Control Packet - Received BFD control packet MUST first be demultiplexed with - information from the lower layer (ex: destination UDP port, - associated channel type). If the packet is determined to be for an - SBFDReflector, then the packet MUST be looked up to locate a - corresponding SBFDReflector session based on the value from the "your - discriminator" field in the table describing S-BFD discriminators. - If the packet is determined not to be for SBFDReflector, then the - packet MUST be looked up to locate a corresponding SBFDInitiator - session or classical BFD session based on the value from the "your - discriminator" field in the table describing BFD discriminators. If - the located session is a SBFDInitiator, then destination of the - packet (i.e. destination IP address) SHOULD be validated to be for - self. + S-BFD packet MUST be demultiplexed with lower layer information + (e.g., dedicated destination UDP port, associated channel type). + Following procedure SHOULD be executed on both initiator and + reflector. - Details of the initial BFD control packet demultiplexing are - described in relevant S-BFD data plane documents. + If S-BFD packet + + If S-BFD packet is for SBFDReflector + + Packet MUST be looked up to locate a corresponding + SBFDReflector session based on the value from the "your + discriminator" field in the table describing S-BFD + discriminators. + + Else + + Packet MUST be looked up to locate a corresponding + SBFDInitiator session or classical BFD session based on the + value from the "your discriminator" field in the table + describing BFD discriminators. + + If session is SBFDInitiator + Destination of the packet (i.e., destination IP address) + SHOULD be validated to be for self. + + Else + + Packet MUST be discarded + + Else + + Procedure described in [RFC5880] MUST be applied. + + More details on S-BFD control packet demultiplexing are described in + relevant S-BFD data plane documents. 7.2. Initiator Procedures S-BFD control packets transmitted by an SBFDInitiator MUST set "your discriminator" field to an S-BFD discriminator corresponding to the remote entity. Every SBFDInitiator MUST have a locally unique "my discriminator" allocated from the BFD discriminator pool. @@ -406,21 +425,21 @@ 7.2.1. SBFDInitiator State Machine An SBFDInitiator may be a persistent session on the initiator with a timer for S-BFD control packet transmissions (stateful SBFDInitiator). An SBFDInitiator may also be a module, a script or a tool on the initiator that transmits one or more S-BFD control packets "when needed" (stateless SBFDInitiator). For stateless SBFDInitiators, a complete BFD state machine may not be applicable. For stateful SBFDInitiators, the states and the state machine described in [RFC5880] will not function due to SBFDReflector session - only sending UP and ADMINDOWN states (i.e. SBFDReflector session + only sending UP and ADMINDOWN states (i.e., SBFDReflector session does not send INIT state). The following diagram provides the RECOMMENDED state machine for stateful SBFDInitiators. The notation on each arc represents the state of the SBFDInitiator (as received in the State field in the S-BFD control packet) or indicates the expiration of the Detection Timer. +--+ ADMIN DOWN, | | TIMER | V +------+ UP +------+ @@ -433,78 +452,207 @@ Figure 4: SBFDInitiator FSM Note that the above state machine is different from the base BFD specification[RFC5880]. This is because the INIT state is no longer applicable for the SBFDInitiator. Another important difference is the transition of the state machine from the DOWN state to the UP state when a packet with State UP is received by the SBFDInitiator. The definitions of the states and the events have the same meaning as in the base BFD specification [RFC5880]. -7.2.2. Details of S-BFD Control Packet Sent by SBFDInitiator +7.2.2. Transmission of S-BFD Control Packet by SBFDInitiator - S-BFD control packets sent by an SBFDInitiator is to have following - contents: + Contents of S-BFD control packets sent by an SBFDInitiator MUST be + set as follows: - o "my discriminator" assigned by local node. - o "your discriminator" corresponding to a remote entity. - o "State" MUST be set to a value describing local state. - o "Desired Min TX Interval" MUST be set to a value describing local - desired minimum transmit interval. - o "Required Min RX Interval" MUST be zero. - o "Required Min Echo RX Interval" SHOULD be zero. - o "Detection Multiplier" MUST be set to a value describing locally - used multiplier value. - o Demand (D) bit MUST be set. + Version + + Set to the current version number (1). + + Diagnostic (Diag) + MAY be set to appropriate value for communicating with peer. + + State (Sta) + + Set to the value indicated by local state. + + Poll (P) + + Set to 1 if the local system is sending a Poll Sequence. + + Final (F) + + Set to 1 if the local system is responding to a Control packet + received with the Poll (P) bit set, or 0 if not. + + Control Plane Independent (C) + + Set to 1 if the local system's BFD implementation is + independent of the control plane (it can continue to function + through a disruption of the control plane.) + + Authentication Present (A) + + Set to 1 if authentication is in use on this session + (bfd.AuthType is nonzero), or 0 if not. + + Demand (D) + + MUST be set always. + + Multipoint (M) + + MUST be set to 0. + + Detect Mult + + MUST be set to a value describing locally used multiplier + value. + + Length + + Set to the appropriate length, based on the fixed header length + (24) plus any Authentication Section. + + My Discriminator + + Set to value assigned by local node. + + Your Discriminator + + Set to value corresponding to remote entity. + + Desired Min TX Interval + + MUST be set to a value describing local desired minimum + transmit interval. + + Required Min RX Interval + + MUST be set to 0. + + Required Min Echo RX Interval + + MUST be set to 0. 7.3. Responder Procedures A network node which receives S-BFD control packets transmitted by an initiator is referred as responder. The responder, upon reception of S-BFD control packets, is to perform necessary relevant validations described in [RFC5880], [RFC5881], [RFC5883], [RFC5884] and [RFC5885]. 7.3.1. Responder Demultiplexing - When a responder receives an S-BFD control packet, if the value in - the "your discriminator" field is not one of S-BFD discriminators - allocated for local entities, then this packet MUST NOT be considered - for this mechanism. If the value in the "your discriminator" field - is one of S-BFD discriminators allocated for local entities, then the - packet is determined to be handled by a reflector BFD session - responsible for the S-BFD discriminator. If the packet was - determined to be processed further for this mechanism, then chosen - reflector BFD session is to transmit a response BFD control packet - using procedures described in Section 7.3.2, unless prohibited by - local policies (ex: administrative, security, rate-limiter, etc). + S-BFD packet MUST be demultiplexed with lower layer information + (e.g., dedicated destination UDP port, associated channel type). + Following procedure SHOULD be executed by responder: -7.3.2. Details of S-BFD Control Packet Sent by SBFDReflector + If "your discriminator" not one of the entry allocated for local + entities - S-BFD control packets sent by an SBFDReflector is to have following - contents: + Packet MUST NOT be considered for this mechanism. - o "my discriminator" MUST be copied from received "your - discriminator". - o "your discriminator" MUST be copied from received "my - discriminator". - o "State" MUST be UP or ADMINDOWN. Clarification of reflector BFD + Else + + Packet is determined to be handled by a reflector BFD session + responsible for that S-BFD discriminator. + + If local policy allows (e.g., administrative, security, rate- + limiter, etc) + + Chosen reflector BFD session SHOULD transmit a response BFD + control packet using procedures described in Section 7.3.2. + +7.3.2. Transmission of S-BFD Control Packet by SBFDReflector + + Contents of S-BFD control packets sent by an SBFDReflector MUST be + set as follows: + + Version + + Set to the current version number (1). + + Diagnostic (Diag) + + MAY be set to appropriate value for communicating with peer. + + State (Sta) + + MUST be set to UP or ADMINDOWN. Clarification of reflector BFD session state is described in Section 7.8. - o "Desired Min TX Interval" MUST be copied from received "Desired - Min TX Interval". - o "Required Min RX Interval" MUST be set to a value describing how - many incoming control packets this reflector BFD session can - handle. Further details are described in Section 7.8. - o "Required Min Echo RX Interval" SHOULD be set to zero. - o "Detection Multiplier" MUST be copied from received "Detection - Multiplier". - o Demand (D) bit MUST be cleared. + + Poll (P) + + Set to 1 if the local system is sending a Poll Sequence, or 0 + if not. + + Final (F) + + Set to 1 if the local system is responding to a Control packet + received with the Poll (P) bit set, or 0 if not. + + Control Plane Independent (C) + + Set to 1 if the local system's BFD implementation is + independent of the control plane (it can continue to function + through a disruption of the control plane.) + + Authentication Present (A) + + Set to 1 if authentication is in use on this session + (bfd.AuthType is nonzero), or 0 if not. + + Demand (D) + + MUST be cleared. + + Multipoint (M) + + MUST be set to 0. + + Detect Mult + MUST be copied from received "Detection Multiplier". + + Length + + Set to the appropriate length, based on the fixed header length + (24) plus any Authentication Section. + + My Discriminator + + MUST be copied from received "your discriminator". + + Your Discriminator + + MUST be copied from received "my discriminator". + + Desired Min TX Interval + + MUST be copied from received "Desired Min TX Interval". + + Required Min RX Interval + + MUST be set to a value describing how many incoming control + packets this reflector BFD session can handle. Further details + are described in Section 7.8. + + Required Min Echo RX Interval + + If device supports looping back S-BFD echo packets + + MUST set non-zero value desired by local device. + + Else + + MUST be set to 0. 7.4. Diagnostic Values Diagnostic value in both directions MAY be set to a certain value, to attempt to communicate further information to both ends. However, details of such are outside the scope of this specification. 7.5. The Poll Sequence Poll sequence MAY be used in both directions. The Poll sequence MUST @@ -614,33 +762,33 @@ In other words, it is not preferable to send just S-BFD echo packets without also sending S-BFD control packets. There are two reasons behind this suggestion: o S-BFD control packets can verify the reachability to intended target node, which allows one to have confidence that S-BFD echo packets are u-turning on the expected target node. o S-BFD control packets can detect when the target node is going out - of service (i.e. via receiving back ADMINDOWN state). + of service (i.e., via receiving back ADMINDOWN state). The usage of the "Required Min Echo RX Interval" field is described in Section 7.2.2 and Section 7.3.2. Because of the stateless nature of SBFDReflector sessions, a value specified the "Required Min Echo RX Interval" field in both directions is not very meaningful. Thus it is RECOMMENDED that the "Required Min Echo RX Interval" field simply be set to zero in both directions. Following aspects of S-BFD Echo functions are left as implementation details, and are outside the scope of this document: - o Format of the S-BFD echo packet (ex: data beyond UDP header). + o Format of the S-BFD echo packet (e.g., data beyond UDP header). o Procedures on when and how to use the S-BFD Echo function. 11. Security Considerations Same security considerations as [RFC5880], [RFC5881], [RFC5883], [RFC5884] and [RFC5885] apply to this document. Additionally, implementing the following measures will strengthen security aspects of the mechanism described by this document: @@ -744,22 +892,22 @@ bfd-generic-crypto-auth-06 (work in progress), April 2014. [I-D.ietf-bfd-multipoint] Katz, D., Ward, D., and J. Networks, "BFD for Multipoint Networks", draft-ietf-bfd-multipoint-04 (work in progress), August 2014. [I-D.ietf-bfd-seamless-use-case] Aldrin, S., Bhatia, M., Mirsky, G., Kumar, N., and S. Matsushima, "Seamless Bidirectional Forwarding Detection - (BFD) Use Case", draft-ietf-bfd-seamless-use-case-00 (work - in progress), June 2014. + (BFD) Use Case", draft-ietf-bfd-seamless-use-case-01 (work + in progress), December 2014. [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. Appendix A. Loop Problem Consider a scenario where we have two nodes and both are S-BFD capable. @@ -796,21 +944,21 @@ o Overload "D" bit (Demand mode bit): Initiator always sets the 'D' bit and reflector clears it. This way we can identify if a received packet was a reflected packet and avoid reflecting it back. However this changes the interpretation of 'D' bit. o Use of State field in the BFD control packets: Initiator will always send packets with State set to DOWN and reflector will send back packets with state field set to UP. Reflectors will never reflect any received packets with state as UP. However the only - issue is the use of state field differently i.e. state in the + issue is the use of state field differently i.e., state in the S-BFD control packet from initiator does not reflect the local state which is anyway not significant at reflector. o Use of local discriminator as My Disc at reflector: Reflector will always fill in My Discriminator with a locally allocated discriminator value (not reserved discriminators) and will not copy it from the received packet. Authors' Addresses