rfc9247xml2.original.xml   rfc9247.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-sbfd-extensions-10"
ipr="trust200902">
<front>
<title abbrev="BGP-LS Extensions for S-BFD">BGP Link-State Extensions for
Seamless BFD</title>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-bgp-ls-s
bfd-extensions-10" number="9247" submissionType="IETF" category="std" consensus=
"true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
tocDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.6 -->
<!-- [rfced] Please note that the title has been updated as
follows. The abbreviation has been expanded per Section 3.6 of
RFC 7322 ("RFC Style Guide"), and "BGP Link-State" has been
updated to "BGP - Link State (BGP-LS)" per standard usage in past
RFCs.
Also, since "Seamless" BFD is used, we updated the acronym to "S-BFD".
If that is not correct, please let us know.
Original:
BGP Link-State Extensions for Seamless BFD
Current:
BGP - Link State (BGP-LS) Extensions for Seamless
Bidirectional Forwarding Detection (S-BFD)
-->
<front>
<title abbrev="BGP-LS Extensions for S-BFD">BGP - Link State (BGP-LS) Extens
ions for
Seamless Bidirectional Forwarding Detection (S-BFD)</title>
<seriesInfo name="RFC" value="9247"/>
<author fullname="Zhenbin Li" initials="Z. " surname="Li"> <author fullname="Zhenbin Li" initials="Z. " surname="Li">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street> <extaddr>Huawei Bld.</extaddr>
<street>No.156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>lizhenbin@huawei.com</email> <email>lizhenbin@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Shunwan Zhuang" initials="S. " surname="Zhuang"> <author fullname="Shunwan Zhuang" initials="S. " surname="Zhuang">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street> <extaddr>Huawei Bld.</extaddr>
<street>No.156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<code>100095</code> <code>100095</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhuangshunwan@huawei.com</email> <email>zhuangshunwan@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K." role="editor" surname="Tal
<author fullname="Ketan Talaulikar" initials="K." role="editor" aulikar">
surname="Talaulikar"> <organization>Arrcus, Inc.</organization>
<organization>Arrcus Inc</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Sam Aldrin" initials="S." surname="Aldrin"> <author fullname="Sam Aldrin" initials="S." surname="Aldrin">
<organization>Google, Inc</organization> <organization>Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>aldrin.ietf@gmail.com</email> <email>aldrin.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials=" J." surname="Tantsura"> <author fullname="Jeff Tantsura" initials=" J." surname="Tantsura">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials=" G." surname="Mirsky"> <author fullname="Greg Mirsky" initials=" G." surname="Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="June" />
<date year=""/> <area>rtg</area>
<workgroup>idr</workgroup>
<area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>BFD</keyword> <keyword>BFD</keyword>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<keyword>OSPFv3</keyword> <keyword>OSPFv3</keyword>
<abstract> <abstract>
<t>Seamless Bidirectional Forwarding Detection (S-BFD) defines a <t>Seamless Bidirectional Forwarding Detection (S-BFD) defines a
simplified mechanism to use Bidirectional Forwarding Detection (BFD) simplified mechanism to use Bidirectional Forwarding Detection (BFD)
with large portions of negotiation aspects eliminated, thus providing with large portions of negotiation aspects eliminated, thus providing
benefits such as quick provisioning as well as improved control and benefits such as quick provisioning as well as improved control and
flexibility to network nodes initiating the path monitoring. The flexibility to network nodes initiating the path monitoring. The
link-state routing protocols (IS-IS and OSPF) have been extended to link-state routing protocols (IS-IS and OSPF) have been extended to
advertise the Seamless BFD (S-BFD) Discriminators.</t> advertise the S-BFD Discriminators.</t>
<t>This document defines extensions to the BGP - Link State (BGP-LS) addre
<t>This document defines extensions to the BGP Link-state address-family ss family
to carry the S-BFD Discriminators' information via BGP.</t> to carry the S-BFD Discriminators' information via BGP.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="INTRO" title="Introduction"> <section anchor="INTRO" numbered="true" toc="default">
<t>Seamless Bidirectional Forwarding Detection (S-BFD) <xref <name>Introduction</name>
target="RFC7880"/> defines a simplified mechanism to use Bidirectional <t>Seamless Bidirectional Forwarding Detection (S-BFD) <xref target="RFC78
Forwarding Detection (BFD) <xref target="RFC5880"/> with large portions 80" format="default"/> defines a simplified mechanism to use Bidirectional
Forwarding Detection (BFD) <xref target="RFC5880" format="default"/> with
large portions
of negotiation aspects eliminated, thus providing benefits such as quick of negotiation aspects eliminated, thus providing benefits such as quick
provisioning as well as improved control and flexibility to network provisioning as well as improved control and flexibility to network
nodes initiating the path monitoring.</t> nodes initiating the path monitoring.</t>
<t>For the monitoring of a service path end to end via S-BFD, the headend
<t>For monitoring of a service path end-to-end via S-BFD, the headend node (i.e., Initiator) needs to know the S-BFD Discriminator of the
node (i.e. Initiator) needs to know the S-BFD Discriminator of the destination/tail-end node (i.e., Responder) of that service. The
destination/tail-end node (i.e. Responder) of that service. The link-state routing protocols (IS-IS <xref target="RFC7883" format="default
link-state routing protocols (IS-IS <xref target="RFC7883"/> and OSPF "/> and OSPF
<xref target="RFC7884"/>) have been extended to advertise the S-BFD <xref target="RFC7884" format="default"/>) have been extended to advertise
the S-BFD
Discriminators. With this, an Initiator can learn the S-BFD Discriminators. With this, an Initiator can learn the S-BFD
discriminator for all Responders within its IGP area/level, or Discriminator for all Responders within its IGP area/level or
optionally within the domain. With networks being divided into multiple optionally within the domain. With networks being divided into multiple
IGP domains for scaling and operational considerations, the service IGP domains for scaling and operational considerations, the service
endpoints that require end to end S-BFD monitoring often span across IGP endpoints that require end-to-end S-BFD monitoring often span across IGP
domains.</t> domains.</t>
<t>BGP - Link State (BGP-LS) <xref target="RFC7752" format="default"/> ena
<t>BGP Link-State (BGP-LS) <xref target="RFC7752"/> enables the bles the
collection and distribution of IGP link-state topology information via collection and distribution of IGP link-state topology information via
BGP sessions across IGP areas/levels and domains. The S-BFD BGP sessions across IGP areas/levels and domains. The S-BFD
discriminator(s) of a node can thus be distributed along with the Discriminator(s) of a node can thus be distributed along with the
topology information via BGP-LS across IGP domains and even across topology information via BGP-LS across IGP domains and even across
multiple Autonomous Systems (AS) within an administrative domain.</t> multiple Autonomous Systems (ASes) within an administrative domain.</t>
<t>This document defines extensions to BGP-LS for carrying the S-BFD <t>This document defines extensions to BGP-LS for carrying the S-BFD
Discriminators information.</t> Discriminators' information.</t>
</section> </section>
<section anchor="TERM" numbered="true" toc="default">
<name>Terminology</name>
<t>This memo makes use of the terms defined in <xref target="RFC7880" form
at="default"/>.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section anchor="TERM" title="Terminology"> <t>
<t>This memo makes use of the terms defined in <xref The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
target="RFC7880"/>.</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<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 title="Requirements Language">
<t>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 BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="SBFDDISC" numbered="true" toc="default">
<section anchor="SBFDDISC" <name>BGP-LS Extensions for S-BFD Discriminators</name>
title="BGP-LS Extensions for S-BFD Discriminator"> <t>BGP-LS <xref target="RFC7752" format="default"/> specifies the Node Net
<t>BGP-LS <xref target="RFC7752"/> specifies the Node Network Layer work Layer
Reachability Information (NLRI) for the advertisement of nodes and their Reachability Information (NLRI) for the advertisement of nodes and their
attributes using the BGP-LS Attribute. The S-BFD discriminators of a attributes using the BGP-LS Attribute. The S-BFD Discriminators of a
node are considered a node-level attribute and advertised as such.</t> node are considered a node-level attribute and are advertised as such.</t>
<t>This document defines a new BGP-LS Attribute TLV called "S-BFD
<t>This document defines a new BGP-LS Attribute TLV called the S-BFD Discriminators TLV", and its format is as follows:</t>
Discriminators TLV and its format is as follows:</t> <figure title="S-BFD Discriminators TLV ">
<artwork align="center" name="" type="" alt=""><![CDATA[
<t><figure>
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator 1 | | Discriminator 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator 2 (Optional) | | Discriminator 2 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Discriminator n (Optional) | | Discriminator n (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>where:
</t>
Figure 1: S-BFD Discriminators TLV <dl>
where: <dt>Type:
]]></artwork> </dt>
</figure><list style="symbols"> <dd>1032
<t>Type: 1032</t> </dd>
<t>Length: variable. It MUST be a minimum of 4 octets and increments <dt>Length:
by 4 octets for each additional discriminator.</t> </dt>
<dd>variable. It <bcp14>MUST</bcp14> be a minimum of 4 octets, and it increments
by 4 octets for each additional discriminator.
</dd>
<t>Discriminator n: 4 octets each, carrying an S-BFD local <dt>Discriminator n:
discriminator value of the node. At least one discriminator MUST be </dt>
included in the TLV.</t> <dd>4 octets each, carrying an S-BFD local discriminator value of the node. At
</list></t> least one discriminator <bcp14>MUST</bcp14> be included in the TLV.
</dd>
<t>The S-BFD Discriminators TLV can be added to the BGP-LS Attribute </dl>
<t>The S-BFD Discriminators TLV can be added to the BGP-LS Attribute
associated with the Node NLRI that originates the corresponding associated with the Node NLRI that originates the corresponding
underlying IGP TLV/sub-TLV as described below. This information is underlying IGP TLV/sub-TLV as described below. This information is
derived from the protocol specific advertisements as follows:<list derived from the protocol-specific advertisements as follows:</t>
style="symbols"> <ul spacing="normal">
<t>IS-IS, as defined by the S-BFD Discriminators sub-TLV in <xref <li>IS-IS, as defined by the S-BFD Discriminators sub-TLV in <xref targe
target="RFC7883"/>.</t> t="RFC7883" format="default"/>.</li>
<li>OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in <xref ta
<t>OSPFv2/OSPFv3, as defined by the S-BFD Discriminator TLV in <xref rget="RFC7884"
target="RFC7884"/>.</t> format="default"/>.</li>
</list></t> </ul>
</section>
<section anchor="IANA" title="IANA Considerations"> </section>
<t>IANA is requested to permanently allocate the following code-point <section anchor="IANA" numbered="true" toc="default">
from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, <name>IANA Considerations</name>
<t>IANA has permanently allocated the following code point
in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor,
and Attribute TLVs" registry. The column "IS-IS TLV/Sub-TLV" defined in and Attribute TLVs" registry. The column "IS-IS TLV/Sub-TLV" defined in
the registry does not require any value and should be left empty.</t> the registry does not require any value and should be left empty.</t>
<figure> <!--[rfced] FYI: per IANA's note, the authors have agreed to remove
<artwork align="center"><![CDATA[ "TLV" from the description in Table 1 to match the IANA registry;
+------------+--------------------------+---------------+ this change is now reflected.
| Code Point | Description | Reference | -->
+------------+--------------------------+---------------+
| 1032 | S-BFD Discriminators TLV | This document |
+---------------+--------------------------+------------+
Table 1: S-BFD Discriminators TLV Code-Point Allocation
]]></artwork> <table>
</figure> <name>S-BFD Discriminators TLV Code Point Allocation</name>
</section> <thead>
<tr>
<th>TLV Code Point</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>1032</td>
<td>S-BFD Discriminators</td>
<td>This document</td>
</tr>
</tbody>
</table>
<section anchor="Manageability" title="Manageability Considerations"> </section>
<section anchor="Manageability" numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>The new protocol extensions introduced in this document augment the <t>The new protocol extensions introduced in this document augment the
existing IGP topology information that was distributed via BGP-LS <xref existing IGP topology information that was distributed via BGP-LS <xref ta
target="RFC7752"/>. Procedures and protocol extensions defined in this rget="RFC7752" format="default"/>. Procedures and protocol extensions defined in
document do not affect the BGP protocol operations and management other this
than as discussed in the Manageability Considerations section of <xref document do not affect BGP protocol operations and management other
target="RFC7752"/>. Specifically, the malformed NLRIs attribute tests in than as discussed in "Manageability Considerations" (Section <xref target=
the Fault Management section of <xref target="RFC7752"/> now encompass "RFC7752"
section="6" sectionFormat="bare"/>) of <xref target="RFC7752" format="defa
ult"/>. Specifically, the malformed NLRIs attribute tests in
"Fault Management" (Section <xref target="RFC7752"
section="6.2.2" sectionFormat="bare"/>) of <xref target="RFC7752" format="
default"/> now encompass
the new TLV for the BGP-LS NLRI in this document.</t> the new TLV for the BGP-LS NLRI in this document.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The new protocol extensions introduced in this document augment the <t>The new protocol extensions introduced in this document augment the
existing IGP topology information that can be distributed via BGP-LS existing IGP topology information that can be distributed via BGP-LS
<xref target="RFC7752"/>. Procedures and protocol extensions defined in <xref target="RFC7752" format="default"/>. Procedures and protocol extensi ons defined in
this document do not affect the BGP security model other than as this document do not affect the BGP security model other than as
discussed in the Security Considerations section of <xref discussed in "Security Considerations" (Section <xref target="RFC7752"
target="RFC7752"/>. More specifically, the aspects related to limiting section="8" sectionFormat="bare"/>) of <xref target="RFC7752" format="defa
ult"/>, i.e., the aspects related to limiting
the nodes and consumers with which the topology information is shared the nodes and consumers with which the topology information is shared
via BGP-LS to trusted entities within an administrative domain.</t> via BGP-LS to trusted entities within an administrative domain.</t>
<t>The TLV introduced in this document is used to propagate IGP-defined
<t>The TLV introduced in this document is used to propagate IGP defined information (see <xref target="RFC7883" format="default"/> and <xref targe
information (<xref target="RFC7883"/> and <xref target="RFC7884"/>). The t="RFC7884" format="default"/>). The
TLV represents information used to set up S-BFD sessions. The IGP TLV represents information used to set up S-BFD sessions. The IGP
instances originating this information are assumed to support any instances originating this information are assumed to support any
required security and authentication mechanisms (as described in <xref required security and authentication mechanisms (as described in <xref tar
target="RFC7883"/> and <xref target="RFC7884"/>).</t> get="RFC7883" format="default"/> and <xref target="RFC7884" format="default"/>).
</t>
<t>Advertising the S-BFD Discriminators via BGP-LS makes it possible for <t>Advertising the S-BFD Discriminators via BGP-LS makes it possible for
attackers to initiate S-BFD sessions using the advertised information. attackers to initiate S-BFD sessions using the advertised information.
The vulnerabilities this poses and how to mitigate them are discussed in The vulnerabilities this poses and how to mitigate them are discussed in
<xref target="RFC7880"/>.</t> <xref target="RFC7880" format="default"/>.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Nan Wu for his contributions to this
work. The authors would also like to thank Gunter Van De Velde and
Thomas Fossati for their reviews. The authors would also like to thank
Jeff Haas for his shepherd review and Alvaro Retana for his AD review of
this document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<references>
<?rfc include='reference.RFC.7752'?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7880'?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7883.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7884.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5880.xml"/>
</references>
</references>
<?rfc include='reference.RFC.7883'?> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Nan Wu"/> for his
contributions to this work. The authors would also like to thank
<contact fullname="Gunter Van de Velde"/> and <contact fullname="Thomas
Fossati"/> for their reviews as well as
<contact fullname="Jeff Haas"/> for his shepherd review and <contact
fullname="Alvaro Retana"/> for his AD review of this document.</t>
</section>
<?rfc include='reference.RFC.7884'?> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
<?rfc include='reference.RFC.8174'?> Note that we did not find any words that might require consideration, but this
</references> should still be reviewed as a best practice.
-->
<references title="Informative References">
<?rfc include='reference.RFC.5880'?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 83 change blocks. 
187 lines changed or deleted 217 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/