S-BFD for VCCV: Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)
How Seamless BFD can run over a pseudowire's connectivity-check channel, with two new check types.
Govindan, V. and C. Pignataro, "Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)", RFC 7885, DOI 10.17487/RFC7885, July 2016, <https://www.rfc-editor.org/info/rfc7885>.
@misc{rfc7885,
series = {Request for Comments},
number = 7885,
howpublished = {RFC 7885},
publisher = {RFC Editor},
doi = {10.17487/RFC7885},
url = {https://www.rfc-editor.org/info/rfc7885},
author = {V. Govindan and C. Pignataro},
title = {{Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV)}},
pagetotal = 11,
year = 2016,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) V. Govindan
Request for Comments: 7885 C. Pignataro
Updates: 5885 Cisco
Category: Standards Track July 2016
ISSN: 2070-1721
Seamless Bidirectional Forwarding Detection (S-BFD)
for Virtual Circuit Connectivity Verification (VCCV)
Abstract
This document defines 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).
This document updates RFC 5885 by extending the CV Type values and
the capability selection.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
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 ......................................................3
2. S-BFD Connectivity Verification .................................3
2.1. Co-existence of S-BFD and BFD 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 ..................6
2.2.2.5. Provisioning of Target Discriminators ......6
2.3. S-BFD Encapsulation ........................................6
3. Capability Selection ............................................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................8
5.1. MPLS CV Types for the VCCV Interface Parameters Sub-TLV ....8
5.2. L2TPv3 CV Types for the VCCV Capability AVP ................8
5.3. PW Associated Channel Type .................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
Acknowledgements ..................................................11
Contributors ......................................................11
Authors' Addresses ................................................11
1. Background
Bidirectional Forwarding Detection (BFD) for Virtual Circuit
Connectivity Verification (VCCV) [RFC5885] defines the CV Types for
BFD using VCCV, protocol operation, and the required packet
encapsulation formats. This document extends those procedures and
CV Type values to enable Seamless BFD (S-BFD) [RFC7880] operation
for VCCV.
The new S-BFD CV Types are Pseudowire (PW) demultiplexer agnostic and
hence are applicable for both MPLS and Layer Two Tunneling Protocol
version 3 (L2TPv3) PW demultiplexers. This document concerns itself
with the S-BFD VCCV operation over Single-Segment PWs (SS-PWs). The
scope of this document is as follows:
o This specification describes procedures for S-BFD asynchronous
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-BFD Discriminator per
PW. There are cases where multiple S-BFD Discriminators per PW can
be useful. One such case involves using different S-BFD
Discriminators per Flow within a Flow-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], 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-BFD Control 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 CV Types to be used for S-BFD. It also
defines the procedures for the S-BFD reflector and S-BFD initiator
operation.
Two CV Types are defined for S-BFD. Table 1 summarizes the S-BFD
CV Types, grouping them by encapsulation (i.e., with IP/UDP headers,
without IP/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 IP/UDP encapsulation (with IP/UDP | 0x40 | N/A |
| headers) | | |
| | | |
| S-BFD PW-ACH encapsulation when using | 0x80 | N/A |
| MPLS PW or S-BFD L2-Specific Sublayer | | |
| (L2SS) encapsulation when using L2TP PW | | |
| (without IP/UDP headers) | | |
+-----------------------------------------+-----------+-------------+
Table 1: Bitmask Values for S-BFD CV Types
IANA has assigned two new bits to indicate S-BFD operation.
2.1. Co-existence of S-BFD and BFD Capabilities
Since the CV Types 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-BFD initiator SHOULD bootstrap S-BFD sessions after it learns
the discriminator of the remote target identifier. This can be
achieved, for example, through one or more of the following methods.
(This list is not exhaustive.)
1. Advertisements of S-BFD Discriminators made through a
PW signaling protocol -- for example, AVPs/TLVs defined in
L2TP/LDP.
2. Provisioning of S-BFD Discriminators by manual configuration of
the Provider Edge (PE) or L2TP Control Connection Endpoints
(LCCEs).
3. Assignment of S-BFD Discriminators by a controller.
4. Probing remote S-BFD Discriminators through a mechanism such as
S-BFD Alert Discriminators [SBFD-ALERT-DISCRIM].
The S-BFD initiator operation MUST be done as specified in
Section 7.3 of [RFC7880].
2.2.2. S-BFD Reflector Operation
When a PW signaling protocol such as LDP or L2TPv3 is in use, the
S-BFD reflector can advertise its target discriminators using that
signaling protocol. When static PWs are in use, the target
discriminator of S-BFD needs to be provisioned on the S-BFD
initiator nodes.
All point-to-point PWs are bidirectional; the S-BFD reflector
therefore reflects the S-BFD packet back to the initiator using the
VCCV channel of the reverse direction of the PW on which it was
received.
The 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-BFD reflector operation for BFD protocol fields MUST be
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 [RFC7880].
2.2.2.2. Transmission of Control Packets
S-BFD reflector procedures as described in [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 MPLS Packet Switched Network (PSN) by
provisioning the S-BFD Discriminators or by learning the S-BFD
Discriminators via some other means.
2.2.2.4. Advertisement of Target Discriminators Using L2TP
The S-BFD reflector MUST use the AVP 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 BFD encapsulation (BFD with IP/UDP headers):
* The destination UDP port for the IP-encapsulated S-BFD packet
MUST be 7784 [RFC7881].
* The contents of the S-BFD Control packets MUST be set according
to Section 7.3.2 of [RFC7880].
* The Time to Live (TTL) (IPv4) or Hop Limit (IPv6) is set
to 255.
o PW-ACH/L2SS BFD encapsulation (BFD without IP/UDP headers):
* The encapsulation of S-BFD packets using this format MUST be
performed according to Section 3.2 of [RFC5885], with the
exception of the value for the PW-ACH/L2SS type.
* When VCCV carries PW-ACH/L2SS-encapsulated S-BFD (i.e., "raw"
S-BFD), the Channel Type of PW-ACH (the PW Control Word (CW))
or L2SS MUST be set to 0x0008 to indicate "S-BFD Control,
PW-ACH/L2SS-encapsulated" (i.e., S-BFD without IP/UDP headers;
see Section 5.3). This is done to allow the identification of
the encapsulated S-BFD payload when demultiplexing the VCCV
control channel.
3. Capability Selection
When multiple S-BFD CV Types are advertised, and after applying the
rules in [RFC5885], the set that both ends of the PW 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 in order,
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. 0x40 - S-BFD IP/UDP-encapsulated, for PW Fault Detection only.
2. 0x80 - S-BFD PW-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 capabilities | BFD | S-BFD | Both S-BFD and |
| of PE1/PE2 | Only | Only | BFD |
+---------------------------+---------+-----------+-----------------+
| BFD Only | BFD | None | BFD Only |
| | | | |
| S-BFD Only | None | S-BFD | S-BFD Only |
| | | | |
| Both S-BFD and BFD | BFD | S-BFD | Both S-BFD and |
| | Only | Only | 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-BFD CV Types does 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 [RFC7880].
The IP/UDP encapsulation of S-BFD makes use of the TTL / Hop Limit
procedures described in the Generalized TTL Security Mechanism (GTSM)
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 VCCV Connectivity Verification (CV) Types"
registry is defined in [RFC5085].
This section lists the new S-BFD CV Types.
IANA has augmented the "MPLS VCCV Connectivity Verification (CV)
Types" registry in the "Pseudowire Name Spaces (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
=========== =========== ==============
6 (0x40) S-BFD IP/UDP-encapsulated, RFC 7885
for PW Fault Detection only
7 (0x80) S-BFD PW-ACH-encapsulated, RFC 7885
for PW Fault Detection only
5.2. L2TPv3 CV Types for the VCCV Capability AVP
This section lists the new S-BFD "L2TPv3 Connectivity Verification
(CV) Types" that have been added to the existing "VCCV Capability AVP
(Attribute Type 96) Values" registry in the "Layer Two Tunneling
Protocol 'L2TP'" registry [IANA-L2TP]. IANA has assigned the
following L2TPv3 Connectivity Verification (CV) Types in the "VCCV
Capability AVP (Attribute Type 96) Values" registry.
VCCV Capability AVP (Attribute Type 96) Values
----------------------------------------------
L2TPv3 Connectivity Verification (CV) Types:
Bit (Value) Description Reference
=========== =========== ==============
6 (0x40) S-BFD IP/UDP-encapsulated, RFC 7885
for PW Fault Detection only
7 (0x80) S-BFD L2SS-encapsulated, RFC 7885
for PW Fault Detection only
5.3. PW Associated Channel Type
As per the IANA considerations in [RFC5586], IANA has allocated a
Channel Type in the "MPLS Generalized Associated Channel (G-ACh)
Types (including Pseudowire Associated Channel Types)" registry
[IANA-G-ACh].
IANA has assigned a new Pseudowire Associated Channel Type value, as
follows:
Value Description Reference
------ ---------------------------------- ---------------
0x0008 S-BFD Control, PW-ACH/L2SS RFC 7885
encapsulation
(without IP/UDP Headers)
6. References
6.1. Normative References
[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>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<http://www.rfc-editor.org/info/rfc7880>.
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless
Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
<http://www.rfc-editor.org/info/rfc7881>.
[RFC7886] Govindan, V. and C. Pignataro, "Advertising Seamless
Bidirectional Forwarding Detection (S-BFD) Discriminators
in the Layer Two Tunneling Protocol Version 3 (L2TPv3)",
RFC 7886, DOI 10.17487/RFC7886, July 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'",
<http://www.iana.org/assignments/l2tp-parameters>.
[IANA-PWE3]
Internet Assigned Numbers Authority, "Pseudowire Name
Spaces (PWE3)",
<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
AI ELI5
On this page
§1Background and Scope
RFC 5885 defines how Bidirectional Forwarding Detection (BFD) runs over the Virtual Circuit Connectivity Verification (VCCV) channel of a pseudowire (PW). This document extends those procedures and CV Type values so that Seamless BFD (S-BFD, RFC 7880) can be used the same way.
The new S-BFD CV Types do not depend on the PW demultiplexer, so they apply to both MPLS and L2TPv3 pseudowires. The scope is narrow: single-segment PWs (SS-PWs), S-BFD asynchronous mode only. S-BFD Echo mode, and S-BFD for fault detection with status signaling, are out of scope.
The RFC specifies a single S-BFD discriminator per PW. Several discriminators per PW could help, for example one per flow on a Flow-Aware Transport (FAT) PW, but that would need a flow-to-discriminator mapping first.
This RFC is only about one kind of virtual cable at a time, and only one simple way of checking it. Fancier checks are left for another day.
§2The Two S-BFD CV Types
S-BFD provides continuity checks by monitoring S-BFD Control packets sent and received over the VCCV channel of the PW. Two CV Types are defined, both for fault detection only: 0x40 for S-BFD with IP/UDP headers, and 0x80 for S-BFD without IP/UDP headers (PW-ACH encapsulation on an MPLS PW, or L2-Specific Sublayer encapsulation on an L2TP PW). The 'fault detection and status signaling' column is not applicable for either.
Because the S-BFD and BFD CV Type values are distinct, a node can advertise BFD and S-BFD capabilities at the same time.
There are two new kinds of 'are you there?' message. One is wrapped in an internet envelope and one is not. A device can know both the old and new kinds at once.
- 0x40S-BFD IP/UDP — S-BFD with IP/UDP headers; fault detection only.
- 0x80S-BFD PW-ACH / L2SS — S-BFD without IP/UDP headers (PW-ACH on MPLS, L2SS on L2TP); fault detection only.
§3Initiator and Reflector Operation
The S-BFD initiator SHOULD start S-BFD sessions once it has learned the discriminator of the remote target. The RFC lists non-exhaustive ways to learn it: advertisement through a PW signaling protocol (L2TP or LDP), manual provisioning on the PE or L2TP Control Connection Endpoint, assignment by a controller, or probing through a mechanism such as S-BFD Alert Discriminators. The initiator MUST follow Section 7.3 of RFC 7880.
The reflector sends each received packet back over the VCCV channel in the reverse direction of the same PW, since all point-to-point PWs are bidirectional. Demultiplexing uses the PW context, following Section 7.1 of RFC 7880, and the BFD fields are handled as RFC 7880 specifies.
For advertising target discriminators, an L2TP reflector MUST use the AVP defined in RFC 7886. For LDP, the advertisement is left for further study, so signaled PWs over MPLS can still use S-BFD by provisioning or learning discriminators another way. For static PWs, discriminators MAY be provisioned.
One end asks 'are you there?' using the other end's special name tag. The other end answers straight back along the same cable. The name tag can be told over the cable or written down by hand.
§4S-BFD Encapsulation
Unless stated otherwise, S-BFD packets are encapsulated as in Section 3.2 of RFC 5885 and RFC 5880. Two formats exist.
- IP/UDP: the destination UDP port MUST be
7784(RFC 7881), the Control packet contents MUST follow Section 7.3.2 of RFC 7880, and the TTL (IPv4) or Hop Limit (IPv6) is set to255. - PW-ACH/L2SS (no IP/UDP headers): encapsulation follows Section 3.2 of RFC 5885, except for the type value. The Channel Type of the PW-ACH (the PW Control Word) or L2SS MUST be
0x0008, meaning 'S-BFD Control, PW-ACH/L2SS-encapsulated', so the S-BFD payload can be identified when demultiplexing the VCCV control channel.
The message can travel in a normal internet envelope with a fixed mailbox number, or in a plain wrapper marked with a special stamp so the receiver knows what it is.
§5Capability Selection
After applying the rules in RFC 5885, the two ends of the PW work out which S-BFD CV Types they share. If they share more than one, the one with the lowest list number is used: first 0x40 (IP/UDP-encapsulated), then 0x80 (PW-ACH/L2SS-encapsulated). Both are for fault detection only.
Between S-BFD and BFD, the RFC gives a matrix. If one end offers only BFD and the other only S-BFD, the result is none. If one end offers only BFD and the other offers both, BFD is used. If one end offers only S-BFD and the other offers both, S-BFD is used. If both offer both, the result is both. This is why the RFC says it updates RFC 5885: it extends the CV Type values and the capability selection.
If both sides know several ways to check, they pick the first one on a shared list. If they have nothing in common, they do not check at all.
| PE1 advertises / PE2 advertises | BFD only | S-BFD only | Both S-BFD and BFD |
|---|---|---|---|
| BFD only | BFD | None | BFD only |
| S-BFD only | None | S-BFD | S-BFD only |
| Both S-BFD and BFD | BFD only | S-BFD only | Both S-BFD and BFD |
§6Security Considerations
The S-BFD CV Types introduce no new security risks for VCCV. Implementations are subject to the same considerations as VCCV in Section 10 of RFC 5085 and those in RFC 7880.
The IP/UDP encapsulation uses the TTL and Hop Limit procedures of the Generalized TTL Security Mechanism (RFC 5082) as a security mechanism.
Sending the message with its hop counter set to its highest value is a trick that helps the receiver ignore messages that came from far away.
§7IANA Allocations
IANA has added entries in three registries. In the MPLS VCCV Connectivity Verification (CV) Types registry, bit 6 (0x40) is S-BFD IP/UDP-encapsulated and bit 7 (0x80) is S-BFD PW-ACH-encapsulated, both for PW fault detection only. In the L2TPv3 VCCV Capability AVP (Attribute Type 96) Values registry, bit 6 (0x40) is S-BFD IP/UDP-encapsulated and bit 7 (0x80) is S-BFD L2SS-encapsulated.
In the MPLS Generalized Associated Channel (G-ACh) Types registry, the Pseudowire Associated Channel Type 0x0008 is assigned to S-BFD Control, PW-ACH/L2SS encapsulation (without IP/UDP headers).
The official list of numbers got three new lines, so everyone uses the same numbers for the new message types.