rfc9764.original.xml   rfc9764.xml 
<?xml version="1.0" encoding='utf-8'?> <?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc sortrefs="yes"?>
<?rfc subcompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocompact="yes"?>
<rfc <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
xmlns:xi="http://www.w3.org/2001/XInclude" tf-bfd-large-packets-16" number="9764" consensus="true" ipr="trust200902" submis
category="std" sionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4"
docName="draft-ietf-bfd-large-packets-16" updates="" obsoletes="" symRefs="true" sortRefs="true" version="3">
ipr="trust200902"
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3"
>
<front>
<title>BFD Encapsulated in Large Packets</title>
<author fullname="Jeffrey Haas" initials="J." surname="Haas"> <front>
<organization>Juniper Networks, Inc.</organization> <title abbrev="BFD Encapsulated in Large Packets">Bidirectional Forwarding Det
<address> ection (BFD) Encapsulated in Large Packets</title>
<postal> <seriesInfo name="RFC" value="9764"/>
<street>1133 Innovation Way</street> <author fullname="Jeffrey Haas" initials="J." surname="Haas">
<city>Sunnyvale</city> <organization>Juniper Networks, Inc.</organization>
<region>CA</region> <address>
<code>94089</code> <postal>
<country>US</country> <street>1133 Innovation Way</street>
</postal> <city>Sunnyvale</city>
<email>jhaas@juniper.net</email> <region>CA</region>
</address> <code>94089</code>
</author> <country>United States of America</country>
</postal>
<email>jhaas@juniper.net</email>
</address>
</author>
<author fullname="Albert Fu" initials="A." surname="Fu"> <author fullname="Albert Fu" initials="A." surname="Fu">
<organization>Bloomberg L.P.</organization> <organization>Bloomberg L.P.</organization>
<address> <address>
<postal> <postal>
<street>731 Lexington Avenue</street> <street>731 Lexington Avenue</street>
<city>New York</city> <city>New York</city>
<region>NY</region> <region>NY</region>
<code>10022</code> <code>10022</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>afu14@bloomberg.net</email> <email>afu14@bloomberg.net</email>
</address>
</author>
<date year="2025" month="April"/>
</address> <area>RTG</area>
</author> <workgroup>bfp</workgroup>
<date year="2025" />
<abstract> <abstract>
<t> <t>
The Bidirectional Forwarding Detection (BFD) protocol is commonly use d to verify The Bidirectional Forwarding Detection (BFD) protocol is commonly use d to verify
connectivity between two systems. BFD packets are typically very sma ll. It is connectivity between two systems. BFD packets are typically very sma ll. It is
desirable in some circumstances to know that not only is the path bet ween two systems desirable in some circumstances to know not only that the path betwee n two systems is
reachable, but also that it is capable of carrying a payload of a par ticular size. reachable, but also that it is capable of carrying a payload of a par ticular size.
This document specifies how to implement such a mechanism using BFD i n Asynchronous This document specifies how to implement such a mechanism using BFD i n Asynchronous
mode. mode.
</t> </t>
<t> <t>
YANG modules for managing this mechanism are also defined in this doc ument. These YANG modules for managing this mechanism are also defined in this doc ument. These
YANG modules augment the existing BFD YANG modules defined in RFC 931 4. YANG modules augment the existing BFD YANG modules defined in RFC 931 4.
The YANG modules in this document conform to the Network Management D atastore The YANG modules in this document conform to the Network Management D atastore
Architecture (NMDA) (RFC 8342). Architecture (NMDA) (RFC 8342).
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro">
<name>Introduction</name>
<t> <t>
The Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/> protocol is commonly The Bidirectional Forwarding Detection (BFD) <xref target="RFC5880"/> protocol is commonly
used to verify connectivity between two systems. However, some appli cations may require used to verify connectivity between two systems. However, some appli cations may require
that the Path MTU <xref target="RFC1191"/> between those two systems meets a certain that the Path MTU <xref target="RFC1191"/> between those two systems meets a certain
minimum criterion. When the Path MTU decreases below the minimum thr eshold, those minimum criterion. When the Path MTU decreases below the minimum thr eshold, those
applications may wish to consider the path unusable. applications may wish to consider the path unusable.
</t> </t>
<t> <t>
BFD may be encapsulated in a number of transport protocols. An examp le of this is BFD may be encapsulated in a number of transport protocols. An examp le is
single-hop BFD <xref target="RFC5881"/>. In that case, the link MTU configuration is single-hop BFD <xref target="RFC5881"/>. In that case, the link MTU configuration is
typically enough to guarantee communication between the two systems f or that size MTU. typically enough to guarantee communication between the two systems f or that size MTU.
BFD Echo mode (Section 6.4 of <xref target="RFC5880"/>) is sufficient to permit BFD Echo mode (<xref target="RFC5880" sectionFormat="of" section="6.4 "/>) is sufficient to permit
verification of the Path MTU of such directly connected systems. Pre vious proposals verification of the Path MTU of such directly connected systems. Pre vious proposals
(<xref target="I-D.haas-xiao-bfd-echo-path-mtu"/>) (e.g., <xref target="I-D.haas-xiao-bfd-echo-path-mtu"/>)
have been made for testing Path MTU for such directly connected syste ms. have been made for testing Path MTU for such directly connected syste ms.
However, in the case of multi-hop BFD <xref target="RFC5883"/>, this guarantee does not hold. However, in the case of multihop BFD <xref target="RFC5883"/>, this g uarantee does not hold.
</t> </t>
<t> <t>
The encapsulation of BFD in multi-hop sessions is a simple UDP packet The encapsulation of BFD in multihop sessions is a simple UDP packet.
. The BFD elements The BFD elements
of procedure (Section 6.8.6 of <xref target="RFC5880"/>) covers valid of procedure (<xref target="RFC5880" sectionFormat="of" section="6.8.
ating the BFD 6"/>) cover validating the BFD
payload. However, the specification is silent on the length of the e ncapsulation that is payload. However, the specification is silent on the length of the e ncapsulation that is
carrying the BFD PDU. While it is most common that the transport pro tocol payload (i.e., carrying the BFD PDU. While it is most common that the transport pro tocol payload (i.e.,
UDP) length is the exact size of the BFD PDU, this is not required by the elements of UDP) length is the exact size of the BFD PDU, this is not required by the elements of
procedure. This leads to the possibility that the transport protocol length may be procedure. This leads to the possibility that the transport protocol length may be
larger than the contained BFD PDU. larger than the contained BFD PDU.
</t> </t>
</section> </section>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119"/> <xref NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
target="RFC8174"/> when, and only when, they appear in all RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section title="BFD Encapsulated in Large Packets"> <section>
<name>BFD Encapsulated in Large Packets</name>
<t> <t>
Support for BFD between two systems is typically configured, even if the actual session Support for BFD between two systems is typically configured, even if the actual session
may be dynamically created by a client protocol. A new BFD variable is defined in this may be dynamically created by a client protocol. A new BFD variable is defined in this
document: document:
</t> </t>
<dl newline='true'> <dl newline='true'>
<dt>bfd.PaddedPduSize</dt> <dt>bfd.PaddedPduSize</dt>
<dd> <dd>
The BFD transport protocol payload size (in bytes) is increased to t his value. The The BFD transport protocol payload size (in bytes) is increased to t his value. The
contents of this additional payload MUST be zero. The contents of t contents of this additional payload <bcp14>MUST</bcp14> be zero. Th
his additional e contents of this additional
payload SHOULD NOT be validated by the receiver. The minimum size of payload <bcp14>SHOULD NOT</bcp14> be validated by the receiver.
this variable
MUST NOT be smaller than permitted by the element of BFD procedure; The minimum size of this variable
24 or 26 - see <bcp14>MUST NOT</bcp14> be smaller than 24 or 26 bytes, as permitted
Section 6.8.6 of <xref target="RFC5880"/>. by the element of BFD procedure; see
<xref target="RFC5880" sectionFormat="of" section="6.8.6"/>.
</dd> </dd>
</dl> </dl>
<t> <t>
The Don't Fragment bit (Section 2.3 of <xref target="RFC0791"/>) The Don't Fragment bit (<xref target="RFC0791" sectionFormat="of" sec
of the IP payload, when using IPv4 encapsulation, MUST be set. tion="2.3"/>)
of the IP payload, when using IPv4 encapsulation, <bcp14>MUST</bcp14>
be set.
</t> </t>
</section> </section>
<section title="Implementation and Deployment Considerations"> <section>
<section title="Implementations that do not support Large BFD Packets <name>Implementation and Deployment Considerations</name>
"> <section>
<name>Implementations That Do Not Support Large BFD Packets</name>
<t> <t>
While this document proposes no change to the BFD protocol, impleme ntations may not While this document proposes no change to the BFD protocol, impleme ntations may not
permit arbitrarily padded transport PDUs to carry BFD packets. Whi permit arbitrarily padded transport PDUs to carry BFD packets. Whi
le Section 6 of le
<xref target="RFC5880"/> warns against excessive pedantry, implemen <xref target="RFC5880" sectionFormat="of" section="6"/> warns again
tations may not work st excessive pedantry, implementations may not work
with this mechanism without additional support. with this mechanism without additional support.
</t> </t>
<t> <t>
<xref target="RFC5880"/>, section 6.8.6, discusses the procedures f or receiving <xref target="RFC5880" sectionFormat="of" section="6.8.6"/> discuss es the procedures for receiving
BFD Control packets. The length of the BFD Control packet is valid ated to be less BFD Control packets. The length of the BFD Control packet is valid ated to be less
than or equal to the payload of the encapsulating protocol. When a receiving than or equal to the payload of the encapsulating protocol. When a receiving
implementation is incapable of processing Large BFD Packets, it co uld manifest in one implementation is incapable of processing large BFD packets, it co uld manifest in one
of two possible ways: of two possible ways:
</t> </t>
<ul> <ul>
<li> <li>
A receiving BFD implementation is incapable of accepting Large BFD Packets. A receiving BFD implementation is incapable of accepting large BFD packets.
This is identical to the packet being discarded. This is identical to the packet being discarded.
</li> </li>
<li> <li>
A receiving BFD implementation is capable of accepting Large BFD Pa ckets, A receiving BFD implementation is capable of accepting large BFD pa ckets,
but the Control packet is improperly rejected during validation pro cedures. but the Control packet is improperly rejected during validation pro cedures.
This is identical to the packet being discarded. This is identical to the packet being discarded.
</li> </li>
</ul> </ul>
<t> <t>
In each of these cases, the BFD state machine would behave as if it were not In each of these cases, the BFD state machine would behave as if it were not
receiving Control packets and the receiving implementation would fo receiving Control packets, and the receiving implementation would f
llow normal BFD ollow normal BFD
procedures regarding not having received control packets. procedures regarding not having received Control packets.
</t> </t>
<t> <t>
If Large BFD Packets is enabled on a session that is already in th If large BFD packets is enabled on a session that is already in th
e Up state e Up state
and the remote BFD system does not, or cannot support receiving th and the remote BFD system does not (or cannot) support receiving t
e padded he padded
BFD control packets, the session will go Down. BFD control packets, the session will go Down.
</t> </t>
</section> </section>
<section title="Selecting MTU size to be detected"> <section>
<name>Selecting MTU Size To Be Detected</name>
<t> <t>
Since the consideration is path MTU, BFD sessions using this featur Since the consideration is Path MTU, BFD sessions using this featur
e only need to use an appropriate value of e only need to use an appropriate value of
bfd.PaddedPduSize appropriate to exercise the path MTU for the desi bfd.PaddedPduSize to exercise the Path MTU for the desired applicat
red application. ion.
This may be significantly smaller than the system's link MTU; e.g., This may be significantly smaller than the system's link MTU, e.g.,
desired path MTU is desired Path MTU is
1512 bytes while the interface MTU that BFD with large packets is r 1512 bytes, while the interface MTU that BFD with large packets is
unning on is 9000 running on is 9000
bytes. bytes.
</t> </t>
<t> <t>
In the case multiple BFD clients desire to test the same BFD endpoi nts using In the case multiple BFD clients desire to test the same BFD endpoi nts using
different bfd.PaddedPduSize parameters, implementations SHOULD sele ct the largest different bfd.PaddedPduSize parameters, implementations <bcp14>SHOU LD</bcp14> select the largest
bfd.PaddedPduSize parameter from the configured sessions. This is similar to bfd.PaddedPduSize parameter from the configured sessions. This is similar to
how implementations of BFD select the most aggressive timing parame ters for multiple how implementations of BFD select the most aggressive timing parame ters for multiple
sessions to the same endpoint. Failure to select the largest size will result in BFD sessions to the same endpoint. Failure to select the largest size will result in BFD
sessions going to the Up state and dependent applications not havin g their MTU sessions going to the Up state and dependent applications not havin g their MTU
requirements satisfied. requirements satisfied.
</t> </t>
</section> </section>
<section title="Detecting MTU Mismatches"> <section>
<name>Detecting MTU Mismatches</name>
<t> <t>
The accepted MTU for an interface is impacted by packet encapsulati on The accepted MTU for an interface is impacted by packet encapsulati on
considerations at a given layer; e.g., layer 2, layer 3, tunnel, et c. A common considerations at a given layer, e.g., Layer 2, Layer 3, tunnel, et c. A common
misconfiguration of interface parameters is inconsistent MTU. In t he presence misconfiguration of interface parameters is inconsistent MTU. In t he presence
of inconsistent MTU, it is possible for applications to have unidir ectional of inconsistent MTU, it is possible for applications to have unidir ectional
connectivity. connectivity.
</t> </t>
<t> <t>
When it is necessary for an application using BFD with Large Packet s to test When it is necessary for an application using BFD with Large Packet s to test
the bi-directional Path MTU, it is necessary to configure the the bidirectional Path MTU, it is necessary to configure the
bfd.PaddedPduSize parameter on each side of the BFD session. E.g., bfd.PaddedPduSize parameter on each side of the BFD session. For e
if xample, if
the desire is to verify a 1500 byte MTU in both directions on an Et the desire is to verify a 1512-byte MTU in both directions on an Et
hernet or hernet or
point to point link, each side of the BFD session must have bfd.Pa point-to-point link, each side of the BFD session must have bfd.Pa
ddedPduSize ddedPduSize
set to 1500. In the absence of such consistent configuration, BFD set to 1512. In the absence of such consistent configuration, BFD
with with
Large Packets may correctly determine unidirectional connectivity a t the Large Packets may correctly determine unidirectional connectivity a t the
tested MTU, but bi-directional MTU may not be properly validated. tested MTU, but bidirectional MTU may not be properly validated.
</t> </t>
<t> <t>
It should be noted that some interfaces may intentionally have diff erent MTUs. It should be noted that some interfaces may intentionally have diff erent MTUs.
Setting the bfd.PaddedPduSize appropriately for each side of the BF D session Setting the bfd.PaddedPduSize appropriately for each side of the BF D session
supports such scenarios. supports such scenarios.
</t> </t>
</section> </section>
<section title="Detecting MTU Changes"> <section>
<name>Detecting MTU Changes</name>
<t> <t>
Once BFD sessions using Large Packets has reached the Up state, Once BFD sessions using Large Packets has reached the Up state,
connectivity at the tested MTU(s) for the session is being connectivity at the tested MTU(s) for the session is being
validated. If the path MTU tested by the BFD with Large Packets validated. If the Path MTU tested by the BFD with Large Packets
session falls below the tested MTU, the BFD session will go Down. session falls below the tested MTU, the BFD session will go Down.
</t> </t>
<t> <t>
In the opposite circumstance where the path MTU increases, the In the opposite circumstance (where the Path MTU increases), the
BFD session will continue without being impacted. BFD for Large BFD session will continue without being impacted. BFD for Large
Packets only ensures that the minimally acceptable MTU for the Packets only ensures that the minimally acceptable MTU for the
session can be used. session can be used.
</t> </t>
</section> </section>
<section title="Equal Cost Multiple Paths (ECMP) or other Load Balanc <section>
ing Considerations"> <name>Equal-Cost Multipath (ECMP) or Other Load-Balancing Considera
tions</name>
<t> <t>
Various mechanisms are utilized to increase throughput between two endpoints Various mechanisms are utilized to increase throughput between two endpoints
at various network layers. Such features include Link Aggregate Gr oups (LAGs) at various network layers. Such features include Link Aggregation Groups (LAGs)
or ECMP forwarding. Such mechanisms balance traffic across multiple physical or ECMP forwarding. Such mechanisms balance traffic across multiple physical
links while hiding the details of that balancing from the higher ne tworking links while hiding the details of that balancing from the higher ne tworking
layers. The details of that balancing are highly implementation sp ecific. layers. The details of that balancing are highly implementation sp ecific.
</t> </t>
<t> <t>
In the presence of such load balancing mechanisms, it is possible t o have In the presence of such load-balancing mechanisms, it is possible t o have
member links that are not properly forwarding traffic. In such cir cumstances, member links that are not properly forwarding traffic. In such cir cumstances,
this will result in dropped traffic when traffic is chosen to be lo ad balanced this will result in dropped traffic when traffic is chosen to be lo ad balanced
across those member links. across those member links.
</t> </t>
<t> <t>
Such load balancing mechanisms may not permit all link members to b e properly Such load-balancing mechanisms may not permit all link members to b e properly
tested by BFD. This is because the BFD Control packets may be forw arded only tested by BFD. This is because the BFD Control packets may be forw arded only
along links that are up. BFD on LAG, <xref target="RFC7130"/>, was developed along links that are up. BFD on LAG interfaces, <xref target="RFC7 130"/>, was developed
to help cover one such scenario. However, for testing forwarding o ver to help cover one such scenario. However, for testing forwarding o ver
multiple hops, there is no such specified general purpose BFD mecha nism for multiple hops, there is no such specified general-purpose BFD mecha nism for
exercising all links in an ECMP. This may result in a BFD session being in exercising all links in an ECMP. This may result in a BFD session being in
the Up state while some traffic may be dropped or otherwise negativ ely the Up state while some traffic may be dropped or otherwise negativ ely
impacted along some component links. impacted along some component links.
</t> </t>
<t> <t>
Some BFD implementations utilize their internal understanding of th e component Some BFD implementations utilize their internal understanding of th e component
links and their resultant forwarding to exercise BFD in such a way to better links and their resultant forwarding to exercise BFD in such a way to better
test the ECMP members and to tie the BFD session state to the healt h of that test the ECMP members and to tie the BFD session state to the healt h of that
ECMP. Due to the implementation specific load balancing, it is not possible ECMP. Due to implementation-specific load balancing, it is not pos sible
to standardize such additional mechanisms for BFD. to standardize such additional mechanisms for BFD.
</t> </t>
<t> <t>
Misconfiguration of some member MTUs may lead to Load Balancing tha t may have Misconfiguration of some member MTUs may lead to load balancing tha t may have
an inconsistent Path MTU depending on how the traffic is balanced. While the an inconsistent Path MTU depending on how the traffic is balanced. While the
intent of BFD with Large Packets is to verify path MTU, it is subje ct to the intent of BFD with large packets is to verify Path MTU, it is subje ct to the
same considerations above. same considerations above.
</t> </t>
<t> <t>
<!-- This text added to make Eric Vyncke happy during AD review --> This section applies to most, if not all, BFD techniques.
The above text also applies to most, if not all, BFD techniques.
</t> </t>
</section> </section>
<section title="S-BFD"> <section>
<name>S-BFD</name>
<t> <t>
This mechanism also can be applied to other forms of BFD, including S This mechanism also can be applied to other forms of BFD, including
-BFD Seamless BFD (S-BFD) <xref target="RFC7880"/>.
<xref target="RFC7880"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="yang-module" title="BFD Encapsulated in Large Packets Y <section anchor="yang-module">
ANG Module"> <name>BFD Encapsulated in Large Packets YANG Module</name>
<section anchor="data-model-overview" title="Data Model Overview"> <section anchor="data-model-overview">
<name>Data Model Overview</name>
<t> <t>
This YANG module augments the "ietf-bfd" module to add a flag This YANG module augments the "ietf-bfd" module to add a flag
'padding' to enable this feature. The feature statement 'padding' to enable this feature. The feature statement
'padding' needs to be enabled to indicate that BFD Encapsulated 'padding' needs to be enabled to indicate that BFD encapsulated
in Large Packet is supported by the implementation. in large packets is supported by the implementation.
</t> </t>
<t> <t>
Further, this YANG module augments the YANG modules for single-h op, Further, this YANG module augments the YANG modules for single-h op,
multi-hop, LAG, and MPLS to add the "pdu-size" multihop, LAG, and MPLS to add the "pdu-size"
parameter to those session types to configure Large BFD packets. parameter to those session types to configure large BFD packets.
</t> </t>
<t> <t>
Finally, similar to the grouping "client-cfg-parms" defined in Finally, similar to the grouping "client-cfg-parms" defined in
<xref section="2.1" target="RFC9314"/>, this YANG module defines a grouping <xref section="2.1" target="RFC9314"/>, this YANG module defines a grouping
"bfd-large-common" that may be utilized by BFD clients using "bfd-large-common" that may be utilized by BFD clients using
"client-cfg-params" to uniformly add support for the feature "client-cfg-params" to uniformly add support for the feature
defined in this RFC. defined in this RFC.
</t> </t>
<figure> <figure>
<artwork><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-bfd-large module: ietf-bfd-large
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session: /bfd-ip-sh:sessions/bfd-ip-sh:session:
+--rw pdu-size? padded-pdu-size {padding}? +--rw pdu-size? padded-pdu-size {padding}?
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh /rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
/bfd-ip-mh:session-groups/bfd-ip-mh:session-group: /bfd-ip-mh:session-groups/bfd-ip-mh:session-group:
+--rw pdu-size? padded-pdu-size {padding}? +--rw pdu-size? padded-pdu-size {padding}?
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag /rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session: /bfd-lag:sessions/bfd-lag:session:
+--rw pdu-size? padded-pdu-size {padding}? +--rw pdu-size? padded-pdu-size {padding}?
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls /rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group: /bfd-mpls:session-groups/bfd-mpls:session-group:
+--rw pdu-size? padded-pdu-size {padding}? +--rw pdu-size? padded-pdu-size {padding}?
]]> ]]></sourcecode>
</artwork>
</figure> </figure>
</section> </section>
<section title="YANG Module"> <section>
<name>YANG Module</name>
<t> <t>
This YANG module imports This YANG module imports
<xref target="RFC8349">A YANG Data Model for Routing</xref>, <xref target="RFC8349">"A YANG Data Model for Routing Management (NMDA Version)"</xref>
and and
<xref target="RFC9314">YANG Data Model for Bidirectional Forwadi ng Detection (BFD)</xref>. <xref target="RFC9314">"YANG Data Model for Bidirectional Forwar ding Detection (BFD)"</xref>.
</t> </t>
<figure> <figure>
<artwork><![CDATA[ <sourcecode type="yang" markers="true" name="ietf-bfd-large@
<CODE BEGINS> file "ietf-bfd-large@2025-01-15.yang" 2025-03-31.yang"><![CDATA[
module ietf-bfd-large { module ietf-bfd-large {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-large"; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-large";
prefix "bfdl"; prefix bfdl;
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing Management "RFC 8349: A YANG Data Model for Routing Management
(NMDA version)"; (NMDA version)";
} }
import ietf-bfd { import ietf-bfd {
prefix bfd; prefix bfd;
skipping to change at line 432 skipping to change at line 428
Authors: Jeffrey Haas (jhaas@juniper.net) Authors: Jeffrey Haas (jhaas@juniper.net)
Albert Fu (afu14@bloomberg.net)."; Albert Fu (afu14@bloomberg.net).";
description description
"This YANG module augments the base BFD YANG module to add "This YANG module augments the base BFD YANG module to add
attributes related to support for BFD Encapsulated in Large attributes related to support for BFD Encapsulated in Large
Packets. In particular, it adds a per-session parameter for the Packets. In particular, it adds a per-session parameter for the
BFD Padded PDU Size. BFD Padded PDU Size.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC 9764
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfc9764); see the RFC itself
for full legal notices. for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision "2025-01-15" { revision 2025-03-31 {
description description
"Initial Version."; "Initial Version.";
reference reference
"RFC XXXX, BFD Encapsulated in Large Packets."; "RFC 9764, Bidirectional Forwarding Detection (BFD)
Encapsulated in Large Packets.";
} }
feature padding { feature padding {
description description
"If supported, the feature allows for BFD sessions to be "If supported, the feature allows for BFD sessions to be
configured with padded PDUs in support of BFD Encapsulated in configured with padded PDUs in support of BFD Encapsulated in
Large Packets."; Large Packets.";
} }
typedef padded-pdu-size { typedef padded-pdu-size {
type uint16 { type uint16 {
range "24..65535"; range "24..65535";
} }
units "bytes"; units "bytes";
description description
"The size of the padded and encapsulated BFD control packets "The size of the padded and encapsulated BFD control packets
to be transmitted at layer 3. The BFD minimum control packet to be transmitted at Layer 3. The BFD minimum control packet
size is 24 or 26 octets; see Section 6.8.6 of RFC 5880. size is 24 or 26 octets; see Section 6.8.6 of RFC 5880.
If the configured padded PDU size is smaller than the minimum If the configured padded PDU size is smaller than the minimum
sized packet of a given BFD session, then the minimum sized sized packet of a given BFD session, then the minimum sized
packet for the session will be used. packet for the session will be used.
The maximum padded PDU size may be limited by the supported The maximum padded PDU size may be limited by the supported
interface MTU of the system."; interface MTU of the system.";
reference reference
"RFC XXXX, BFD Encapsulated in Large Packets."; "RFC 9764, Bidirectional Forwarding Detection (BFD)
Encapsulated in Large Packets.";
} }
grouping bfd-large-common { grouping bfd-large-common {
description description
"Common configuration and operational state for BFD "Common configuration and operational state for BFD
Encapsulated in Large Packets."; Encapsulated in Large Packets.";
reference reference
"RFC XXXX, BFD Encapsulated in Large Packets."; "RFC 9764, Bidirectional Forwarding Detection (BFD)
Encapsulated in Large Packets.";
leaf pdu-size { leaf pdu-size {
if-feature "padding"; if-feature "padding";
type padded-pdu-size; type padded-pdu-size;
description description
"If set, this configures the padded PDU size for the "If set, this configures the padded PDU size for the
Asynchronous mode BFD session. By default, no additional Asynchronous mode BFD session. By default, no additional
padding is added to such packets."; padding is added to such packets.";
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
"bfd-ip-sh:sessions/bfd-ip-sh:session" { + "bfd-ip-sh:sessions/bfd-ip-sh:session" {
uses bfd-large-common; uses bfd-large-common;
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets."; Encapsulated in Large Packets.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/" + + "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
"bfd-ip-mh:session-groups/bfd-ip-mh:session-group" { + "bfd-ip-mh:session-groups/bfd-ip-mh:session-group" {
uses bfd-large-common; uses bfd-large-common;
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets."; Encapsulated in Large Packets.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/" + + "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
"bfd-lag:sessions/bfd-lag:session" { + "bfd-lag:sessions/bfd-lag:session" {
uses bfd-large-common; uses bfd-large-common;
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets."; Encapsulated in Large Packets.";
} }
augment "/rt:routing/rt:control-plane-protocols/" + augment "/rt:routing/rt:control-plane-protocols/"
"rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/" + + "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
"bfd-mpls:session-groups/bfd-mpls:session-group" { + "bfd-mpls:session-groups/bfd-mpls:session-group" {
uses bfd-large-common; uses bfd-large-common;
description description
"Augment the 'bfd' container to add attributes related to BFD "Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets."; Encapsulated in Large Packets.";
} }
} }
<CODE ENDS>
]]> ]]>
</artwork> </sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section title="Security Considerations"> <section>
<name>Security Considerations</name>
<t> <t>
This document does not change the underlying security considerations of the BFD protocol This document does not change the underlying security considerations of the BFD protocol
or its encapsulations. or its encapsulations.
</t> </t>
<t> <t>
<!-- This text added to make Eric Vyncke happy -->
On-path attackers that can selectively drop BFD packets, including th ose with large On-path attackers that can selectively drop BFD packets, including th ose with large
MTUs, can cause BFD sessions to go Down. MTUs, can cause BFD sessions to go Down.
</t> </t>
<t> <t>
<!-- This text added to make security people happy. -->
The contents of the padding payload are set to zero. This avoids im plementation issues The contents of the padding payload are set to zero. This avoids im plementation issues
where the local uninitialized data may be leaked. where the local uninitialized data may be leaked.
</t> </t>
<section title="YANG Security Considerations"> <section>
<name>YANG Security Considerations</name>
<t> <t>
This section is modeled after the template described in Section This section is modeled after the template described in
3.7 <xref target="I-D.ietf-netmod-rfc8407bis" sectionFormat="of" sec
of <xref target="I-D.ietf-netmod-rfc8407bis"/>. tion="3.7"/>.
</t> </t>
<t> <t>
The "ietf-bfd-large" YANG module defines a data model that is The "ietf-bfd-large" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, suc h as designed to be accessed via YANG-based management protocols, suc h as
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8 040"/>. These protocols have to NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8 040"/>. These protocols have to
use a secure transport layer (e.g., SSH <xref target="RFC4252"/> , TLS <xref target="RFC8446"/>, and use a secure transport layer (e.g., SSH <xref target="RFC4252"/> , TLS <xref target="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and have to use mutual authentica tion. QUIC <xref target="RFC9000"/>) and have to use mutual authentica tion.
</t> </t>
skipping to change at line 613 skipping to change at line 611
</li> </li>
</ul> </ul>
<t> <t>
There are no particularly sensitive readable data nodes. There are no particularly sensitive readable data nodes.
</t> </t>
<t> <t>
There are no particularly sensitive RPC or action operations. There are no particularly sensitive RPC or action operations.
</t> </t>
<t>
Modules that use the groupings that are defined in this documen
t
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-re
lated
information (e.g., 'node-example'). This module defines one su
ch grouping,
"bfd-large-common", which contains the "pdu-size" data node who
se security
considerations are documented above.
</t>
<t>
Modules that use the groupings that are defined in this document
should identify the
corresponding security considerations. This module defines one s
uch grouping,
"bfd-large-common", which contains the "pdu-size" data node whos
e security
considerations are documented above.
</t>
</section> </section>
</section> </section>
<section title="IANA Considerations"> <section>
<section title="The &quot;IETF XML&quot; Registry"> <name>IANA Considerations</name>
<t>This document registers one URIs in the "ns" subregistry of t <section>
he <name>The &quot;IETF XML&quot; Registry</name>
"IETF XML" registry <xref target="RFC3688"/>. Following the form <t>IANA has registered the following URI in the "ns" subregistry
at in of the
<xref target="RFC3688"/>, the following registration is requeste "IETF XML Registry" <xref target="RFC3688"/>.</t>
d:</t>
<dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-large</dd
>
<dt>Registrant Contact:</dt><dd>The IESG</dd>
<dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</d
d>
</dl>
<figure>
<artwork><![CDATA[URI: urn:ietf:params:xml:ns:yang:ietf-
bfd-large
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
]]>
</artwork>
</figure>
</section> </section>
<section title="The &quot;YANG Module Names&quot; Registry"> <section>
<t>This document registers one YANG modules in the "YANG Module <name>The &quot;YANG Module Names&quot; Registry</name>
Names" <t>IANA has registered the following YANG module in the "YANG Mo
registry <xref target="RFC6020"/>. Following the format in <xref dule Names"
target="RFC6020"/>, the following registrations are requested:</ registry <xref target="RFC6020"/>.</t>
t>
<figure> <dl spacing="compact" newline="false">
<artwork><![CDATA[ <dt>Name:</dt><dd>ietf-bfd-large</dd>
name: ietf-bfd-large <dt>Maintained by IANA:</dt><dd>N</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-large <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-bfd-lar
prefix: bfdl ge</dd>
reference: RFC XXXX <dt>Prefix:</dt><dd>bfdl</dd>
]]></artwork> <dt>Reference:</dt><dd>RFC 9764</dd>
</figure> </dl>
</section>
</section>
<section title="Acknowledgments"> </section>
<t>
The authors would like to thank Les Ginsberg, Mahesh Jethanandani, Ro
bert Raszuk,
and Ketan Talaulikar, for their valuable feedback on this proposal.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R <displayreference target="I-D.haas-xiao-bfd-echo-path-mtu" to="BFD-ECHO-PATH-MTU
FC.0791.xml"/> "/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R <displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>
FC.2119.xml"/> <references>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R <name>References</name>
FC.3688.xml"/> <references>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R <name>Normative References</name>
FC.5880.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.0791.xml"/>
FC.5881.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.2119.xml"/>
FC.5883.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.3688.xml"/>
FC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.5880.xml"/>
FC.7130.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.5881.xml"/>
FC.7880.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.5883.xml"/>
FC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.6020.xml"/>
FC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.7130.xml"/>
FC.8349.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.7880.xml"/>
FC.9314.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.8341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.8349.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
FC.9314.xml"/>
</references> </references>
<references title="Informative References"> <references>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R <name>Informative References</name>
FC.1191.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.1191.xml"/>
FC.4252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.4252.xml"/>
FC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.6241.xml"/>
FC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.8040.xml"/>
FC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.R FC.8446.xml"/>
FC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.R
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference. FC.9000.xml"/>
I-D.haas-xiao-bfd-echo-path-mtu.xml"/> <!-- [I-D.haas-xiao-bfd-echo-path-mtu] draft-haas-xiao-bfd-echo-path-mtu-01
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference. IESG State: Expired as of 03/18/25.
I-D.draft-ietf-netmod-rfc8407bis-22.xml"/> -->
<reference anchor="I-D.haas-xiao-bfd-echo-path-mtu" target="https://datatracker.
ietf.org/doc/html/draft-haas-xiao-bfd-echo-path-mtu-01">
<front>
<title>Application of the BFD Echo function for Path MTU Verification or D
etection</title>
<author initials="X." surname="Min" fullname="Xiao Min" role="editor">
<organization>ZTE Corporation</organization>
</author>
<author initials="J." surname="Haas" fullname="Jeffrey Haas" role="editor"
>
<organization>Juniper Networks</organization>
</author>
<date month="July" day="11" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-haas-xiao-bfd-echo-path-mtu-01
" />
</reference>
<!-- [I-D.ietf-netmod-rfc8407bis] draft-ietf-netmod-rfc8407bis-22
IESG State: Publication Requested as of 03/18/25.
-->
<reference anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.
org/doc/html/draft-ietf-netmod-rfc8407bis-22">
<front>
<title>Guidelines for Authors and Reviewers of Documents Containing YANG D
ata Models</title>
<author initials="A." surname="Bierman" fullname="Andy Bierman">
<organization>YumaWorks</organization>
</author>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" rol
e="editor">
<organization>Orange</organization>
</author>
<author initials="Q." surname="Wu" fullname="Qin Wu">
<organization>Huawei</organization>
</author>
<date month="January" day="14" year="2025" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22" />
</reference>
</references> </references>
</references>
<section numbered="false">
<name>Acknowledgments</name>
<t>
The authors would like to thank <contact fullname="Les
Ginsberg"/>, <contact fullname="Mahesh Jethanandani"/>, <contact
fullname="Robert Raszuk"/>, and <contact fullname="Ketan
Talaulikar"/>, for their valuable feedback on this proposal.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 87 change blocks. 
275 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.48.