Internet Engineering Task Force (IETF) V. GovindanInternet-DraftRequest for Comments: 7885 C. Pignataro Updates: 5885(if approved)CiscoIntended status:Category: Standards TrackApril 28, 2016 Expires: October 30,June 2016 ISSN: 2070-1721 SeamlessBFDBidirectional Forwarding Detection (S-BFD) forVCCV draft-ietf-pals-seamless-vccv-03Virtual Circuit Connectivity Verification (VCCV) Abstract This documentextendsdefines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification(VCCV) to define Seamless BFD (S-BFD) for VCCV.(VCCV). This document updates RFC5885,5885 by extending the CVValuesType values and theCapability Selection.capability selection. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 October 30, 2016.http://www.rfc-editor.org/info/rfc7885. Copyright Notice Copyright (c) 2016 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 described in the Simplified BSD License. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 21.1. Requirements Language . . . . . . . . . . . . . . . . . . 32. S-BFD Connectivity Verification . . . . . . . . . . . . . . . 3 2.1. Co-existence of S-BFD and BFDCapabilites .Capabilities . . . . . . . 4 2.2. S-BFD CV Operation . . . . . . . . . . . . . . . . . . . 4 2.2.1. S-BFD Initiator Operation . . . . . . . . . . . . . . 4 2.2.2. S-BFD Reflector Operation . . . . . . . . . . . . . . 5 2.2.2.1. Demultiplexing . . . . . . . . . . . . . . . . . 5 2.2.2.2. Transmission of Control Packets . . . . . . . . . 5 2.2.2.3. Advertisement of Target Discriminators Using LDP 5 2.2.2.4. Advertisement of Target Discriminators Using L2TP 5 2.2.2.5. Provisioning of Target Discriminators . . . . . .65 2.3. S-BFD Encapsulation . . . . . . . . . . . . . . . . . . . 62.4. S-BFD CV Types . . . . . . . . . . . . . . . . . . . . . 63. Capability Selection . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV . 7 5.2. L2TPv3 CV Types for the VCCV Capability AVP . . . . . . . 8 5.3. PW Associated Channel Type . . . . . . . . . . . . . . . 8 6.AcknowledgmentsReferences . . . . . . . . . . . . . . . . . . . . . . . . . 97. Contributors6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . .9 8. References. . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . .9 8.1. Normative References. . . . . . . . . . 10 Contributors . . . . . . . . .9 8.2. Informative References. . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. BackgroundBFDBidirectional Forwarding Detection (BFD) forVCCVVirtual Circuit Connectivity Verification (VCCV) [RFC5885] defines the CVtypesTypes for BFD using VCCV, protocoloperationoperation, and the required packet encapsulation formats. This document extends thoseprocedures,procedures and CVtypeType values to enableS-BFD [I-D.ietf-bfd-seamless-base]Seamless BFD (S-BFD) [RFC7880] operation for VCCV. The new S-BFD CV Types are Pseudowire (PW)demultiplexer-agnostic,demultiplexer agnostic and hence are applicable for both MPLS and Layer Two Tunneling Protocol version 3 (L2TPv3)pseudowirePW demultiplexers. This document concerns itself with the S-BFD VCCV operation oversingle-segment pseudowiresSingle-Segment PWs (SS-PWs). The scope of this document is as follows: o This specification describes proceduresonlyfor S-BFD asynchronousmode.mode only. o S-BFD Echo mode is outside the scope of this specification. o S-BFD operation for fault detection and status signaling is outside the scope of this specification. This document specifies the use of a single S-BFDdiscriminatorDiscriminator perPseudowire.PW. There are cases where multiple S-BFDdiscriminatorsDiscriminators per PW can be useful. One suchcases iscase involves using different S-BFDdiscriminatorsDiscriminators per Flow within aFATFlow-Aware Transport (FAT) PW [RFC6391]; however, the mapping between Flows and discriminators is a prerequisite. FAT PWs can be supported as described in Section 7 of[RFC6391]. 1.1. Requirements Language[RFC6391], which details Operations, Administration, and Maintenance (OAM) considerations for FAT PWs. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. S-BFD Connectivity Verification The S-BFD protocol provides continuity check services by monitoring the S-BFDcontrolControl packets sent and received over the VCCV channel of the PW. The term "Connectivity Verification" (CV) is used throughout this document to be consistent with [RFC5885]. This section defines the CVtypesTypes to be used for S-BFD. It also defines the procedures for the S-BFD reflector and S-BFDInitiatorinitiator operation. Two CV Types are defined for S-BFD. Table 1 summarizes the S-BFD CV Types, grouping them by encapsulation (i.e., withversusIP/UDP headers, withoutIP/ UDPIP/UDP headers) for fault detection only. S-BFD for fault detection and status signaling is outside the scope of this specification.+----------------------------------------+-----------+--------------++-----------------------------------------+-----------+-------------+ | | Fault | Fault | | | Detection | Detection | | | Only | and Status | | | | Signaling |+----------------------------------------+-----------+--------------++-----------------------------------------+-----------+-------------+ |S-BFD,S-BFD IP/UDPEncapsulationencapsulation (with IP/UDP |TBD10x40 | N/A | |IP/UDP Headers)headers) | | | | | | | |S-BFD,S-BFD PW-ACHEncapsulationencapsulation when using |TBD20x80 | N/A | | MPLS PW or S-BFD L2-Specific Sublayer(L2SS)| | | |Encapsulation(L2SS) encapsulation when using L2TP PW | | | | (without IP/UDPHeaders)headers) | | |+----------------------------------------+-----------+--------------++-----------------------------------------+-----------+-------------+ Table 1: Bitmask Values forBFDS-BFD CV TypesTwoIANA has assigned two new bitsare requested from IANAto indicate S-BFD operation. 2.1. Co-existence of S-BFD and BFDCapabilitesCapabilities Since the CVtypesTypes for S-BFD and BFD are unique, BFD and S-BFD capabilities can be advertised concurrently. 2.2. S-BFD CV Operation 2.2.1. S-BFD Initiator Operation The S-BFDInitiatorinitiator SHOULD bootstrap S-BFD sessions after it learns the discriminator of the remote target identifier. This can be achieved, forexample but not limited to,example, through one or more of the followingmethods:methods. (This list is not exhaustive.) 1. Advertisements of S-BFDdiscriminatorsDiscriminators made through a PW signalingprotocol,protocol -- forexample AVP/TLVsexample, AVPs/TLVs defined in L2TP/LDP. 2. Provisioning of S-BFDdiscriminatorsDiscriminators by manual configuration of thePE/LCCEs.Provider Edge (PE) or L2TP Control Connection Endpoints (LCCEs). 3. Assignment of S-BFDdiscriminatorsDiscriminators by a controller. 4. Probing remote S-BFDdiscriminatorsDiscriminators through a mechanism such as S-BFD Alertdiscriminators [I-D.akiya-bfd-seamless-alert-discrim]Discriminators [SBFD-ALERT-DISCRIM]. The S-BFDInitiatorinitiator operation MUST beaccording to the specificationsdone as specified in Section7.27.3 of[I-D.ietf-bfd-seamless-base].[RFC7880]. 2.2.2. S-BFD Reflector Operation When apseudowirePW signaling protocol such as LDP or L2TPv3 is in use, the S-BFDReflectorreflector can advertise its target discriminators using that signaling protocol. When static PWs are inuseuse, the target discriminator of S-BFD needs to be provisioned on the S-BFDInitiatorinitiator nodes. Allpoint to point pseudowirespoint-to-point PWs arebidirectional,bidirectional; the S-BFDReflectorreflector therefore reflects the S-BFD packet back to theInitiatorinitiator using the VCCV channel of the reverse direction of the PW on which it was received.It is observed that theThe reflector has enough information to reflect the S-BFD Async packet received by it back to the S-BFD initiator using the PW context (e.g., fields of the L2TPv3 headers). The S-BFDReflectorreflector operation for BFD protocol fields MUST beaccording to the specifications of [I-D.ietf-bfd-seamless-base].performed as specified in [RFC7880]. 2.2.2.1. Demultiplexing Demultiplexing of S-BFD is achieved using the PW context, following the procedures in Section 7.1 of[I-D.ietf-bfd-seamless-base].[RFC7880]. 2.2.2.2. Transmission of Control PacketsThe procedures ofS-BFDReflectorreflector procedures as described in[I-D.ietf-bfd-seamless-base][RFC7880] apply for S-BFD using VCCV. 2.2.2.3. Advertisement of Target Discriminators Using LDP The advertisement of the target discriminator using LDP is left for further study. It should be noted that S-BFD can still be used with signaled PWs over an MPLSPSN,Packet Switched Network (PSN) by provisioningofthe S-BFDdiscriminatorsDiscriminators or by learning the S-BFDdiscriminators byDiscriminators via some other means. 2.2.2.4. Advertisement of Target Discriminators Using L2TP The S-BFDReflectorreflector MUST use the AVP[I-D.ietf-l2tpext-sbfd-discriminator]defined in [RFC7886] for advertising its target discriminators using L2TP. 2.2.2.5. Provisioning of Target Discriminators S-BFD target discriminators MAY be provisioned when static PWs are used. 2.3. S-BFD Encapsulation Unless specified differently below, the encapsulation of S-BFD packets is identical to the method specified in Section 3.2 of [RFC5885] and in [RFC5880] for the encapsulation of BFD packets. o IP/UDP BFDEncapsulationencapsulation (BFD with IP/UDPHeaders)headers): * The destination UDP port for theIP encapsulatedIP-encapsulated S-BFD packet MUST be 7784[I-D.ietf-bfd-seamless-ip].[RFC7881]. * Theencapsulationcontents of the S-BFDheader fieldsControl packets MUST be set according to Section 7.3.2 of[I-D.ietf-bfd-seamless-base].[RFC7880]. * The Time to Live (TTL) (IPv4) or Hop Limit (IPv6) is set to 255. oPW-ACH/ L2SSPW-ACH/L2SS BFDEncapsulationencapsulation (BFD without IP/UDPHeaders)headers): * The encapsulation of S-BFD packets using this format MUST be performed according to Section 3.2 of[RFC5885][RFC5885], with the exception of the value for the PW-ACH/L2SS type. * When VCCV carriesPW-ACH/ L2SS-encapsulatedPW-ACH/L2SS-encapsulated S-BFD (i.e., "raw" S-BFD), thePW-ACH (pseudowire CW's) or L2SS'Channel Type of PW-ACH (the PW Control Word (CW)) or L2SS MUST be set toTBD30x0008 to indicate "S-BFD Control,PW-ACH/ L2SS- encapsulated"PW-ACH/L2SS-encapsulated" (i.e., S-BFD without IP/UDP headers; see Section 5.3). This is done to allow the identification of theencasedencapsulated S-BFD payload when demultiplexing the VCCV control channel.2.4. S-BFD CV Types3. Capability Selection When multiple S-BFD CV Types are advertised, and after applying the rules in [RFC5885], the set that both ends of thepseudowirePW have in common is determined. If the two ends have more than one S-BFD CV Type in common, the following list of S-BFD CV Types is considered inthe order oforder, from the lowest list number CV Type to the highest list number CV Type, and the CV Type with the lowest list number is used: 1.TBD10x40 - S-BFD IP/UDP-encapsulated, for PW Fault Detection only. 2.TBD20x80 - S-BFDPW-ACH/ L2SS-encapsulatedPW-ACH/L2SS-encapsulated (without IP/UDP headers), for PW Fault Detection only. The order of capability selection between S-BFD and BFD is defined as follows:+----------------------------+---------+----------+-----------------++---------------------------+---------+-----------+-----------------+ | Advertised capabilitiesof| BFD |SBFDS-BFD | Both S-BFD and | |PE1/ PE2of PE1/PE2 | Only | Only | BFD |+----------------------------+---------+----------+-----------------++---------------------------+---------+-----------+-----------------+ | BFD Only | BFD | None | BFD Only | | | | | | | S-BFD Only | None | S-BFD | S-BFDonlyOnly | | | | | | | Both S-BFD and BFD | BFD | S-BFD | BothSBFDS-BFD and | | |onlyOnly |onlyOnly | BFD |+----------------------------+---------+----------+-----------------++---------------------------+---------+-----------+-----------------+ Table 2: Capability Selection Matrix for BFD and S-BFD 4. Security Considerations Security considerations for VCCV are addressed in Section 10 of [RFC5085]. The introduction of the S-BFDConnectivity Verification (CV)CV Typesintroduces nodoes not present any new security risks for VCCV. Implementations of the additional CV Types defined herein are subject to the same security considerations as those defined in [RFC5085] as well as[I-D.ietf-bfd-seamless-base].[RFC7880]. The IP/UDPencasulationencapsulation of S-BFD makes use of theTTL/HopTTL / Hop Limit procedures described in the Generalized TTL Security Mechanism (GTSM)[RFC5082])specification [RFC5082] as a security mechanism. This specification does not raise any additional security issues beyond these. 5. IANA Considerations 5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV The VCCV Interface Parameters Sub-TLV codepoint is defined in [RFC4446], and the "MPLS VCCVCV TypesConnectivity Verification (CV) Types" registry is defined in [RFC5085]. This section lists the newBFDS-BFD CV Types. IANA has augmented the "MPLS VCCV Connectivity Verification (CV) Types" registry in thePseudowire"Pseudowire Name Spacesreachable from(PWE3)" registry [IANA-PWE3]. These are bitfield values. CV Type values are specified in Section 2 of this document. MPLS VCCV Connectivity Verification (CV) Types: Bit (Value) Description Reference =========== =========== ==============TBD1(0xY)6 (0x40) S-BFD IP/UDP-encapsulated,This documentRFC 7885 for PW Fault Detection onlyTBD2(0xZ)7 (0x80) S-BFD PW-ACH-encapsulated,This documentRFC 7885 for PW Fault Detection only 5.2. L2TPv3 CV Types for the VCCV Capability AVP This section lists the newrequests forS-BFD "L2TPv3 Connectivity Verification (CV) Types"to bethat have been added to the existing "VCCV CapabilityAVP"AVP (Attribute Type 96) Values" registry in theL2TP name spaces. The Layer"Layer Two Tunneling Protocol"L2TP" Name Spaces are reachable from'L2TP'" registry [IANA-L2TP]. IANAis requested to assignhas assigned the following L2TPv3 Connectivity Verification (CV) Types in theVCCV"VCCV Capability AVPValues(Attribute Type 96) Values" registry. VCCV Capability AVP (Attribute Type 96) Values ---------------------------------------------- L2TPv3 Connectivity Verification (CV) Types: Bit (Value) Description Reference =========== =========== ==============TBD1(0xY)6 (0x40) S-BFD IP/UDP-encapsulated,This documentRFC 7885 for PW Fault Detection onlyTBD2(0xZ)7 (0x80) S-BFD L2SS-encapsulated,This documentRFC 7885 for PW Fault Detection only 5.3. PW Associated Channel Type As per the IANA considerations in [RFC5586], IANAis requested to allocate the followinghas allocated a ChannelTypesType in the "MPLS Generalized Associated Channel (G-ACh)Types" registry:Types (including Pseudowire Associated Channel Types)" registry [IANA-G-ACh]. IANA hasreservedassigned a new Pseudowire Associated Channel Typevaluevalue, as follows:Registry: TLVValue DescriptionFollowsReference ------ --------------------------------------------------------TBD30x0008 S-BFD Control, PW-ACH/L2SSNo [This document]RFC 7885 encapsulation (without IP/UDP Headers) 6.Acknowledgments The authors would like to thank Nobo Akiya, Stewart Bryant, Greg Mirsky, and Pawel Sowinski, Yuanlong, Andrew Malis, and Alexander Vainshtein for providing input to this document and for performing thorough reviews and useful comments. 7. Contributors Mallik Mudigonda Cisco Systems, Inc. Email: mmudigon@cisco.com 8.References8.1.6.1. Normative References[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-09 (work in progress), April 2016. [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-04 (work in progress), April 2016. [I-D.ietf-l2tpext-sbfd-discriminator] Govindan, V. and C. Pignataro, "Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in Layer Two Tunneling Protocol, Version 3 (L2TPv3)", draft-ietf-l2tpext-sbfd-discriminator-05 (work in progress), April 2016.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>. [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>. [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>. [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.8.2. Informative References [I-D.akiya-bfd-seamless-alert-discrim][RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, June 2016, <http://www.rfc-editor.org/info/rfc7880>. [RFC7881] Pignataro, C.,and D.Ward, D., and N. Akiya, "Seamless Bidirectional Forwarding Detection (S-BFD)Alert Discriminator", draft-akiya-bfd-seamless-alert-discrim-03 (workfor IPv4, IPv6, and MPLS", RFC 7881, DOI 10.17487/RFC7881, June 2016, <http://www.rfc-editor.org/info/rfc7881>. [RFC7886] Govindan, V. and C. Pignataro, "Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators inprogress), October 2014.the Layer Two Tunneling Protocol Version 3 (L2TPv3)", RFC 7886, DOI 10.17487/RFC7886, June 2016, <http://www.rfc-editor.org/info/rfc7886>. 6.2. Informative References [IANA-G-ACh] Internet Assigned Numbers Authority, "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)", <http://www.iana.org/assignments/g-ach-parameters>. [IANA-L2TP] Internet Assigned Numbers Authority, "Layer Two Tunneling Protocol"L2TP"", May 2015,'L2TP'", <http://www.iana.org/assignments/l2tp-parameters>. [IANA-PWE3] Internet Assigned Numbers Authority, "Pseudowire Name Spaces (PWE3)",January 2016,<http://www.iana.org/assignments/pwe3-parameters>. [RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, <http://www.rfc-editor.org/info/rfc6391>. [SBFD-ALERT-DISCRIM] Akiya, N., Pignataro, C., and D. Ward, "Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discriminator", Work in Progress, draft-akiya-bfd- seamless-alert-discrim-03, October 2014. Acknowledgements The authors would like to thank Nobo Akiya, Stewart Bryant, Greg Mirsky, Pawel Sowinski, Yuanlong Jiang, Andrew Malis, and Alexander Vainshtein for providing input to this document, performing thorough reviews, and providing useful comments. Contributors Mallik Mudigonda Cisco Systems, Inc. Email: mmudigon@cisco.com Authors' Addresses Vengada Prasad Govindan Cisco Systems, Inc. Email: venggovi@cisco.com Carlos Pignataro Cisco Systems, Inc. Email: cpignata@cisco.com