rfc8690xml2.original.xml   rfc8690.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' ipr='trust200902' docName='draft-ietf-mpls-rfc8287-len-clari <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
fication-04'
updates="8287">
<front> <rfc number="8690" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<title abbrev="RFC8287 Sub-TLV Length Clarification">RFC8287 Sub-TLV Length Clar ipr="trust200902" docName="draft-ietf-mpls-rfc8287-len-clarification-04"
ification</title> updates="8287" obsoletes="" submissionType="IETF" xml:lang="en" consensus="
true"
tocInclude="true" symRefs="true" sortRefs="true" version="3">
<author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar"> <!-- xml2rfc v2v3 conversion 2.31.0 -->
<organization>Cisco Systems, Inc.</organization> <front>
<address>
<postal>
<street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>277
09</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro"> <title abbrev="Clarification of Segment ID Sub-TLV Length for RFC 8287">Clar
<organization>Cisco Systems, Inc.</organization> ification of Segment ID Sub-TLV Length for RFC 8287</title>
<address>
<postal>
<street>7200-11 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>277
09</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="F." surname="Iqbal" fullname="Faisal Iqbal"> <seriesInfo name="RFC" value="8690" />
<organization>Individual</organization>
<address>
<postal>
<street></street>
<city></city> <region></region> <code></code>
<country>Canada</country>
</postal>
<email>faisal.iqbal@msn.com</email>
</address>
</author>
<author initials="A." surname="Vainshtein" fullname="Alexander Vainshtein"> <author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
<organization>ECI Telecom</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street></street> <street>7200-12 Kit Creek Road</street>
<city></city> <region></region> <code></code> <city>Research Triangle Park</city>
<country>Israel</country> <region>NC</region>
</postal> <code>27709</code>
<email>vainshtein.alex@gmail.com</email> <country>United States of America</country>
</address> </postal>
</author> <email>naikumar@cisco.com</email>
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200-11 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>United States of America</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="F." surname="Iqbal" fullname="Faisal Iqbal">
<organization>Individual</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>Canada</country>
</postal>
<email>faisal.ietf@gmail.com</email>
</address>
</author>
<author initials="A." surname="Vainshtein" fullname="Alexander Vainshtein">
<organization>ECI Telecom</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>Israel</country>
</postal>
<email>vainshtein.alex@gmail.com</email>
</address>
</author>
<date /> <date month="December" year="2019"/>
<area>Internet</area> <area>Internet</area>
<workgroup>Network Work group</workgroup> <workgroup>Network Work group</workgroup>
<keyword>mpls</keyword>
<keyword>mpls</keyword> <abstract>
<abstract><t>RFC8287 defines the extensions to MPLS LSP Ping and <t>RFC 8287 defines the extensions to perform LSP Ping and
Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier ( Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers
SIDs) (SIDs)
with an MPLS data plane. RFC8287 proposes 3 Target FEC Stack Sub-TLVs. While the with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence
standard Class (FEC) Stack sub-TLVs.
defines the format and procedure to handle those Sub-TLVs, it does not sufficien While RFC 8287
tly defines the format and procedure to handle those sub-TLVs, it does not sufficien
clarify how the length of the Segment ID Sub-TLVs should be computed to tly
include in the Length field of the Sub-TLVs which may result in interoperability clarify how the length of the Segment ID sub-TLVs should be computed to be
included in the Length field of the sub-TLVs. This ambiguity has resulted in int
eroperability
issues.</t> issues.</t>
<t>This document updates RFC8287 by clarifying the length of each Segment ID Sub <t>This document updates RFC 8287 by clarifying the length of each of the
-TLVs Segment ID sub-TLVs
defined in RFC8287. defined in RFC 8287.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC8287" /> defines the extensions to MPLS LSP Ping and
Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (
SIDs)
with an MPLS data plane. <xref target="RFC8287" /> proposes 3 Target FEC Stack S
ub-TLVs.
While the standard defines the format and procedure to handle those Sub-TLVs, it
does not sufficiently clarify how the length of the Segment ID Sub-TLVs should b
e computed to
include in the Length field of the Sub-TLVs which may result in interoperability
issues.</t>
<t>This document updates <xref target="RFC8287" /> by clarifying the length of
each Segment ID Sub-TLVs defined in <xref target="RFC8287" />.
</t> </t>
</section> </abstract>
</front>
<section title="Terminology"> <middle>
<section numbered="true" toc="default">
<t>This document uses the terminologies defined in <name>Introduction</name>
<xref target="RFC8402" />, <t><xref target="RFC8287" format="default"/> defines the extensions to MPL
<xref target="RFC8029" />, <xref target="RFC8287" /> S LSP Ping and
and so the readers are expected to be familiar with the same. Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers
</t> (SIDs)
</section> with the MPLS data plane. <xref target="RFC8287" format="default"/> proposes thr
ee Target FEC Stack sub-TLVs.
<section title="Requirements notation"> While RFC 8287 defines the format and procedure to handle those sub-TLVs, it
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", does not sufficiently clarify how the length of the Segment ID sub-TLVs should b
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and e computed to
"OPTIONAL" in this document are to be interpreted as described in BCP be included in the Length field of the sub-TLVs, which may result in interoperab
14 [RFC2119] [RFC8174] when, and only when, they appear in all ility issues.</t>
capitals, as shown here. <t>This document updates <xref target="RFC8287" format="default"/> by clar
</t> ifying the length of
each Segment ID sub-TLVs defined in <xref target="RFC8287" format="default"/>.
</t>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the terminology defined in
<xref target="RFC8402" format="default"/>,
<xref target="RFC8029" format="default"/>, and <xref target="RFC8287"
format="default"/>; readers are expected to be familiar with
the terms as used in those documents.
</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Notation</name>
<section title="Length field clarification for Segment ID Sub-TLVs"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t>Section 5 of <xref target="RFC8287" /> defines 3 different Segment ID IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
Sub-TLVs that NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
will be included in Target FEC Stack TLV defined in <xref target="RFC8029 RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
" />. The "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
length of each Sub-TLVs MUST be calculated as defined in this section. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t>The TLVs representation defined in section 5.1, 5.2 and 5.3 of <xref t </t>
arget="RFC8287" /> are updated
to clarify the length calculation as shown in section 4.1, 4.2 and 4.3 re
spectively.
The updated TLV representation contain explicitly defined length.
</t>
<section title="IPv4 IGP-Prefix Segment ID Sub-TLV">
<t>The Sub-TLV length for IPv4 IGP-Prefix Segment ID MUST be set
to 8 as shown
in the below TLV format:
</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 34 (IPv4 IGP-Prefix SID)| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<name>Length Field Clarification for Segment ID Sub-TLVs</name>
<t><xref target="RFC8287" sectionFormat="of" section="5"/> defines three
different Segment ID sub-TLVs that
can be included in the Target FEC Stack TLV defined in <xref
target="RFC8029" format="default"/>.
<section title="IPv6 IGP-Prefix Segment ID Sub-TLV"> The length of each sub-TLV <bcp14>MUST</bcp14> be calculated as defined in
<t>The Sub-TLV length for IPv6 IGP-Prefix Segment ID MUST be set this section.
to 20 as shown </t>
in the below TLV format: <t>The TLV representations defined in Sections <xref target="RFC8287"
</t> section="5.1" sectionFormat="bare"/>, <xref target="RFC8287"
<figure> section="5.2" sectionFormat="bare"/>, and <xref target="RFC8287"
<artwork><![CDATA[ section="5.3" sectionFormat="bare"/> of <xref target="RFC8287"/> are
updated to clarify the length calculations, as shown in Sections <xref
target="ipv4-segment-id-subtlv" format="counter"/>, <xref
target="ipv6-segment-id-subtlv" format="counter"/>,
and <xref target="igp-segment-id-subtlv" format="counter"/>,
respectively. The updated TLV representations contain explicitly
defined lengths.
</t>
<section numbered="true" toc="default" anchor="ipv4-segment-id-subtlv">
<name>IPv4 IGP-Prefix Segment ID Sub-TLV</name>
<t>The sub-TLV length for the IPv4 IGP-Prefix Segment ID <bcp14>MUST</bc
p14> be set to 8, as shown
in the TLV format below:
</t>
<artwork name="" type="" align="center" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 34 (IPv4 IGP-Prefix SID)| Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</section>
<section numbered="true" toc="default" anchor="ipv6-segment-id-subtlv">
<name>IPv6 IGP-Prefix Segment ID Sub-TLV</name>
<t>The sub-TLV length for the IPv6 IGP-Prefix Segment ID <bcp14>MUST</bc
p14> be set to 20, as shown
in the TLV format below:
</t>
<artwork name="" type="" align="center" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 35 (IPv6 IGP-Prefix SID)| Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| IPv6 Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</section>
<section numbered="true" toc="default" anchor="igp-segment-id-subtlv">
<name>IGP-Adjacency Segment ID Sub-TLV</name>
<t>The sub-TLV length for the IGP-Adjacency Segment ID varies depending
on the
Adjacency Type and Protocol. In any of the allowed combinations o
f Adjacency Type
and Protocol, the sub-TLV length <bcp14>MUST</bcp14> be
calculated by including 2 octets of the
Reserved field. <xref target="demo"/> lists the length for differ
ent combinations
of Adj. Type and Protocol.
</t>
0 1 2 3 <table anchor="demo" align="center">
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 <name>IGP-Adjacency SID Length Computation</name>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <thead>
|Type = 35 (IPv6 IGP-Prefix SID)| Length = 20 | <tr>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <th rowspan="2" colspan="1">Protocol</th>
| | <th rowspan="1" colspan="4">Length for Adj. Type</th>
| | </tr>
| IPv6 Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> <tr>
</figure> <th align="center">Parallel</th>
</section> <th align="center">IPv4</th>
<th align="center">IPv6</th>
<th align="center">Unnumbered</th>
</tr>
<section title="IGP-Adjacency Segment ID Sub-TLV"> </thead>
<t>The Sub-TLV length for IGP-Adjacency Segment ID varies depending on the <tbody>
Adjacency Type and Protocol. In any of the allowed combination of <tr>
Adjacency Type <td align="center">OSPF</td>
and Protocol, the sub-TLV length MUST be calculated by including <td align="center">20</td>
2 octets of <td align="center">20</td>
Reserved field. Table 1 below list the length for different combi <td align="center">44</td>
nations <td align="center">20</td>
of Adj.Type and Protocol. </tr>
</t> <tr>
<figure> <td align="center">ISIS</td>
<artwork><![CDATA[ <td align="center">24</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="center">24</td>
| Protocol | Length for Adj.Type | <td align="center">48</td>
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="center">24</td>
| | Parallel | IPv4 | IPv6 | Unnumbered| </tr>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <tr>
| OSPF | 20 | 20 | 44 | 20 | <td align="center">Any</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="center">20</td>
| ISIS | 24 | 24 | 48 | 24 | <td align="center">20</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <td align="center">44</td>
| Any | 20 | 20 | 44 | 20 | <td align="center">20</td>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </tr>
Table 1. IGP-Adjacency SID Length Comparison </tbody>
</table>
]]></artwork> <t>
</figure>
<t>
For example, when the Adj. Type is set to Parallel Adjacency For example, when the Adj. Type is set to Parallel Adjacency
and the Protocol is set to 0, the Sub-TLV will be as below: and the Protocol is set to 0, the sub-TLV will be as below:
</t> </t>
<figure> <artwork name="" type="" align="center" alt=""><![CDATA[
<artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 36 (IGP-Adjacency SID) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 36 (IGP-Adjacency SID) | Length = 20 | | Adj. Type = 1 | Protocol = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type = 1 | Protocol = 0 | Reserved | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) | | Advertising Node Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Node Identifier (4 octets) | | Receiving Node Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
| Receiving Node Identifier (4 octets) | </section>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section> </section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations">
<t>This document does not introduce any IANA consideration.
</t>
</section>
<section title="Security Considerations">
<t>This document updates <xref target="RFC8287" /> and does not i
ntroduce
any additional security considerations.
</t>
</section>
<section title="Contributors"> <t>IANA has listed this document as an additional reference for
the following entries in the "Sub-TLVs for TLV Types 1, 16, and
21" registry:</t>
<t>The below individuals contributed to this document: <table anchor="iana">
<list> <name>Sub-TLVs for TLV Types 1, 16, and 21 (Updated Entries)</name>
<t>Zafar Ali, Cisco Systems, Inc.</t> <thead>
</list> <tr>
</t> <th>Sub-Type</th>
<th>Sub-TLV Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>34</td>
<td>IPv4 IGP-Prefix Segment ID</td>
<td><xref target="RFC8287" sectionFormat="of"
section="5.1"/>,
This document</td>
</tr>
<tr>
<td>35</td>
<td>IPv6 IGP-Prefix Segment ID</td>
<td><xref target="RFC8287" sectionFormat="of"
section="5.2"/>, This document</td>
</tr>
<tr>
<td>36</td>
<td>IGP-Adjacency Segment ID</td>
<td><xref target="RFC8287" sectionFormat="of"
section="5.3"/>, This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section title="Acknowledgement"> <section numbered="true" toc="default">
<t>The authors would like to thank Michael Gorokhovsky and Manoha <name>Security Considerations</name>
r Doppalapudi <t>This document updates <xref target="RFC8287" format="default"/> and doe
for investigating the interop issue during EANTC test.</t> s not introduce
</section> any additional security considerations.
</t>
</middle> </section>
</middle>
<back> <back>
<references>
<references title="Normative References"> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<?rfc include="reference.RFC.2119"?> ce.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<?rfc include="reference.RFC.8174"?> ce.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<?rfc include="reference.RFC.8402"?> ce.RFC.8402.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<?rfc include="reference.RFC.8029"?> ce.RFC.8029.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
<?rfc include="reference.RFC.8287"?> ce.RFC.8287.xml"/>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank Michael Gorokhovsky and Manohar Doppala
pudi
for investigating the interoperability issue during European
Advanced Network Test Center (EANTC) testing.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The following individual contributed to this document: Zafar Ali, Cisco
Systems, Inc.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 29 change blocks. 
267 lines changed or deleted 321 lines changed or added

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