rfc8663xml2.original.xml   rfc8663.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- [rfced] updated by Chris /07/23/19 --> nsus="true" docName="draft-ietf-mpls-sr-over-ip-07" indexInclude="true" ipr="tru
st200902" number="8663" prepTime="2019-12-04T21:02:22" scripts="Common,Latin" so
<?rfc toc="yes"?> rtRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true
<?rfc tocompact="yes"?> " xml:lang="en">
<?rfc tocdepth="3"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip-07" re
<?rfc tocindent="yes"?> l="prev"/>
<?rfc symrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8663" rel="alternate"/>
<?rfc sortrefs="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc submissionType="IETF" category="std" consensus="yes" number="XXXX" ipr="tru
st200902">
<front> <front>
<title abbrev="SR-MPLS over IP">SR-MPLS over IP</title> <title abbrev="SR-MPLS-over-IP">MPLS Segment Routing over IP</title>
<seriesInfo name="RFC" value="8663" stream="IETF"/>
<author fullname="Xiaohu Xu" initials="X." surname="Xu"> <author fullname="Xiaohu Xu" initials="X." surname="Xu">
<organization>Alibaba, Inc</organization> <organization showOnFrontPage="true">Alibaba, Inc</organization>
<address> <address>
<email>xiaohu.xxh@alibaba-inc.com</email> <email>xiaohu.xxh@alibaba-inc.com</email>
</address> </address>
</author> </author>
<author fullname="Stewart Bryant" initials="S." surname="Bryant">
<author fullname="Stewart Bryant" initials="S." surname="Bryant "> <organization showOnFrontPage="true">Futurewei Technologies</organization>
<organization>Huawei</organization>
<address> <address>
<email>stewart.bryant@gmail.com</email> <email>stewart.bryant@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<author fullname="Adrian Farrel" initials="A." surname="Farrel "> <organization showOnFrontPage="true">Old Dog Consulting</organization>
<organization>Old Dog Consulting</organization>
<address> <address>
<email>adrian@olddog.co.uk</email> <email>adrian@olddog.co.uk</email>
</address> </address>
</author> </author>
<author fullname="Syed Hassan" initials="S." surname="Hassan"> <author fullname="Syed Hassan" initials="S." surname="Hassan">
<organization>Cisco</organization> <organization showOnFrontPage="true">Cisco</organization>
<address> <address>
<email>shassan@cisco.com</email> <email>shassan@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx"> <author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization>Nokia</organization> <organization showOnFrontPage="true">Nokia</organization>
<address> <address>
<email>wim.henderickx@nokia.com</email> <email>wim.henderickx@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Zhenbin Li" initials="Z." surname="Li"> <author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei</organization> <organization showOnFrontPage="true">Huawei</organization>
<address> <address>
<email>lizhenbin@huawei.com</email> <email>lizhenbin@huawei.com</email>
</address> </address>
</author> </author>
<date month="12" year="2019"/>
<keyword>MPLS-SR-over-IP, SR-MPLS-over-IP, MPLS-SR-over-UDP, SR-MPLS-over-UD
P</keyword>
<abstract pn="section-abstract">
<t pn="section-abstract-1">MPLS Segment Routing (SR-MPLS) is a method of s
ource routing a packet
through an MPLS data plane by imposing a stack of MPLS labels on the
packet to specify the path together with any packet-specific
instructions to be executed on it.
<date year="2019" month="July"/> SR-MPLS can be leveraged to realize a source-routing mechanism across
MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a
<!-- [rfced] Please insert any keywords (beyond those that appear in source-routing instruction set while making no changes to SR-MPLS
the title) for use on https://www.rfc-editor.org/search. --> specifications and interworking with SR-MPLS implementations.</t>
<t pn="section-abstract-2">This document describes how SR-MPLS-capable rou
<keyword>example</keyword> ters and IP-only
routers can seamlessly coexist and interoperate through the use of
<abstract> SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP
<t>MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source
routing paradigm in which the sender of a packet is allowed to partially
or completely specify the route the packet takes through the network by
imposing stacked MPLS labels on the packet. SR-MPLS can be leveraged
to realize a source routing mechanism across MPLS, IPv4, and IPv6 data
planes by using an MPLS label stack as a source routing instruction set
while making no changes to SR-MPLS specifications and interworking with
SR-MPLS implementations.</t>
<t>This document describes how SR-MPLS capable routers and IP-only
routers can seamlessly co-exist and interoperate through the use of
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in-UDP
as defined in RFC 7510.</t> as defined in RFC 7510.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="section-boilerplate.1-2">
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.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8663" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-introduction">Introductio
n</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-terminology">
Terminology</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-use-cases">Use Cases</xre
f></t>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-procedures-of-sr-mpls-ove
r-">Procedures of SR-MPLS-over-IP</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derive
dContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-forwarding-en
try-constructi">Forwarding Entry Construction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.1.2">
<li pn="section-toc.1-1.3.2.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.1.2.1.1"><xre
f derivedContent="3.1.1" format="counter" sectionFormat="of" target="section-3.1
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-f
ib-construction-example">FIB Construction Example</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.2">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derive
dContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-packet-forwar
ding-procedure">Packet-Forwarding Procedures</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.1.1"><xre
f derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-p
acket-forwarding-with-penu">Packet Forwarding with Penultimate Hop Popping</xref
></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.2.1"><xre
f derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-p
acket-forwarding-without-p">Packet Forwarding without Penultimate Hop Popping</x
ref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.3">
<t keepWithNext="true" pn="section-toc.1-1.3.2.2.2.3.1"><xre
f derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2
.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a
dditional-forwarding-proce">Additional Forwarding Procedures</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-security-considerations">
Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-references">References</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derive
dContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-normative-ref
erences">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derive
dContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-informative-r
eferences">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-acknowledgements">Ackno
wledgements</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-contributors">Contribut
ors</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-authors-addresses">Auth
ors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t>MPLS Segment Routing (SR-MPLS) <xref <name slugifiedName="name-introduction">Introduction</name>
target="RFCYYYY"/> is an MPLS data <t pn="section-1-1">MPLS Segment Routing (SR-MPLS) <xref target="RFC8660"
plane-based source routing paradigm in which the sender of a packet is format="default" sectionFormat="of" derivedContent="RFC8660"/> is a method of so
allowed to partially or completely specify the route the packet takes urce routing a packet through an
through the network by imposing stacked MPLS labels on the packet. MPLS data plane. This is achieved by the sender imposing a stack of MPLS
SR-MPLS uses an MPLS label stack to encode a source routing instruction labels that partially or completely specify the path that the packet is
set. This can be used to realize a source routing mechanism that can to take and any instructions to be executed on the packet as it passes
operate across MPLS, IPv4, and IPv6 data planes. This approach through the network.
makes no changes to SR-MPLS specifications and allows interworking with
SR-MPLS implementations. More specifically, the source routing
instruction set information contained in a source routed packet could be
uniformly encoded as an MPLS label stack no matter whether the underlay is
IPv4, IPv6 (including Segment Routing for IPv6 (SRv6) [RFC8354]), or MPLS.
</t>
<t>This document describes how SR-MPLS capable routers and IP-only
routers can seamlessly co-exist and interoperate through the use of
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in-UDP
<xref target="RFC7510"/>.</t>
<t><xref target="usecases"/> describes various use cases for the
tunneling SR-MPLS over IP. <xref target="procs"/> describes a typical
application scenario and how the packet forwarding happens.</t>
<section anchor="Abbreviations_Terminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref
target="RFC3031"/> and <xref
target="RFCYYYY"/>.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SR-MPLS uses an MPLS label stack to encode a sequence of source-routing
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and instructions. This can be used to realize a source-routing mechanism
"OPTIONAL" in this document are to be interpreted as described in BCP that can operate across MPLS, IPv4, and IPv6 data planes. This approach
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only makes no changes to SR-MPLS specifications and allows interworking with
when, they appear in all capitals, as shown here.</t> SR-MPLS implementations. More specifically, the source-routing
instructions in a source-routed packet could be
uniformly encoded as an MPLS label stack regardless of whether the
underlay is IPv4, IPv6 (including Segment Routing for IPv6 (SRv6) <xref ta
rget="RFC8354" format="default" sectionFormat="of" derivedContent="RFC8354"/>),
or MPLS.</t>
<t pn="section-1-2">This document describes how SR-MPLS-capable routers an
d IP-only
routers can seamlessly coexist and interoperate through the use of
SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP
<xref target="RFC7510" format="default" sectionFormat="of" derivedContent=
"RFC7510"/>.</t>
<t pn="section-1-3"><xref target="usecases" format="default" sectionFormat
="of" derivedContent="Section 2"/> describes various use
cases for tunneling SR-MPLS over IP. <xref target="procs" format="default"
sectionFormat="of" derivedContent="Section 3"/> describes a typical application
scenario and how the
packet forwarding happens.</t>
<section anchor="Abbreviations_Terminology" numbered="true" toc="include"
removeInRFC="false" pn="section-1.1">
<name slugifiedName="name-terminology">Terminology</name>
<t pn="section-1.1-1">This memo makes use of the terms defined in <xref
target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/>
and <xref target="RFC8660" format="default" sectionFormat="of" derivedContent="R
FC8660"/>.</t>
<t pn="section-1.1-2">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</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 14 <xref target="RFC2119" format="default" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
ear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="usecases" numbered="true" toc="include" removeInRFC="false"
<section anchor="usecases" title="Use Cases"> pn="section-2">
<t>Tunneling SR-MPLS using IPv4 and/or IPv6 (including SRv6) tunnels is <name slugifiedName="name-use-cases">Use Cases</name>
<t pn="section-2-1">Tunneling SR-MPLS using IPv4 and/or IPv6 (including SR
v6) tunnels is
useful at least in the use cases listed below. In all cases, this can be useful at least in the use cases listed below. In all cases, this can be
enabled using an IP tunneling mechanism such as MPLS-in-UDP as described enabled using an IP tunneling mechanism such as MPLS-over-UDP as described
in <xref target="RFC7510"/>. The tunnel selected MUST have its remote end in <xref target="RFC7510" format="default" sectionFormat="of" derivedConte
point (destination) address equal to the address of the next SR-MPLS nt="RFC7510"/>. The tunnel selected <bcp14>MUST</bcp14> have its remote
capable node identified as being on the SR path (i.e., the egress of the endpoint (destination) address equal to the address of the next
active segment). The local end point (source) address is set to an address node capable of SR-MPLS identified as being on the SR path (i.e., the
of the encapsulating node. <xref target="RFC7510"/> gives further advice egress of the active segment). The local endpoint (source) address is
on how to set the source address if the UDP zero-checksum mode is used set to an address of the encapsulating node. <xref target="RFC7510" format
with MPLS-in-UDP. Using UDP as the encapsulation may be particularly ="default" sectionFormat="of" derivedContent="RFC7510"/>
beneficial because it is agnostic of the underlying transport.</t> gives further advice on how to set the source address if the UDP
zero-checksum mode is used with MPLS-over-UDP. Using UDP as the
<t><list style="symbols"> encapsulation may be particularly beneficial because it is agnostic of
<t>Incremental deployment of the SR-MPLS technology may be the underlying transport.</t>
<ul spacing="normal" bare="false" empty="false" pn="section-2-2">
<li pn="section-2-2.1">
<t pn="section-2-2.1.1">Incremental deployment of the SR-MPLS technolo
gy may be
facilitated by tunneling SR-MPLS packets across parts of a network facilitated by tunneling SR-MPLS packets across parts of a network
that are not SR-MPLS as shown in <xref target="islandsFig"/>. This that are not SR-MPLS as shown in <xref target="islandsFig" format="def ault" sectionFormat="of" derivedContent="Figure 1"/>. This
demonstrates how islands of SR-MPLS may be connected across a legacy demonstrates how islands of SR-MPLS may be connected across a legacy
network. It may be particularly useful for joining sites (such as network. It may be particularly useful for joining sites (such as
data centers). data centers).
<figure anchor="islandsFig" </t>
title="SR-MPLS in UDP to Tunnel Between SR-MPLS Sites"> <figure anchor="islandsFig" align="left" suppress-title="false" pn="fi
<artwork><![CDATA[ gure-1">
<name slugifiedName="name-sr-mpls-over-udp-to-tunnel-">SR-MPLS-over-
UDP to Tunnel between SR-MPLS Sites</name>
<artwork name="" type="" align="left" alt="" pn="section-2-2.1.2.1">
________________________ ________________________
_______ ( ) _______ _______ ( ) _______
( ) ( IP Network ) ( ) ( ) ( IP Network ) ( )
( SR-MPLS ) ( ) ( SR-MPLS ) ( SR-MPLS ) ( ) ( SR-MPLS )
( Network ) ( ) ( Network ) ( Network ) ( ) ( Network )
( -------- -------- ) ( -------- -------- )
( | Border | SR-in-UDP Tunnel | Border | ) ( | Border | SR-in-UDP Tunnel | Border | )
( | Router |========================| Router | ) ( | Router |========================| Router | )
( | R1 | | R2 | ) ( | R1 | | R2 | )
( -------- -------- ) ( -------- -------- )
( ) ( ) ( ) ( ) ( ) ( )
( ) ( ) ( ) ( ) ( ) ( )
(_______) ( ) (_______) (_______) ( ) (_______)
(________________________) (________________________)
]]></artwork> </artwork>
</figure></t> </figure>
</li>
<t>If encoding of entropy (<xref target="RFC6790"/> is desired, IP <li pn="section-2-2.2">If the encoding of entropy <xref target="RFC6790"
tunneling mechanisms that allow encoding of entropy, such as format="default" sectionFormat="of" derivedContent="RFC6790"/> is desired, IP-t
MPLS-in-UDP encapsulation <xref target="RFC7510"/> where the source unneling mechanisms that allow the
port of the UDP header is used as an entropy field, may be used to encoding of entropy, such as MPLS-over-UDP encapsulation <xref target="R
maximize the utilization of ECMP and/or LAG, especially when it is FC7510" format="default" sectionFormat="of" derivedContent="RFC7510"/> where the
difficult to make use of the entropy label mechanism. This is to be source port of the UDP
contrasted with <xref target="RFC4023" /> where MPLS-in-IP does not header is used as an entropy field, may be used to maximize the
provide for an entropy mechanism. Refer to <xref utilization of Equal-Cost Multipath (ECMP) and/or Link Aggregation
target="ENTROPY-LABEL"/>) for more discussion Groups (LAGs), especially when it is difficult to make use of the
about using entropy labels in SR-MPLS.</t> entropy-label mechanism. This is to be contrasted with <xref target="RFC
4023" format="default" sectionFormat="of" derivedContent="RFC4023"/> where MPLS-
<t>Tunneling MPLS over IP provides a technology that enables SR in over-IP does not provide
an IPv4 and/or IPv6 network where the routers do not support SRv6 for an entropy mechanism. Refer to <xref target="RFC8662" format="defaul
capabilities <xref target="IPV6-SEGMENT"/> t" sectionFormat="of" derivedContent="RFC8662"/>) for more discussion about usin
and where MPLS forwarding is not an option. This is shown in <xref g entropy labels in
target="transitionFig"/>. <figure anchor="transitionFig" SR-MPLS.</li>
title="SR-MPLS Enabled Within an IP Network"> <li pn="section-2-2.3">
<artwork><![CDATA[ <t pn="section-2-2.3.1">Tunneling MPLS over IP provides a technology t
hat enables Segment
__________________________________ Routing (SR) in an IPv4 and/or IPv6 network where the routers do not
__( IP Network )__ support SRv6 capabilities <xref target="I-D.ietf-6man-segment-routing-
__( )__ header" format="default" sectionFormat="of" derivedContent="IPv6-SRH"/> and
( -- -- -- ) where MPLS forwarding is not an option. This is shown in <xref target=
-------- -- -- |SR| -- |SR| -- |SR| -- -------- "transitionFig" format="default" sectionFormat="of" derivedContent="Figure 2"/>.
| Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress | </t>
| SR | | | | | | | | | | | | | | | | | | SR | <figure anchor="transitionFig" align="left" suppress-title="false" pn=
-------- -- -- | | -- | | -- | | -- -------- "figure-2">
(__ -- -- -- __) <name slugifiedName="name-sr-mpls-enabled-within-an-i">SR-MPLS Enabl
(__ __) ed within an IP Network</name>
(__________________________________) <artwork name="" type="" align="left" alt="" pn="section-2-2.3.2.1">
__________________________________
Key: __( IP Network )__
IR : IP-only Router __( )__
SR : SR-MPLS-capable Router ( -- -- -- )
== : SR-MPLS in UDP Tunnel -------- -- -- |SR| -- |SR| -- |SR| -- --------
| Ingress| |IR| |IR| | | |IR| | | |IR| | | |IR| | Egress|
]]></artwork> --&gt;| Router |===========| |======| |======| |======| Router|--&gt;
</figure></t> | SR | | | | | | | | | | | | | | | | | | SR |
-------- -- -- | | -- | | -- | | -- --------
(__ -- -- -- __)
(__ __)
(__________________________________)
</list></t> Key:
IR : IP-only Router
SR : SR-MPLS-capable Router
== : SR-MPLS-over-UDP Tunnel
</artwork>
</figure>
</li>
</ul>
</section> </section>
<section anchor="procs" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="procs" title="Procedures of SR-MPLS over IP"> ="section-3">
<t>This section describes the construction of forwarding information <name slugifiedName="name-procedures-of-sr-mpls-over-">Procedures of SR-MP
LS-over-IP</name>
<t pn="section-3-1">This section describes the construction of forwarding
information
base (FIB) entries and the forwarding behavior that allow the deployment base (FIB) entries and the forwarding behavior that allow the deployment
of SR-MPLS when some routers in the network are IP only (i.e., do not of SR-MPLS when some routers in the network are IP only (i.e., do not
support SR-MPLS). Note that the examples in <xref target="fibeg"/> and support SR-MPLS). Note that the examples in Sections <xref target="fibeg"
<xref target="fwd"/> assume that OSPF or ISIS is enabled: in fact, other format="counter" sectionFormat="of" derivedContent="3.1.1"/> and <xref target="f
mechanisms of discovery and advertisement could be used including other wd" format="counter" sectionFormat="of" derivedContent="3.2"/> assume that
routing protocols (such as BGP) or a central controller.</t> OSPF or IS-IS is enabled; in fact, other mechanisms of discovery and
advertisement could be used including other routing protocols (such as
<section anchor="fib" title="Forwarding Entry Construction"> BGP) or a central controller.</t>
<t>This sub-section describes the how to construct the forwarding <section anchor="fib" numbered="true" toc="include" removeInRFC="false" pn
="section-3.1">
<name slugifiedName="name-forwarding-entry-constructi">Forwarding Entry
Construction</name>
<t pn="section-3.1-1">This subsection describes how to construct the for
warding
information base (FIB) entry on an SR-MPLS-capable router when some or information base (FIB) entry on an SR-MPLS-capable router when some or
all of the next-hops along the shortest path towards a prefix Segment all of the next hops along the shortest path towards a prefix Segment
Identifier (prefix-SID) are IP-only routers. <xref target="fibeg" /> Identifier (Prefix-SID) are IP-only routers. <xref target="fibeg" format
="default" sectionFormat="of" derivedContent="Section 3.1.1"/>
provides a concrete example of how the process applies when using OSPF provides a concrete example of how the process applies when using OSPF
or ISIS.</t> or IS-IS.</t>
<t pn="section-3.1-2">Consider router A that receives a labeled packet w
<t>Consider router A that receives a labeled packet with top label ith top label
L(E) that corresponds to the prefix-SID SID(E) of prefix P(E) L(E) that corresponds to the Prefix-SID SID(E) of prefix P(E)
advertised by router E. Suppose the i-th next-hop router (termed NHi) advertised by router E. Suppose the i-th next-hop router (termed NHi)
along the shortest path from router A toward SID(E) is not SR-MPLS along the shortest path from router A toward SID(E) is not SR-MPLS
capable while both routers A and E are SR-MPLS capable. The following capable while both routers A and E are SR-MPLS capable. The following
processing steps apply:</t> processing steps apply:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.1-3">
<t> <li pn="section-3.1-3.1">Router E is SR-MPLS capable, so it advertises
<list style="symbols"> a Segment Routing
<t>Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB). The SRGB is defined in <xref target="RFC8402" f
Global Block (SRGB). The SRGB is defined in <xref target="RFC8402"/> ormat="default" sectionFormat="of" derivedContent="RFC8402"/>.
.
There are a number of ways that the advertisement can be achieved There are a number of ways that the advertisement can be achieved
including IGPs, BGP, configuration/management protocols. For including IGPs, BGP, and configuration/management protocols. For
example, see <xref target="DATACENTER-GATEWAY" />.</t> example, see <xref target="I-D.ietf-bess-datacenter-gateway" format=
"default" sectionFormat="of" derivedContent="DC-GATEWAY"/>.</li>
<t>When Router E advertises the prefix-SID SID(E) of prefix P(E) <li pn="section-3.1-3.2">When Router E advertises the Prefix-SID SID(E
it MUST also advertise the encapsulation endpoint and the tunnel ) of prefix P(E), it <bcp14>MUST</bcp14>
type of any tunnel used to reach E. This information is flooded also advertise the egress endpoint address and the encapsulation type of any
domain wide.</t> tunnel used to reach E. This information is flooded domain wide.
</li>
<t>If A and E are in different routing domains then the information <li pn="section-3.1-3.3">If A and E are in different routing domains,
MUST then the information <bcp14>MUST</bcp14>
be flooded into both domains. How this is achieved depends on the be flooded into both domains. How this is achieved depends on the
advertisement mechanism being used. The objective is that router A advertisement mechanism being used. The objective is that router A
knows the characteristics of router E that originated the knows the characteristics of router E that originated the
advertisement of SID(E).</t> advertisement of SID(E).</li>
<li pn="section-3.1-3.4">
<t>Router A programs the FIB entry for prefix P(E) corresponding <t pn="section-3.1-3.4.1">Router A programs the FIB entry for prefix
P(E) corresponding
to the SID(E) according to whether a pop or swap action is advertise d to the SID(E) according to whether a pop or swap action is advertise d
for the prefix. The resulting action may be: for the prefix. The resulting action may be:
<list style="symbols"> </t>
<t>pop the top label</t> <ul spacing="normal" bare="false" empty="false" pn="section-3.1-3.4.
<t>swap the top label to a value equal to SID(E) plus the 2">
lower bound of the SRGB of E</t> <li pn="section-3.1-3.4.2.1">pop the top label</li>
</list></t> <li pn="section-3.1-3.4.2.2">swap the top label to a value equal t
</list></t> o SID(E) plus the
lower bound of the SRGB of E</li>
<t>Once constructed, the FIB can be used by a router to tell it how to </ul>
</li>
</ul>
<t pn="section-3.1-4">Once constructed, the FIB can be used by a router
to tell it how to
process packets. It encapsulates the packets according to the process packets. It encapsulates the packets according to the
appropriate encapsulation advertised for the segment and then it sends appropriate encapsulation advertised for the segment and then sends
the packets towards the next hop NHi.</t> the packets towards the next hop NHi.</t>
<section anchor="fibeg" numbered="true" toc="include" removeInRFC="false
<section anchor="fibeg" title="FIB Construction Example"> " pn="section-3.1.1">
<t>This section is non-normative and provides a worked example of how <name slugifiedName="name-fib-construction-example">FIB Construction E
a FIB might be constructed using OSPF and ISIS extensions. It is based xample</name>
on the process described in <xref target="fib" />.</t> <t pn="section-3.1.1-1">This section is non-normative and provides a w
orked example of how
<t> a FIB might be constructed using OSPF and IS-IS extensions. It is base
<list style="symbols"> d
<t>Router E is SR-MPLS capable, so it advertises a Segment Routing on the process described in <xref target="fib" format="default" sectio
nFormat="of" derivedContent="Section 3.1"/>.</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.1.1-2">
<li pn="section-3.1.1-2.1">Router E is SR-MPLS capable, so it advert
ises a Segment Routing
Global Block (SRGB) using Global Block (SRGB) using
<xref target="OSPF-EXTENSIONS"/> or <xref target="RFC8665" format="default" sectionFormat="of" derived
<xref target="ISIS-EXTENSIONS"/>.</t> Content="RFC8665"/> or
<xref target="RFC8667" format="default" sectionFormat="of" derived
<t>When Router E advertises the prefix-SID SID(E) of prefix P(E) Content="RFC8667"/>.</li>
it also advertises the encapsulation endpoint and the tunnel <li pn="section-3.1.1-2.2">When Router E advertises the Prefix-SID S
ID(E) of prefix P(E),
it also advertises the encapsulation endpoint address and the tunn
el
type of any tunnel used to reach E using type of any tunnel used to reach E using
<xref target="ISIS-ENCAP"/> or <xref target="I-D.ietf-isis-encapsulation-cap" format="default" se
<xref target="OSPF-ROUTER"/>.</t> ctionFormat="of" derivedContent="ISIS-ENCAP"/> or
<xref target="I-D.ietf-ospf-encapsulation-cap" format="default" se
<t>If A and E are in different domains then the information is ctionFormat="of" derivedContent="OSPF-ENCAP"/>.</li>
<li pn="section-3.1.1-2.3">
<t pn="section-3.1.1-2.3.1">If A and E are in different domains, t
hen the information is
flooded into both domains and any intervening domains. flooded into both domains and any intervening domains.
<list style="symbols"> </t>
<t>The OSPF Tunnel Encapsulation TLV <ul spacing="normal" bare="false" empty="false" pn="section-3.1.1-
<xref target="OSPF-ROUTER"/> or the ISIS 2.3.2">
Tunnel Encapsulation sub-TLV <li pn="section-3.1.1-2.3.2.1">The OSPF Tunnel Encapsulations TL
<xref target="ISIS-ENCAP"/> is flooded V
domain-wide.</t> <xref target="I-D.ietf-ospf-encapsulation-cap" format="default
" sectionFormat="of" derivedContent="OSPF-ENCAP"/> or the IS-IS
<t>The OSPF SID/label range TLV Tunnel Encapsulation Type sub-TLV
<xref target="OSPF-EXTENSIONS"/> or <xref target="I-D.ietf-isis-encapsulation-cap" format="default
the ISIS SR-Capabilities Sub-TLV " sectionFormat="of" derivedContent="ISIS-ENCAP"/> is flooded
<xref target="ISIS-EXTENSIONS"/> is domain wide.</li>
advertised domain-wide so that router A knows the <li pn="section-3.1.1-2.3.2.2">The OSPF SID/Label Range TLV
characteristics of router E.</t> <xref target="RFC8665" format="default" sectionFormat="of" der
ivedContent="RFC8665"/> or
<t>When router E advertises the prefix P(E): the IS-IS SR-Capabilities sub-TLV
<list style="symbols"> <xref target="RFC8667" format="default" sectionFormat="of" der
<t>If router E is running ISIS it uses the extended ivedContent="RFC8667"/> is
advertised domain wide so that router A knows the
characteristics of router E.</li>
<li pn="section-3.1.1-2.3.2.3">
<t pn="section-3.1.1-2.3.2.3.1">When router E advertises the p
refix P(E):
</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.
1.1-2.3.2.3.2">
<li pn="section-3.1.1-2.3.2.3.2.1">If router E is running IS
-IS, it uses the extended
reachability TLV (TLVs 135, 235, 236, 237) and associates reachability TLV (TLVs 135, 235, 236, 237) and associates
the IPv4/IPv6 or IPv4/IPv6 source router ID sub-TLV(s) the IPv4/IPv6 or IPv4/IPv6 Source Router ID sub-TLV(s)
<xref target="RFC7794"/>.</t> <xref target="RFC7794" format="default" sectionFormat="of"
derivedContent="RFC7794"/>.</li>
<t>If router E is running OSPF it uses the OSPFv2 Extended <li pn="section-3.1.1-2.3.2.3.2.2">If router E is running OS
Prefix Opaque LSA <xref target="RFC7684"/> and sets the PF, it uses the OSPFv2 Extended
flooding scope to AS-wide.</t> Prefix Opaque Link-State Advertisement (LSA) <xref target=
</list></t> "RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> and set
s the
<t>If router E is running ISIS and advertises the ISIS flooding scope to Autonomous System (AS) wide.</li>
capability TLV (TLV 242) <xref target="RFC7981"/>, it sets the </ul>
"router-ID" field to a valid value or includes an IPV6 </li>
TE router-ID sub-TLV (TLV 12), or does both. The "S" bit <li pn="section-3.1.1-2.3.2.4">If router E is running IS-IS and
(flooding scope) of the ISIS capability TLV (TLV 242) is set advertises the IS-IS
to "1" .</t> Router CAPABILITY TLV (TLV 242) <xref target="RFC7981" format=
</list></t> "default" sectionFormat="of" derivedContent="RFC7981"/>, it sets the
"Router ID" field to a valid value or includes an IPv6
<t>Router A programs the FIB entry for prefix P(E) corresponding TE Router ID sub-TLV (TLV 12), or it does both. The "S" bit
(flooding scope) of the IS-IS Router CAPABILITY TLV (TLV 242)
is set
to "1".</li>
</ul>
</li>
<li pn="section-3.1.1-2.4">
<t pn="section-3.1.1-2.4.1">Router A programs the FIB entry for pr
efix P(E) corresponding
to the SID(E) according to whether a pop or swap action is adverti sed to the SID(E) according to whether a pop or swap action is adverti sed
for the prefix as follows: for the prefix as follows:
<list style="symbols"> </t>
<t>If the NP flag in OSPF or the P flag in ISIS is clear: <ul spacing="normal" bare="false" empty="false" pn="section-3.1.1-
<list style="empty"> 2.4.2">
<t>pop the top label</t> <li pn="section-3.1.1-2.4.2.1">
</list></t> <t pn="section-3.1.1-2.4.2.1.1">If the No-PHP (NP) Flag in OSP
F or the Persistent (P) Flag in IS-IS is clear:
<t>If the NP flag in OSPF or the P flag in ISIS is set: </t>
<list style="empty"> <ul empty="true" spacing="normal" bare="false" pn="section-3.1
<t>swap the top label to a value equal to SID(E) plus the .1-2.4.2.1.2">
lower bound of the SRGB of E</t> <li pn="section-3.1.1-2.4.2.1.2.1">pop the top label</li>
</list></t> </ul>
</li>
</list></t> <li pn="section-3.1.1-2.4.2.2">
<t pn="section-3.1.1-2.4.2.2.1">If the No-PHP (NP) Flag in OSP
</list></t> F or the Persistent (P) Flag in IS-IS is set:
</t>
<t>When forwarding the packet according to the constructed FIB entry t <ul empty="true" spacing="normal" bare="false" pn="section-3.1
he .1-2.4.2.2.2">
<li pn="section-3.1.1-2.4.2.2.2.1">swap the top label to a v
alue equal to SID(E) plus the
lower bound of the SRGB of E</li>
</ul>
</li>
</ul>
</li>
</ul>
<t pn="section-3.1.1-3">When forwarding the packet according to the co
nstructed FIB entry, the
router encapsulates the packet according to the encapsulation as adver tised router encapsulates the packet according to the encapsulation as adver tised
using the mechanisms described in <xref target="ISIS-ENCAP"/> using the mechanisms described in <xref target="I-D.ietf-isis-encapsul
or <xref target="OSPF-ROUTER"/>). It then sends the ation-cap" format="default" sectionFormat="of" derivedContent="ISIS-ENCAP"/>
or <xref target="I-D.ietf-ospf-encapsulation-cap" format="default" sec
tionFormat="of" derivedContent="OSPF-ENCAP"/>. It then sends the
packets towards the next hop NHi.</t> packets towards the next hop NHi.</t>
<t pn="section-3.1.1-4">Note that <xref target="RFC7510" format="defau
<t>Note that <xref target="RFC7510"/> specifies the use of port number lt" sectionFormat="of" derivedContent="RFC7510"/> specifies the use of port numb
6635 er 6635
to indicate that the payload of a UDP packet is MPLS, and port number 6636 for to indicate that the payload of a UDP packet is MPLS, and port number 6636 for
MPLS-in-UDP utilizing DTLS. However, <xref target="ISIS-ENCAP"/> MPLS-over-UDP utilizing DTLS. However, <xref target="I-D.ietf-isis-enc
and <xref target="OSPF-ROUTER"/> provide dynamic protocol apsulation-cap" format="default" sectionFormat="of" derivedContent="ISIS-ENCAP"/
mechanisms to configure the use any Dynamic Port for a tunnel that use >
s UDP and <xref target="I-D.ietf-ospf-encapsulation-cap" format="default" se
ctionFormat="of" derivedContent="OSPF-ENCAP"/> provide dynamic protocol
mechanisms to configure the use of any Dynamic Port for a tunnel that
uses UDP
encapsulation. Nothing in this document prevents the use of an IGP or any other encapsulation. Nothing in this document prevents the use of an IGP or any other
mechanism to negotiate the use of a Dynamic Port when UDP encapsulatio n is used mechanism to negotiate the use of a Dynamic Port when UDP encapsulatio n is used
for SR-MPLS, but if no such mechanism is used then the port numbers sp for SR-MPLS, but if no such mechanism is used, then the port numbers s
ecified in pecified in
<xref target="RFC7510"/> are used.</t> <xref target="RFC7510" format="default" sectionFormat="of" derivedCont
ent="RFC7510"/> are used.</t>
</section> </section>
</section> </section>
<section anchor="fwd" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="fwd" title="Packet Forwarding Procedures"> ="section-3.2">
<t><xref target="RFC7510"/> specifies an IP-based encapsulation for <name slugifiedName="name-packet-forwarding-procedure">Packet-Forwarding
MPLS, i.e., MPLS-in-UDP. This approach is applicable where IP-based Procedures</name>
<t pn="section-3.2-1"><xref target="RFC7510" format="default" sectionFor
mat="of" derivedContent="RFC7510"/> specifies an IP-based encapsulation for
MPLS, i.e., MPLS-over-UDP. This approach is applicable where IP-based
encapsulation for MPLS is required and further fine-grained load encapsulation for MPLS is required and further fine-grained load
balancing of MPLS packets over IP networks over Equal-Cost Multipath balancing of MPLS packets over IP networks over
(ECMP) and/or Link Aggregation Groups (LAGs) is also required. This ECMP and/or LAGs is also required. This
section provides details about the forwarding procedure when section provides details about the forwarding procedure when
UDP encapsulation is adopted for SR-MPLS over IP. Other encapsulation UDP encapsulation is adopted for SR-MPLS-over-IP. Other encapsulation
and tunnelling mechanisms can be applied using similar techniques, and tunneling mechanisms can be applied using similar techniques,
but for clarity this section uses UDP encapsulation as the exemplar.</t> but for clarity, this section uses UDP encapsulation as the exemplar.</t
>
<t>Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all <t pn="section-3.2-2">Nodes that are SR-MPLS capable can process SR-MPLS
packets. Not all
of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may
be "legacy routers" that cannot handle SR-MPLS packets but can forward be "legacy routers" that cannot handle SR-MPLS packets but can forward
IP packets. An SR-MPLS-capable node MAY advertise its capabilities IP packets. A node capable of SR-MPLS <bcp14>MAY</bcp14> advertise its c
using the IGP as described in <xref target="procs"/>. There are six apabilities
types of node in an SR-MPLS domain: <list style="symbols"> using the IGP as described in <xref target="procs" format="default" sect
<t>Domain ingress nodes that receive packets and encapsulate them ionFormat="of" derivedContent="Section 3"/>. There are six
types of nodes in an SR-MPLS domain: </t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.2-3">
<li pn="section-3.2-3.1">Domain ingress nodes that receive packets and
encapsulate them
for transmission across the domain. Those packets may be any for transmission across the domain. Those packets may be any
payload protocol including native IP packets or packets that are payload protocol including native IP packets or packets that are
already MPLS encapsulated.</t> already MPLS encapsulated.</li>
<li pn="section-3.2-3.2">Legacy transit nodes that are IP routers but
<t>Legacy transit nodes that are IP routers but that are not that are not
SR-MPLS capable (i.e., are not able to perform segment SR-MPLS capable (i.e., are not able to perform Segment
routing).</t> Routing).</li>
<li pn="section-3.2-3.3">Transit nodes that are SR-MPLS capable but th
<t>Transit nodes that are SR-MPLS capable but that are not at are not
identified by a SID in the SID stack.</t> identified by a SID in the SID stack.</li>
<li pn="section-3.2-3.4">Transit nodes that are SR-MPLS capable and ne
<t>Transit nodes that are SR-MPLS capable and need to perform ed to perform
SR-MPLS routing because they are identified by a SID in the SID SR-MPLS routing because they are identified by a SID in the SID
stack.</t> stack.</li>
<li pn="section-3.2-3.5">The penultimate node capable of SR-MPLS on th
<t>The penultimate SR-MPLS capable node on the path that processes e path that processes
the last SID on the stack on behalf of the domain egress node.</t> the last SID on the stack on behalf of the domain egress node.</li>
<li pn="section-3.2-3.6">The domain egress node that forwards the payl
<t>The domain egress node that forwards the payload packet for oad packet for
ultimate delivery.</t> ultimate delivery.</li>
</list></t> </ul>
<section anchor="phpfwd" numbered="true" toc="include" removeInRFC="fals
<section anchor="phpfwd" e" pn="section-3.2.1">
title="Packet Forwarding with Penultimate Hop Popping"> <name slugifiedName="name-packet-forwarding-with-penu">Packet Forwardi
<t>The description in this section assumes that the label associated ng with Penultimate Hop Popping</name>
with each prefix-SID is advertised by the owner of the prefix-SID as <t pn="section-3.2.1-1">The description in this section assumes that t
a Penultimate Hop Popping (PHP) label. That is, if one of the IGP he label associated
flooding mechanisms is used, the NP flag in OSPF or the P flag in with each Prefix-SID is advertised by the owner of the Prefix-SID as
ISIS associated with the prefix-SID is not set.</t> a Penultimate Hop-Popping (PHP) label. That is, if one of the IGP
flooding mechanisms is used, the NP-Flag in OSPF or the P-Flag in
<figure anchor="phpfwdeg" title="Packet Forwarding Example with PHP"> IS-IS associated with the Prefix-SID is not set.</t>
<artwork align="center"><![CDATA[ <figure anchor="phpfwdeg" align="left" suppress-title="false" pn="figu
re-3">
<name slugifiedName="name-packet-forwarding-example-w">Packet-Forwar
ding Example with PHP</name>
<artwork align="center" name="" type="" alt="" pn="section-3.2.1-2.1
">
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-------+ B +-------+ C +-------+ D +-------+ H | | A +-------+ B +-------+ C +-------+ D +-------+ H |
+-----+ +--+--+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+ +--+--+ +-----+
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +-------+ F +-------+ G | | E +-------+ F +-------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
+--------+ +--------+
|IP(A->E)| |IP(A-&gt;E)|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| UDP | |IP(E->G)| |IP(G-&gt;H)| | UDP | |IP(E->G)| |IP(G-&gt;H)|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(G) | | UDP | | UDP | | L(G) | | UDP | | UDP |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(H) | | L(H) | |Exp Null| | L(H) | | L(H) | |Exp Null|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Packet | ---> | Packet | ---&gt; | Packet | | Packet | ---> | Packet | ---&gt; | Packet |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-3.2.1-3">In the example shown in <xref target="phpfwdeg
<t>In the example shown in <xref target="phpfwdeg"/>, assume that " format="default" sectionFormat="of" derivedContent="Figure 3"/>, assume that
routers A, E, G and H are SR-MPLS-capable while the remaining routers A, E, G, and H are capable of SR-MPLS while the remaining
routers (B, C, D and F) are only capable of forwarding IP packets. routers (B, C, D, and F) are only capable of forwarding IP packets.
Routers A, E, G, and H advertise their Segment Routing related Routers A, E, G, and H advertise their Segment Routing related
information, such as via IS-IS or OSPF.</t> information, such as via IS-IS or OSPF.</t>
<t pn="section-3.2.1-4">Now assume that router A (the Domain ingress)
<t>Now assume that router A (the Domain ingress) wants to send a wants to send a
packet to router H (the Domain egress) via the explicit path packet to router H (the Domain egress) via the explicit path
{E-&gt;G-&gt;H}. Router A will impose an MPLS label stack on the {E-&gt;G-&gt;H}. Router A will impose an MPLS label stack on the
packet that corresponds to that explicit path. Since the next hop packet that corresponds to that explicit path. Since the next hop
toward router E is only IP-capable (B is a legacy transit node), toward router E is only IP capable (B is a legacy transit node),
router A replaces the top label (that indicated router E) with a router A replaces the top label (that indicated router E) with a
UDP-based tunnel for MPLS (i.e., MPLS-over-UDP <xref UDP-based tunnel for MPLS (i.e., MPLS-over-UDP <xref target="RFC7510"
target="RFC7510"/>) to router E and then sends the packet. In other format="default" sectionFormat="of" derivedContent="RFC7510"/>) to router E and
then sends the packet. In other
words, router A pops the top label and then encapsulates the MPLS words, router A pops the top label and then encapsulates the MPLS
packet in a UDP tunnel to router E.</t> packet in a UDP tunnel to router E.</t>
<t pn="section-3.2.1-5">When the IP-encapsulated MPLS packet arrives a
<t>When the IP-encapsulated MPLS packet arrives at router E (which t router E (which
is an SR-MPLS-capable transit node), router E strips the IP-based is a transit node capable of SR-MPLS), router E strips the IP-based
tunnel header and then processes the decapsulated MPLS packet. The top tunnel header and then processes the decapsulated MPLS packet. The top
label indicates that the packet must be forwarded toward router G. label indicates that the packet must be forwarded toward router G.
Since the next hop toward router G is only IP-capable, router E Since the next hop toward router G is only IP capable, router E
replaces the current top label with an MPLS-over-UDP tunnel toward replaces the current top label with an MPLS-over-UDP tunnel toward
router G and sends it out. That is, router E pops the top label and router G and sends it out. That is, router E pops the top label and
then encapsulates the MPLS packet in a UDP tunnel to router G.</t> then encapsulates the MPLS packet in a UDP tunnel to router G.</t>
<t pn="section-3.2.1-6">When the packet arrives at router G, router G
<t>When the packet arrives at router G, router G will strip the will strip the
IP-based tunnel header and then process the decapsulated MPLS IP-based tunnel header and then process the decapsulated MPLS
packet. The top label indicates that the packet must be forwarded packet. The top label indicates that the packet must be forwarded
toward router H. Since the next hop toward router H is only toward router H. Since the next hop toward router H is only
IP-capable (D is a legacy transit router), router G would replace IP capable (D is a legacy transit router), router G would replace
the current top label with an MPLS-over-UDP tunnel toward router H the current top label with an MPLS-over-UDP tunnel toward router H
and send it out. However, since router G reaches the bottom of the and send it out. However, since router G reaches the bottom of the
label stack (G is the penultimate SR-MPLS capable node on the path) label stack (G is the penultimate node capable of SR-MPLS on the path) ,
this would leave the original packet that router A wanted to send to this would leave the original packet that router A wanted to send to
router H encapsulated in UDP as if it was MPLS (i.e., with a UDP router H encapsulated in UDP as if it was MPLS (i.e., with a UDP
header and destination port indicating MPLS) even though the header and destination port indicating MPLS) even though the
original packet could have been any protocol. That is, the final original packet could have been any protocol. That is, the final
SR-MPLS has been popped exposing the payload packet.</t> SR-MPLS has been popped exposing the payload packet.</t>
<t pn="section-3.2.1-7">To handle this, when a router (here it is rout
<t>To handle this, when a router (here it is router G) pops the er G) pops the
final SR-MPLS label, it inserts an explicit null label <xref final SR-MPLS label, it inserts an explicit NULL label <xref target="R
target="RFC3032"/> before encapsulating the packet in an FC3032" format="default" sectionFormat="of" derivedContent="RFC3032"/> before en
capsulating the packet in an
MPLS-over-UDP tunnel toward router H and sending it out. That is, MPLS-over-UDP tunnel toward router H and sending it out. That is,
router G pops the top label, discovers it has reached the bottom of router G pops the top label, discovers it has reached the bottom of
stack, pushes an explicit null label, and then encapsulates the MPLS stack, pushes an explicit NULL label, and then encapsulates the MPLS
packet in a UDP tunnel to router H.</t> packet in a UDP tunnel to router H.</t>
</section> </section>
<section anchor="nophpfwd" numbered="true" toc="include" removeInRFC="fa
<section anchor="nophpfwd" lse" pn="section-3.2.2">
title="Packet Forwarding without Penultimate Hop Popping"> <name slugifiedName="name-packet-forwarding-without-p">Packet Forwardi
<t><xref target="nophpfwdeg"/> demonstrates the packet walk in the ng without Penultimate Hop Popping</name>
case where the label associated with each prefix-SID advertised by <t pn="section-3.2.2-1"><xref target="nophpfwdeg" format="default" sec
the owner of the prefix-SID is not a Penultimate Hop Popping (PHP) tionFormat="of" derivedContent="Figure 4"/> demonstrates the packet walk in the
label (e.g., the the NP flag in OSPF or the P flag in ISIS case where the label associated with each Prefix-SID advertised by
associated with the prefix-SID is set). Apart from the PHP function the owner of the Prefix-SID is not a Penultimate Hop-Popping (PHP)
the roles of the routers is unchanged from <xref label (e.g., the NP-Flag in OSPF or the P-Flag in IS-IS
target="phpfwd"/>.</t> associated with the Prefix-SID is set). Apart from the PHP function,
the roles of the routers are unchanged from <xref target="phpfwd" form
<figure anchor="nophpfwdeg" at="default" sectionFormat="of" derivedContent="Section 3.2.1"/>.</t>
title="Packet Forwarding Example without PHP"> <figure anchor="nophpfwdeg" align="left" suppress-title="false" pn="fi
<artwork align="center"><![CDATA[ gure-4">
<name slugifiedName="name-packet-forwarding-example-wi">Packet-Forwa
rding Example without PHP</name>
<artwork align="center" name="" type="" alt="" pn="section-3.2.2-2.1
">
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-------+ B +-------+ C +--------+ D +--------+ H | | A +-------+ B +-------+ C +--------+ D +--------+ H |
+-----+ +--+--+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+ +--+--+ +-----+
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +-------+ F +--------+ G | | E +-------+ F +--------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
+--------+ +--------+
|IP(A->E)| |IP(A-&gt;E)|
+--------+ +--------+ +--------+ +--------+
| UDP | |IP(E->G)| | UDP | |IP(E-&gt;G)|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(E) | | UDP | |IP(G->H)| | L(E) | | UDP | |IP(G-&gt;H)|
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(G) | | L(G) | | UDP | | L(G) | | L(G) | | UDP |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| L(H) | | L(H) | | L(H) | | L(H) | | L(H) | | L(H) |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Packet | ---> | Packet | ---&gt; | Packet | | Packet | ---> | Packet | ---&gt; | Packet |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
]]></artwork> </artwork>
</figure> </figure>
<t pn="section-3.2.2-3">As can be seen from the figure, the SR-MPLS la
<t>As can be seen from the figure, the SR-MPLS label for each bel for each
segment is left in place until the end of the segment where it is segment is left in place until the end of the segment where it is
popped and the next instruction is processed.</t> popped and the next instruction is processed.</t>
</section> </section>
<section anchor="addnlfwd" numbered="true" toc="include" removeInRFC="fa
<section anchor="addnlfwd" title="Additional Forwarding Procedures"> lse" pn="section-3.2.3">
<t><list style="hanging"> <name slugifiedName="name-additional-forwarding-proce">Additional Forw
<t hangText="Non-MPLS Interfaces:">Although the description in arding Procedures</name>
the previous two sections is based on the use of prefix-SIDs, <dl newline="false" spacing="normal" pn="section-3.2.3-1">
<dt pn="section-3.2.3-1.1">Non-MPLS Interfaces:</dt>
<dd pn="section-3.2.3-1.2">Although the description in
the previous two sections is based on the use of Prefix-SIDs,
tunneling SR-MPLS packets is useful when the top label of a tunneling SR-MPLS packets is useful when the top label of a
received SR-MPLS packet indicates an adjacency-SID and the received SR-MPLS packet indicates an Adjacency SID and the
corresponding adjacent node to that adjacency-SID is not capable corresponding adjacent node to that Adjacency SID is not capable
of MPLS forwarding but can still process SR-MPLS packets. In of MPLS forwarding but can still process SR-MPLS packets. In
this scenario the top label would be replaced by an IP tunnel this scenario, the top label would be replaced by an IP tunnel
toward that adjacent node and then forwarded over the toward that adjacent node and then forwarded over the
corresponding link indicated by the adjacency-SID.</t> corresponding link indicated by the Adjacency SID.</dd>
<dt pn="section-3.2.3-1.3">When to Use IP-Based Tunnels:</dt>
<t hangText="When to use IP-based Tunnels:">The description in <dd pn="section-3.2.3-1.4">The description in
the previous two sections is based on the assumption that the previous two sections is based on the assumption that
MPLS-over-UDP tunnel is used when the nexthop towards the next an MPLS-over-UDP tunnel is used when the next hop towards the next
segment is not MPLS-enabled. However, even in the case where the segment is not MPLS enabled. However, even in the case where the
nexthop towards the next segment is MPLS-capable, an next hop towards the next segment is MPLS capable, an
MPLS-over-UDP tunnel towards the next segment could still be MPLS-over-UDP tunnel towards the next segment could still be
used instead due to local policies. For instance, in the example used instead due to local policies. For instance, in the example
as described in <xref target="nophpfwdeg"/>, assume F is now an as described in <xref target="nophpfwdeg" format="default" section
SR-MPLS-capable transit node while all the other assumptions Format="of" derivedContent="Figure 4"/>, assume F is now a
remain unchanged: since F is not identified by a SID in the stack transit node capable of SR-MPLS while all the other assumptions
remain unchanged; since F is not identified by a SID in the stack
and an MPLS-over-UDP tunnel is preferred to an MPLS LSP and an MPLS-over-UDP tunnel is preferred to an MPLS LSP
according to local policies, router E replaces the current according to local policies, router E replaces the current
top label with an MPLS-over-UDP tunnel toward router G and send top label with an MPLS-over-UDP tunnel toward router G and sends
it out. (Note that if an MPLS LSP was preferred, the packet it out. (Note that if an MPLS LSP was preferred, the packet
would be forwarded as native SR-MPLS.)</t> would be forwarded as native SR-MPLS.)</dd>
<dt pn="section-3.2.3-1.5">IP Header Fields:</dt>
<t hangText="IP Header Fields:">When encapsulating an MPLS <dd pn="section-3.2.3-1.6">When encapsulating an MPLS
packet in UDP, the resulting packet is further encapsulated in packet in UDP, the resulting packet is further encapsulated in
IP for transmission. IPv4 or IPv6 may be used according to the IP for transmission. IPv4 or IPv6 may be used according to the
capabilities of the network. The address fields are set as capabilities of the network. The address fields are set as
described in <xref target="usecases"/>. The other IP header described in <xref target="usecases" format="default" sectionForma
fields (such as the ECN field <xref target="RFC6040"/>, the DSCP t="of" derivedContent="Section 2"/>. The other IP header
code point <xref target="RFC2983"/>, or IPv6 Flow Label) on each fields (such as the ECN field <xref target="RFC6040" format="defau
UDP-encapsulated segment SHOULD be configurable according to the lt" sectionFormat="of" derivedContent="RFC6040"/>, the
operator&apos;s policy: they may be copied from the header of the Differentiated Services Code Point (DSCP) <xref target="RFC2983" f
incoming packet; they may be promoted from the header of the ormat="default" sectionFormat="of" derivedContent="RFC2983"/>, or IPv6 Flow Labe
payload packet; they may be set according to instructions l) on each UDP-encapsulated
programmed to be associated with the SID; or they may be segment <bcp14>SHOULD</bcp14> be configurable according to the ope
configured dependent on the outgoing interface and payload. The rator's
TTL field setting in the encapsulating packet header is handled policy; they may be copied from the header of the incoming
as described in [RFC7510] which refers to [RFC4023].</t> packet; they may be promoted from the header of the payload
packet; they may be set according to instructions programmed to
<t hangText="Entropy and ECMP:">When encapsulating an MPLS be associated with the SID; or they may be configured dependent
on the outgoing interface and payload. The TTL field setting in
the encapsulating packet header is handled as described in
<xref target="RFC7510" format="default" sectionFormat="of" derived
Content="RFC7510"/>, which refers to <xref target="RFC4023" format="default" sec
tionFormat="of" derivedContent="RFC4023"/>.</dd>
<dt pn="section-3.2.3-1.7">Entropy and ECMP:</dt>
<dd pn="section-3.2.3-1.8">When encapsulating an MPLS
packet with an IP tunnel header that is capable of encoding packet with an IP tunnel header that is capable of encoding
entropy (such as <xref target="RFC7510"/>), the corresponding entropy (such as <xref target="RFC7510" format="default" sectionFo
entropy field (the source port in the case of a UDP tunnel) MAY rmat="of" derivedContent="RFC7510"/>), the corresponding
entropy field (the source port in the case of a UDP tunnel) <bcp14
>MAY</bcp14>
be filled with an entropy value that is generated by the be filled with an entropy value that is generated by the
encapsulator to uniquely identify a flow. However, what encapsulator to uniquely identify a flow. However, what
constitutes a flow is locally determined by the encapsulator. For constitutes a flow is locally determined by the encapsulator. For
instance, if the MPLS label stack contains at least one entropy instance, if the MPLS label stack contains at least one entropy
label and the encapsulator is capable of reading that entropy label and the encapsulator is capable of reading that entropy
label, the entropy label value could be directly copied to the label, the entropy label value could be directly copied to the
source port of the UDP header. Otherwise, the encapsulator may source port of the UDP header. Otherwise, the encapsulator may
have to perform a hash on the whole label stack or the five-tuple have to perform a hash on the whole label stack or the five-tuple
of the SR-MPLS payload if the payload is determined as an IP packe t. of the SR-MPLS payload if the payload is determined as an IP packe t.
To avoid re-performing the hash or hunting for the entropy label To avoid recalculating the hash or hunting for the entropy label
each time the packet is encapsulated in a UDP tunnel it MAY be each time the packet is encapsulated in a UDP tunnel, it <bcp14>MA
Y</bcp14> be
desirable that the entropy value contained in the incoming desirable that the entropy value contained in the incoming
packet (i.e., the UDP source port value) is retained when packet (i.e., the UDP source port value) is retained when
stripping the UDP header and is re-used as the entropy value of stripping the UDP header and is reused as the entropy value of
the outgoing packet.</t> the outgoing packet.</dd>
<dt pn="section-3.2.3-1.9">Congestion Considerations:</dt>
<t hangText="Congestion Considerations:">Section 5 of <dd pn="section-3.2.3-1.10">
<xref target="RFC7510" /> provides a detailed analysis of the <xref target="RFC7510" sectionFormat="of" section="5" format="defa
ult" derivedLink="https://rfc-editor.org/rfc/rfc7510#section-5" derivedContent="
RFC7510"/> provides a detailed analysis of the
implications of congestion in MPLS-over-UDP systems and builds implications of congestion in MPLS-over-UDP systems and builds
on section 3.1.3 of <xref target="RFC8085" /> that describes on <xref target="RFC8085" sectionFormat="of" section="3.1.3" forma t="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.1.3" deriv edContent="RFC8085"/>, which describes
the congestion implications of UDP tunnels. All of those the congestion implications of UDP tunnels. All of those
considerations apply to SR-MPLS-over-UDP tunnels as described considerations apply to SR-MPLS-over-UDP tunnels as described
in this document. In particular, it should be noted that the in this document. In particular, it should be noted that the
traffic carried in SR-MPLS flows is likely to be IP traffic.</t> traffic carried in SR-MPLS flows is likely to be IP traffic.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-4">
<t>This document makes no requests for IANA action.</t> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t pn="section-4-1">This document has no IANA actions.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
<section anchor="Security" title="Security Considerations"> pn="section-5">
<t>The security consideration of <xref target="RFC8354"/> (which redirects <name slugifiedName="name-security-considerations">Security Considerations
the reader to <xref target="RFC5095" />) and <xref target="RFC7510"/> </name>
apply. DTLS <xref target="RFC6347"/> SHOULD be used where security is <t pn="section-5-1">The security consideration of <xref target="RFC8354" f
needed on an MPLS-SR-over-UDP segment including when the IP segment crosse ormat="default" sectionFormat="of" derivedContent="RFC8354"/> (which redirects
s the reader to <xref target="RFC5095" format="default" sectionFormat="of" d
the public Internet or some other untrusted environment. <xref target="RFC erivedContent="RFC5095"/>) and <xref target="RFC7510" format="default" sectionFo
8402" /> rmat="of" derivedContent="RFC7510"/>
provides security considerations for Segment Routing, and Section 8.1 of t apply. DTLS <xref target="RFC6347" format="default" sectionFormat="of" der
hat ivedContent="RFC6347"/> <bcp14>SHOULD</bcp14> be used where security is
document is particularly applicable to SR-MPLS.</t> needed on an SR-MPLS-over-UDP segment including when the IP segment crosse
s
<t>It is difficult for an attacker to pass a raw MPLS encoded packet the public Internet or some other untrusted environment. <xref target="RFC
into a network and operators have considerable experience at excluding 8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>
such packets at the network boundaries, for example by excluding all provides security considerations for Segment Routing, and <xref target="RF
C8402" sectionFormat="of" section="8.1" format="default" derivedLink="https://rf
c-editor.org/rfc/rfc8402#section-8.1" derivedContent="RFC8402"/> is particularly
applicable to SR-MPLS.</t>
<t pn="section-5-2">It is difficult for an attacker to pass a raw MPLS-enc
oded packet
into a network, and operators have considerable experience in excluding
such packets at the network boundaries, for example, by excluding all
packets that are revealed to be carrying an MPLS packet as the payload packets that are revealed to be carrying an MPLS packet as the payload
of IP tunnels. Further discussion of MPLS security is found in of IP tunnels. Further discussion of MPLS security is found in
<xref target="RFC5920" />.</t> <xref target="RFC5920" format="default" sectionFormat="of" derivedContent=
"RFC5920"/>.</t>
<t>It is easy for a network ingress node to detect any attempt to smuggle <t pn="section-5-3">It is easy for a network ingress node to detect any at
an IP tempt to smuggle an IP
packet into the network since it would see that the UDP destination port packet into the network since it would see that the UDP destination port
was set to MPLS, and such filtering SHOULD be applied. If, however, the was set to MPLS, and such filtering <bcp14>SHOULD</bcp14> be applied. If,
mechanisms described in <xref target="OSPF-EXTENSIONS"/> however, the
or <xref target="ISIS-EXTENSIONS"/> are applied, mechanisms described in <xref target="RFC8665" format="default" sectionFor
mat="of" derivedContent="RFC8665"/>
or <xref target="RFC8667" format="default" sectionFormat="of" derivedConte
nt="RFC8667"/> are applied,
a wider variety of UDP port numbers might be in use making port filtering a wider variety of UDP port numbers might be in use making port filtering
harder.</t> harder.</t>
<t pn="section-5-4">SR packets not having a destination address terminatin
<t>SR packets not having a destination address terminating in the network g in the network
would be transparently carried and would pose no different security risk t o would be transparently carried and would pose no different security risk t o
the network under consideration than any other traffic.</t> the network under consideration than any other traffic.</t>
<t pn="section-5-5">Where control-plane techniques are used (as described
<t>Where control plane techniques are used (as described in <xref in <xref target="procs" format="default" sectionFormat="of" derivedContent="Sect
target="procs"/>), it is important that these protocols are adequately ion 3"/>), it is important that these protocols are adequately
secured for the environment in which they are run as discussed in secured for the environment in which they are run as discussed in
<xref target="RFC6862" /> and <xref target="RFC5920" />.</t> <xref target="RFC6862" format="default" sectionFormat="of" derivedContent= "RFC6862"/> and <xref target="RFC5920" format="default" sectionFormat="of" deriv edContent="RFC5920"/>.</t>
</section> </section>
</middle>
<section title="Contributors"> <back>
<figure> <displayreference target="I-D.ietf-bess-datacenter-gateway" to="DC-GATEWAY"/
<artwork><![CDATA[Ahmed Bashandy >
<displayreference target="I-D.ietf-ospf-encapsulation-cap" to="OSPF-ENCAP"/>
<displayreference target="I-D.ietf-isis-encapsulation-cap" to="ISIS-ENCAP"/>
<displayreference target="I-D.ietf-6man-segment-routing-header" to="IPv6-SRH
"/>
<references pn="section-6">
<name slugifiedName="name-references">References</name>
<references pn="section-6.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3
031" quoteTitle="true" derivedAnchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Viswanathan" fullname="A. Viswanathan
">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="January"/>
<abstract>
<t>This document specifies the architecture for Multiprotocol Labe
l Switching (MPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<seriesInfo name="DOI" value="10.17487/RFC3031"/>
</reference>
<reference anchor="RFC3032" target="https://www.rfc-editor.org/info/rfc3
032" quoteTitle="true" derivedAnchor="RFC3032">
<front>
<title>MPLS Label Stack Encoding</title>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Tappan" fullname="D. Tappan">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fedorkow" fullname="G. Fedorkow">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Farinacci" fullname="D. Farinacci">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Conta" fullname="A. Conta">
<organization showOnFrontPage="true"/>
</author>
<date year="2001" month="January"/>
<abstract>
<t>This document specifies the encoding to be used by an LSR in or
der to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on
LAN data links, and possibly on other data links as well. This document also sp
ecifies rules and procedures for processing the various fields of the label stac
k encoding. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3032"/>
<seriesInfo name="DOI" value="10.17487/RFC3032"/>
</reference>
<reference anchor="RFC4023" target="https://www.rfc-editor.org/info/rfc4
023" quoteTitle="true" derivedAnchor="RFC4023">
<front>
<title>Encapsulating MPLS in IP or Generic Routing Encapsulation (GR
E)</title>
<author initials="T." surname="Worster" fullname="T. Worster">
<organization showOnFrontPage="true"/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rosen" fullname="E. Rosen" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="March"/>
<abstract>
<t>Various applications of MPLS make use of label stacks with mult
iple entries. In some cases, it is possible to replace the top label of the sta
ck with an IP-based encapsulation, thereby enabling the application to run over
networks that do not have MPLS enabled in their core routers. This document spe
cifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing
Encapsulation). Each of these is applicable in some circumstances. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4023"/>
<seriesInfo name="DOI" value="10.17487/RFC4023"/>
</reference>
<reference anchor="RFC5095" target="https://www.rfc-editor.org/info/rfc5
095" quoteTitle="true" derivedAnchor="RFC5095">
<front>
<title>Deprecation of Type 0 Routing Headers in IPv6</title>
<author initials="J." surname="Abley" fullname="J. Abley">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Savola" fullname="P. Savola">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Neville-Neil" fullname="G. Neville-Ne
il">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="December"/>
<abstract>
<t>The functionality provided by IPv6's Type 0 Routing Header can
be exploited in order to achieve traffic amplification over a remote path for th
e purposes of generating denial-of-service traffic. This document updates the I
Pv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light
of this security concern. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5095"/>
<seriesInfo name="DOI" value="10.17487/RFC5095"/>
</reference>
<reference anchor="RFC6040" target="https://www.rfc-editor.org/info/rfc6
040" quoteTitle="true" derivedAnchor="RFC6040">
<front>
<title>Tunnelling of Explicit Congestion Notification</title>
<author initials="B." surname="Briscoe" fullname="B. Briscoe">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="November"/>
<abstract>
<t>This document redefines how the explicit congestion notificatio
n (ECN) field of the IP header should be constructed on entry to and exit from a
ny IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP
tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulat
ion, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously
unused combinations of inner and outer headers. The new rules ensure the ECN fi
eld is correctly propagated across a tunnel whether it is used to signal one or
two severity levels of congestion; whereas before, only one severity level was s
upported. Tunnel endpoints can be updated in any order without affecting pre-ex
isting uses of the ECN field, thus ensuring backward compatibility. Nonetheless
, operators wanting to support two severity levels (e.g., for pre-congestion not
ification -- PCN) can require compliance with this new specification. A thoroug
h analysis of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need, RFC 4774
gives guidance on designing alternate ECN semantics, and this document extends t
hat to include tunnelling issues. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6040"/>
<seriesInfo name="DOI" value="10.17487/RFC6040"/>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
347" quoteTitle="true" derivedAnchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="January"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
y for datagram protocols. The protocol allows client/server applications to com
municate in a way that is designed to prevent eavesdropping, tampering, or messa
ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
otocol and provides equivalent security guarantees. Datagram semantics of the u
nderlying transport are preserved by the DTLS protocol. This document updates D
TLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC7510" target="https://www.rfc-editor.org/info/rfc7
510" quoteTitle="true" derivedAnchor="RFC7510">
<front>
<title>Encapsulating MPLS in UDP</title>
<author initials="X." surname="Xu" fullname="X. Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Sheth" fullname="N. Sheth">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Yong" fullname="L. Yong">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Callon" fullname="R. Callon">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="April"/>
<abstract>
<t>This document specifies an IP-based encapsulation for MPLS, cal
led MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation
is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost M
ultipath) or link aggregation. The MPLS- in-UDP encapsulation technology must o
nly be deployed within a single network (with a single network operator) or netw
orks of an adjacent set of cooperating network operators where traffic is manage
d to avoid congestion, rather than over the Internet where congestion control is
required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is no
t congestion controlled and to UDP zero checksum usage with IPv6.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7510"/>
<seriesInfo name="DOI" value="10.17487/RFC7510"/>
</reference>
<reference anchor="RFC7684" target="https://www.rfc-editor.org/info/rfc7
684" quoteTitle="true" derivedAnchor="RFC7684">
<front>
<title>OSPFv2 Prefix/Link Attribute Advertisement</title>
<author initials="P." surname="Psenak" fullname="P. Psenak">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Gredler" fullname="H. Gredler">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Henderickx" fullname="W. Henderickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Tantsura" fullname="J. Tantsura">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="November"/>
<abstract>
<t>OSPFv2 requires functional extension beyond what can readily be
done with the fixed-format Link State Advertisements (LSAs) as described in RFC
2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV
) tuples that can be used to associate additional attributes with prefixes or li
nks. Depending on the application, these prefixes and links may or may not be a
dvertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and ful
ly backward compatible.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7684"/>
<seriesInfo name="DOI" value="10.17487/RFC7684"/>
</reference>
<reference anchor="RFC7794" target="https://www.rfc-editor.org/info/rfc7
794" quoteTitle="true" derivedAnchor="RFC7794">
<front>
<title>IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachabili
ty</title>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Xu" fullname="X. Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="U." surname="Chunduri" fullname="U. Chunduri">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t>This document introduces new sub-TLVs to support advertisement
of IPv4 and IPv6 prefix attribute flags and the source router ID of the router t
hat originated a prefix advertisement.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7794"/>
<seriesInfo name="DOI" value="10.17487/RFC7794"/>
</reference>
<reference anchor="RFC7981" target="https://www.rfc-editor.org/info/rfc7
981" quoteTitle="true" derivedAnchor="RFC7981">
<front>
<title>IS-IS Extensions for Advertising Router Information</title>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Chen" fullname="M. Chen">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="October"/>
<abstract>
<t>This document defines a new optional Intermediate System to Int
ermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, whic
h allows a router to announce its capabilities within an IS-IS level or the enti
re routing domain. This document obsoletes RFC 4971.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7981"/>
<seriesInfo name="DOI" value="10.17487/RFC7981"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
402" quoteTitle="true" derivedAnchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A
node steers a packet through an ordered list of instructions, called "segments".
A segment can represent any instruction, topological or service based. A segm
ent can have a semantic local to an SR node or global within an SR domain. SR p
rovides a mechanism that allows a flow to be restricted to a specific topologica
l path, while maintaining per-flow state only at the ingress node(s) to the SR d
omain.</t>
<t>SR can be directly applied to the MPLS architecture with no cha
nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered
list of segments is encoded as a stack of labels. The segment to process is on
the top of the stack. Upon completion of a segment, the related label is poppe
d from the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of
routing header. A segment is encoded as an IPv6 address. An ordered list of se
gments is encoded as an ordered list of IPv6 addresses in the routing header. T
he active segment is indicated by the Destination Address (DA) of the packet. T
he next active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8
660" quoteTitle="true" derivedAnchor="RFC8660">
<front>
<title>Segment Routing with the MPLS Data Plane</title>
<seriesInfo name="RFC" value="8660"/>
<seriesInfo name="DOI" value="10.17487/RFC8660"/>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
i">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
</references>
<references pn="section-6.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.ietf-bess-datacenter-gateway" quoteTitle="true" t
arget="https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-04" derive
dAnchor="DC-GATEWAY">
<front>
<title>Gateway Auto-Discovery and Route Advertisement for Segment Ro
uting Enabled Domain Interconnection</title>
<author initials="A" surname="Farrel" fullname="Adrian Farrel">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Drake" fullname="John Drake">
<organization showOnFrontPage="true"/>
</author>
<author initials="E" surname="Rosen" fullname="Eric Rosen">
<organization showOnFrontPage="true"/>
</author>
<author initials="K" surname="Patel" fullname="Keyur Patel">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Jalil" fullname="Luay Jalil">
<organization showOnFrontPage="true"/>
</author>
<date month="August" day="21" year="2019"/>
<abstract>
<t>Data centers are critical components of the infrastructure used
by network operators to provide services to their customers. Data centers are
attached to the Internet or a backbone network by gateway routers. One data cen
ter typically has more than one gateway for commercial, load balancing, and resi
liency reasons. Segment Routing is a popular protocol mechanism for use within
a data center, but also for steering traffic that flows between two data center
sites. In order that one data center site may load balance the traffic it sends
to another data center site, it needs to know the complete set of gateway route
rs at the remote data center, the points of connection from those gateways to th
e backbone network, and the connectivity across the backbone network. Segment R
outing may also be operated in other domains, such as access networks. Those do
mains also need to be connected across backbone networks through gateways. This
document defines a mechanism using the BGP Tunnel Encapsulation attribute to al
low each gateway router to advertise the routes to the prefixes in the Segment R
outing domains to which it provides access, and also to advertise on behalf of e
ach other gateway to the same Segment Routing domain.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-datacenter-ga
teway-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-bess-datacenter-gateway-04.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-6man-segment-routing-header" quoteTitle="tru
e" target="https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26
" derivedAnchor="IPv6-SRH">
<front>
<title>IPv6 Segment Routing Header (SRH)</title>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Dukes" fullname="Darren Dukes">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Leddy" fullname="John Leddy">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Matsushima" fullname="Satoru Matsushim
a">
<organization showOnFrontPage="true"/>
</author>
<author initials="D" surname="Voyer" fullname="Daniel Voyer">
<organization showOnFrontPage="true"/>
</author>
<date month="October" day="22" year="2019"/>
<abstract>
<t>Segment Routing can be applied to the IPv6 data plane using a n
ew type of Routing Extension Header called the Segment Routing Header. This docu
ment describes the Segment Routing Header and how it is used by Segment Routing
capable nodes.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-6man-segment-routi
ng-header-26"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-6man-segment-routing-header-26.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-isis-encapsulation-cap" quoteTitle="true" ta
rget="https://tools.ietf.org/html/draft-ietf-isis-encapsulation-cap-01" derivedA
nchor="ISIS-ENCAP">
<front>
<title>Advertising Tunnelling Capability in IS-IS</title>
<author initials="X" surname="Xu" fullname="Xiaohu Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Raszuk" fullname="Robert Raszuk">
<organization showOnFrontPage="true"/>
</author>
<author initials="U" surname="Chunduri" fullname="Uma Chunduri">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Contreras" fullname="Luis Contreras">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Jalil" fullname="Luay Jalil">
<organization showOnFrontPage="true"/>
</author>
<date month="April" day="24" year="2017"/>
<abstract>
<t>Some networks use tunnels for a variety of reasons. A large va
riety of tunnel types are defined and the ingress needs to select a type of tunn
el which is supported by the egress. This document defines how to advertise egr
ess tunnel capabilities in IS-IS Router Capability TLV.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-isis-encapsulation
-cap-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-isis-encapsulation-cap-01.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-ospf-encapsulation-cap" quoteTitle="true" ta
rget="https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-09" derivedA
nchor="OSPF-ENCAP">
<front>
<title>The Tunnel Encapsulations OSPF Router Information</title>
<author initials="X" surname="Xu" fullname="Xiaohu Xu">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Raszuk" fullname="Robert Raszuk">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Contreras" fullname="Luis Contreras">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Jalil" fullname="Luay Jalil">
<organization showOnFrontPage="true"/>
</author>
<date month="October" day="10" year="2017"/>
<abstract>
<t>Networks use tunnels for a variety of reasons. A large variety
of tunnel types are defined and the tunnel encapsulator router needs to select
a type of tunnel which is supported by the tunnel decapsulator router. This doc
ument defines how to advertise, in OSPF Router Information Link State Advertisem
ent (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulat
or.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ospf-encapsulation
-cap-09"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-ospf-encapsulation-cap-09.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC2983" target="https://www.rfc-editor.org/info/rfc2
983" quoteTitle="true" derivedAnchor="RFC2983">
<front>
<title>Differentiated Services and Tunnels</title>
<author initials="D." surname="Black" fullname="D. Black">
<organization showOnFrontPage="true"/>
</author>
<date year="2000" month="October"/>
<abstract>
<t>This document considers the interaction of Differentiated Servi
ces (diffserv) with IP tunnels of various forms. This memo provides information
for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2983"/>
<seriesInfo name="DOI" value="10.17487/RFC2983"/>
</reference>
<reference anchor="RFC5920" target="https://www.rfc-editor.org/info/rfc5
920" quoteTitle="true" derivedAnchor="RFC5920">
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author initials="L." surname="Fang" fullname="L. Fang" role="editor
">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="July"/>
<abstract>
<t>This document provides a security framework for Multiprotocol L
abel Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Netw
orks. This document addresses the security aspects that are relevant in the con
text of MPLS and GMPLS. It describes the security threats, the related defensiv
e techniques, and the mechanisms for detection and reporting. This document emp
hasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-p
rovider security considerations for building and maintaining MPLS and GMPLS netw
orks across different domains or different Service Providers. This document is
not an Internet Standards Track specification; it is published for informationa
l purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5920"/>
<seriesInfo name="DOI" value="10.17487/RFC5920"/>
</reference>
<reference anchor="RFC6790" target="https://www.rfc-editor.org/info/rfc6
790" quoteTitle="true" derivedAnchor="RFC6790">
<front>
<title>The Use of Entropy Labels in MPLS Forwarding</title>
<author initials="K." surname="Kompella" fullname="K. Kompella">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Drake" fullname="J. Drake">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Amante" fullname="S. Amante">
<organization showOnFrontPage="true"/>
</author>
<author initials="W." surname="Henderickx" fullname="W. Henderickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Yong" fullname="L. Yong">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="November"/>
<abstract>
<t>Load balancing is a powerful tool for engineering traffic acros
s a network. This memo suggests ways of improving load balancing across MPLS ne
tworks using the concept of "entropy labels". It defines the concept, describes
why entropy labels are useful, enumerates properties of entropy labels that all
ow maximal benefit, and shows how they can be signaled and used for various appl
ications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6790"/>
<seriesInfo name="DOI" value="10.17487/RFC6790"/>
</reference>
<reference anchor="RFC6862" target="https://www.rfc-editor.org/info/rfc6
862" quoteTitle="true" derivedAnchor="RFC6862">
<front>
<title>Keying and Authentication for Routing Protocols (KARP) Overvi
ew, Threats, and Requirements</title>
<author initials="G." surname="Lebovitz" fullname="G. Lebovitz">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Bhatia" fullname="M. Bhatia">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Weis" fullname="B. Weis">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="March"/>
<abstract>
<t>Different routing protocols employ different mechanisms for sec
uring protocol packets on the wire. While most already have some method for acc
omplishing cryptographic message authentication, in many cases the existing meth
ods are dated, vulnerable to attack, and employ cryptographic algorithms that ha
ve been deprecated. The "Keying and Authentication for Routing Pr
otocols" (KARP) effort aims to overhaul and improve these mechanisms. This docu
ment does not contain protocol specifications. Instead, it defines the areas wh
ere protocol specification work is needed. This document is a companion documen
t to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Gu
idelines"; together they form the guidance and instruction KARP design teams wil
l use to review and overhaul routing protocol transport security.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6862"/>
<seriesInfo name="DOI" value="10.17487/RFC6862"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" quoteTitle="true" derivedAnchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-pas
sing transport that has no inherent congestion control mechanisms. This documen
t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<t>Because congestion control is critical to the stable operation
of the Internet, applications and other protocols that choose to use UDP as an I
nternet transport must employ mechanisms to prevent congestion collapse and to e
stablish some degree of fairness with concurrent traffic. They may also need to
implement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protoco
ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
when these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multic
ast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8354" target="https://www.rfc-editor.org/info/rfc8
354" quoteTitle="true" derivedAnchor="RFC8354">
<front>
<title>Use Cases for IPv6 Source Packet Routing in Networking (SPRIN
G)</title>
<author initials="J." surname="Brzozowski" fullname="J. Brzozowski">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Leddy" fullname="J. Leddy">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Maglione" fullname="R. Maglione" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Townsley" fullname="M. Townsley">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="March"/>
<abstract>
<t>The Source Packet Routing in Networking (SPRING) architecture d
escribes how Segment Routing can be used to steer packets through an IPv6 or MPL
S network using the source routing paradigm. This document illustrates some use
cases for Segment Routing in an IPv6-only environment.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8354"/>
<seriesInfo name="DOI" value="10.17487/RFC8354"/>
</reference>
<reference anchor="RFC8662" target="https://www.rfc-editor.org/info/rfc8
662" quoteTitle="true" derivedAnchor="RFC8662">
<front>
<title>Entropy Label for Source Packet Routing in Networking (SPRING
) Tunnels</title>
<seriesInfo name="RFC" value="8662"/>
<seriesInfo name="DOI" value="10.17487/RFC8662"/>
<author initials="S" surname="Kini" fullname="Sriganesh Kini">
<organization showOnFrontPage="true"/>
</author>
<author initials="K" surname="Kompella" fullname="Kireeti Kompella">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Litkowski" fullname="Stephane Litkowsk
i">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc8
665" quoteTitle="true" derivedAnchor="RFC8665">
<front>
<title>OSPF Extensions for Segment Routing</title>
<seriesInfo name="RFC" value="8665"/>
<seriesInfo name="DOI" value="10.17487/RFC8665"/>
<author initials="P" surname="Psenak" fullname="Peter Psenak" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="S" surname="Previdi" fullname="Stefano Previdi" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Gredler" fullname="Hannes Gredler">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Shakir" fullname="Rob Shakir">
<organization showOnFrontPage="true"/>
</author>
<author initials="W" surname="Henderickx" fullname="Wim Henderickx">
<organization showOnFrontPage="true"/>
</author>
<author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
<reference anchor="RFC8667" target="https://www.rfc-editor.org/info/rfc8
667" quoteTitle="true" derivedAnchor="RFC8667">
<front>
<title>IS-IS Extensions for Segment Routing</title>
<seriesInfo name="RFC" value="8667"/>
<seriesInfo name="DOI" value="10.17487/RFC8667"/>
<author initials="S" surname="Previdi" fullname="Stefano Previdi" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="L" surname="Ginsberg" fullname="Les Ginsberg" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Gredler" fullname="Hannes Gredler">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Decraene" fullname="Bruno Decraene">
<organization showOnFrontPage="true"/>
</author>
<date month="December" year="2019"/>
</front>
</reference>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.a-1">Thanks to Joel Halpern, Bruno Decraene, Loa A
ndersson,
Ron Bonica, Eric Rosen, Jim Guichard, Gunter Van De Velde,
Andy Malis, Robert Sparks, and Al Morton for their insightful
comments on this document.</t>
<t pn="section-appendix.a-2">Additional thanks to Mirja Kuehlewind, Alvaro
Retana, Spencer Dawkins,
Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and Eric Vyncke
for careful reviews and resulting comments.</t>
</section>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.b">
<name slugifiedName="name-contributors">Contributors</name>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-1">
Ahmed Bashandy
Individual Individual
Email: abashandy.ietf@gmail.com Email: abashandy.ietf@gmail.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-2">
Clarence Filsfils Clarence Filsfils
Cisco Cisco
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-3">
John Drake John Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-4">
Shaowen Ma Shaowen Ma
Mellanox Technologies Mellanox Technologies
Email: mashaowen@gmail.com Email: mashaowen@gmail.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-5">
Mach Chen Mach Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-6">
Hamid Assarpour Hamid Assarpour
Broadcom Broadcom
Email:hamid.assarpour@broadcom.com Email:hamid.assarpour@broadcom.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-7">
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
Email: robert@raszuk.net Email: robert@raszuk.net
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-8">
Uma Chunduri Uma Chunduri
Huawei Huawei
Email: uma.chunduri@gmail.com Email: uma.chunduri@gmail.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-9">
Luis M. Contreras Luis M. Contreras
Telefonica I+D Telefonica I+D
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-10">
Luay Jalil Luay Jalil
Verizon Verizon
Email: luay.jalil@verizon.com Email: luay.jalil@verizon.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-11">
Gunter Van De Velde Gunter Van De Velde
Nokia Nokia
Email: gunter.van_de_velde@nokia.com Email: gunter.van_de_velde@nokia.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-12">
Tal Mizrahi Tal Mizrahi
Marvell Marvell
Email: talmi@marvell.com Email: talmi@marvell.com
</artwork>
<artwork name="" type="" align="left" alt="" pn="section-appendix.b-13">
Jeff Tantsura Jeff Tantsura
Individual Apstra, Inc.
Email: jefftant@gmail.com Email: jefftant.ietf@gmail.com
</artwork>
]]></artwork>
</figure>
</section> </section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<section anchor="Acknowledgements" title="Acknowledgements"> ="include" pn="section-appendix.c">
<t>Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
Ron Bonica, Eric Rosen, Jim Guichard, Gunter Van De Velde, <author fullname="Xiaohu Xu" initials="X." surname="Xu">
Andy Malis, Robert Sparks, and Al Morton for their insightful <organization showOnFrontPage="true">Alibaba, Inc</organization>
comments on this draft.</t> <address>
<email>xiaohu.xxh@alibaba-inc.com</email>
<t>Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer Dawkins, </address>
Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and &#x00C9;ric Vyncke </author>
for careful reviews and resulting comments.</t> <author fullname="Stewart Bryant" initials="S." surname="Bryant">
<organization showOnFrontPage="true">Futurewei Technologies</organizatio
n>
<address>
<email>stewart.bryant@gmail.com</email>
</address>
</author>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization showOnFrontPage="true">Old Dog Consulting</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<author fullname="Syed Hassan" initials="S." surname="Hassan">
<organization showOnFrontPage="true">Cisco</organization>
<address>
<email>shassan@cisco.com</email>
</address>
</author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization showOnFrontPage="true">Nokia</organization>
<address>
<email>wim.henderickx@nokia.com</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization showOnFrontPage="true">Huawei</organization>
<address>
<email>lizhenbin@huawei.com</email>
</address>
</author>
</section> </section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3031"?>
<?rfc include="reference.RFC.3032"?>
<?rfc include="reference.RFC.4023"?>
<?rfc include="reference.RFC.5095"?>
<?rfc include="reference.RFC.6040"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.7510"?>
<?rfc include="reference.RFC.7684"?>
<?rfc include="reference.RFC.7794"?>
<?rfc include="reference.RFC.7981"?>
<?rfc include="reference.RFC.8174"?>
<?rfc include="reference.RFC.8402"?>
<!-- <?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>; companion
document RFC YYYY-->
<reference anchor='RFCYYYY'>
<front>
<title>Segment Routing with MPLS data plane</title>
<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'>
<organization />
</author>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization />
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization />
</author>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'>
<organization />
</author>
<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
<organization />
</author>
<author initials='R' surname='Shakir' fullname='Rob Shakir'>
<organization />
</author>
<date month='May' day='1' year='2019' />
<abstract><t>Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through a controlled set of instructions, called segments, by p
repending the packet with an SR header. In the MPLS dataplane, the SR header is
instantiated through a label stack. This document specifies the forwarding beha
vior to allow instantiating SR over the MPLS dataplane.</t></abstract>
</front>
<seriesInfo name="RFC" value="YYYY"/>
<seriesInfo name="DOI" value="10.17487/RFCYYYY"/>
</reference>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2983"?>
<?rfc include="reference.RFC.5920"?>
<?rfc include="reference.RFC.6790"?>
<?rfc include="reference.RFC.6862"?>
<?rfc include="reference.RFC.8085"?>
<?rfc include="reference.RFC.8354"?>
<!-- <?rfc include="reference.I-D.ietf-bess-datacenter-gateway"?>; I-D Exists --
>
<reference anchor='DATACENTER-GATEWAY'>
<front>
<title>Gateway Auto-Discovery and Route Advertisement for Segment Routing Enable
d Domain Interconnection</title>
<author initials='A' surname='Farrel' fullname='Adrian Farrel'>
<organization />
</author>
<author initials='J' surname='Drake' fullname='John Drake'>
<organization />
</author>
<author initials='E' surname='Rosen' fullname='Eric Rosen'>
<organization />
</author>
<author initials='K' surname='Patel' fullname='Keyur Patel'>
<organization />
</author>
<author initials='L' surname='Jalil' fullname='Luay Jalil'>
<organization />
</author>
<date month='February' day='26' year='2019' />
<abstract><t>Data centers are critical components of the infrastructure used by
network operators to provide services to their customers. Data centers are atta
ched to the Internet or a backbone network by gateway routers. One data center
typically has more than one gateway for commercial, load balancing, and resilien
cy reasons. Segment Routing is a popular protocol mechanism for use within a da
ta center, but also for steering traffic that flows between two data center site
s. In order that one data center site may load balance the traffic it sends to
another data center site, it needs to know the complete set of gateway routers a
t the remote data center, the points of connection from those gateways to the ba
ckbone network, and the connectivity across the backbone network. Segment Routi
ng may also be operated in other domains, such as access networks. Those domain
s also need to be connected across backbone networks through gateways. This doc
ument defines a mechanism using the BGP Tunnel Encapsulation attribute to allow
each gateway router to advertise the routes to the prefixes in the Segment Routi
ng domains to which it provides access, and also to advertise on behalf of each
other gateway to the same Segment Routing domain.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-bess-datacenter-gateway-0
2' />
</reference>
<!-- <?rfc include="reference.I-D.ietf-ospf-segment-routing-extensions"?>; RFC E
d Queue -->
<reference anchor='OSPF-EXTENSIONS'>
<front>
<title>OSPF Extensions for Segment Routing</title>
<author initials='P' surname='Psenak' fullname='Peter Psenak' role="editor">
<organization />
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi' role="editor">
<organization />
</author>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization />
</author>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization />
</author>
<author initials='R' surname='Shakir' fullname='Rob Shakir'>
<organization />
</author>
<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
<organization />
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization />
</author>
<date month='December' day='5' year='2018' />
<abstract><t>Segment Routing (SR) allows a flexible definition of end-to-end pat
hs within IGP topologies by encoding paths as sequences of topological sub-paths
, called "segments". These segments are advertised by the link-state routing pr
otocols (IS-IS and OSPF). This draft describes the OSPFv2 extensions required f
or Segment Routing.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-ospf-segment-routing-exte
nsions-27' />
</reference>
<!-- <?rfc include="reference.I-D.ietf-isis-segment-routing-extensions"?>; RFC E
d Queue -->
<reference anchor='ISIS-EXTENSIONS'>
<front>
<title>IS-IS Extensions for Segment Routing</title>
<author initials='S' surname='Previdi' fullname='Stefano Previdi' role="editor">
<organization />
</author>
<author initials='L' surname='Ginsberg' fullname='Les Ginsberg' role="editor">
<organization />
</author>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization />
</author>
<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'>
<organization />
</author>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization />
</author>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'>
<organization />
</author>
<date month='May' day='19' year='2019' />
<abstract><t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of topological sub-p
aths, called "segments". These segments are advertised by the link-state routin
g protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensio
ns that need to be introduced for Segment Routing operating on an MPLS data-plan
e.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-isis-segment-routing-exte
nsions-25' />
</reference>
<!-- <?rfc include="reference.I-D.ietf-ospf-encapsulation-cap"?>; RFC Ed Queue -
->
<reference anchor='OSPF-ROUTER'>
<front>
<title>The Tunnel Encapsulations OSPF Router Information</title>
<author initials='X' surname='Xu' fullname='Xiaohu Xu' role="editor">
<organization />
</author>
<author initials='B' surname='Decraene' fullname='Bruno Decraene' role="editor">
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<organization />
</author>
<author initials='L' surname='Contreras' fullname='Luis Contreras'>
<organization />
</author>
<author initials='L' surname='Jalil' fullname='Luay Jalil'>
<organization />
</author>
<date month='October' day='10' year='2017' />
<abstract><t>Networks use tunnels for a variety of reasons. A large variety of
tunnel types are defined and the tunnel encapsulator router needs to select a ty
pe of tunnel which is supported by the tunnel decapsulator router. This documen
t defines how to advertise, in OSPF Router Information Link State Advertisement
(LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator.<
/t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-ospf-encapsulation-cap-09
' />
</reference>
<!-- <?rfc include="reference.I-D.ietf-isis-encapsulation-cap"?>; Expired -->
<reference anchor='ISIS-ENCAP'>
<front>
<title>Advertising Tunnelling Capability in IS-IS</title>
<author initials='X' surname='Xu' fullname='Xiaohu Xu' role="editor">
<organization />
</author>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'>
<organization />
</author>
<author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<organization />
</author>
<author initials='U' surname='Chunduri' fullname='Uma Chunduri'>
<organization />
</author>
<author initials='L' surname='Contreras' fullname='Luis Contreras'>
<organization />
</author>
<author initials='L' surname='Jalil' fullname='Luay Jalil'>
<organization />
</author>
<date month='April' day='24' year='2017' />
<abstract><t>Some networks use tunnels for a variety of reasons. A large variet
y of tunnel types are defined and the ingress needs to select a type of tunnel w
hich is supported by the egress. This document defines how to advertise egress
tunnel capabilities in IS-IS Router Capability TLV.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-isis-encapsulation-cap-01
' />
</reference>
<!-- <?rfc include="reference.I-D.ietf-mpls-spring-entropy-label"?>; RFC Ed Queu
e -->
<reference anchor='ENTROPY-LABEL'>
<front>
<title>Entropy label for SPRING tunnels</title>
<author initials='S' surname='Kini' fullname='Sriganesh Kini'>
<organization />
</author>
<author initials='K' surname='Kompella' fullname='Kireeti Kompella'>
<organization />
</author>
<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
<organization />
</author>
<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
<organization />
</author>
<author initials='R' surname='Shakir' fullname='Rob Shakir'>
<organization />
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization />
</author>
<date month='July' day='16' year='2018' />
<abstract><t>Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called segments. Segm
ent Routing can be applied to the Multi Protocol Label Switching (MPLS) data pla
ne. Entropy label (EL) is a technique used in MPLS to improve load-balancing.
This document examines and describes how ELs are to be applied to Segment Routin
g MPLS.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-mpls-spring-entropy-label
-12' />
</reference>
<!-- <?rfc include="reference.I-D.ietf-6man-segment-routing-header"?>; AD Evalua
tion::Revised I-D Needed for 2 days -->
<reference anchor='IPV6-SEGMENT'>
<front>
<title>IPv6 Segment Routing Header (SRH)</title>
<author initials='C' surname='Filsfils' fullname='Clarence Filsfils' role="edito
r">
<organization />
</author>
<author initials='D' surname='Dukes' fullname='Darren Dukes' role="editor">
<organization />
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization />
</author>
<author initials='J' surname='Leddy' fullname='John Leddy'>
<organization />
</author>
<author initials='S' surname='Matsushima' fullname='Satoru Matsushima'>
<organization />
</author>
<author initials='d' surname='daniel.voyer@bell.ca' fullname='daniel.voyer@bell.
ca'>
<organization />
</author>
<date month='June' day='13' year='2019' />
<abstract><t>Segment Routing can be applied to the IPv6 data plane using a new t
ype of Routing Extension Header. This document describes the Segment Routing Ex
tension Header and how it is used by Segment Routing capable nodes.</t></abstrac
t>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-6man-segment-routing-head
er-21' />
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 108 change blocks. 
903 lines changed or deleted 1692 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/