rfc8665xml2.original.xml   rfc8665.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?rfc toc="yes"?> nsus="true" docName="draft-ietf-ospf-segment-routing-extensions-27" indexInclude
<?rfc tocompact="yes"?> ="true" ipr="trust200902" number="8665" prepTime="2019-12-04T21:10:11" scripts="
<?rfc tocdepth="3"?> Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3"
<?rfc tocindent="yes"?> tocInclude="true" xml:lang="en">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-e
<?rfc sortrefs="yes"?> xtensions-27" rel="prev"/>
<?rfc comments="yes"?> <link href="https://dx.doi.org/10.17487/rfc8665" rel="alternate"/>
<?rfc inline="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ospf-segment-routing-extensions-27"
ipr="trust200902">
<front> <front>
<title abbrev="OSPF Extensions for Segment Routing">OSPF Extensions for <title abbrev="OSPF Extensions for Segment Routing">OSPF Extensions for Segm
Segment Routing</title> ent Routing</title>
<seriesInfo name="RFC" value="8665" stream="IETF"/>
<author fullname="Peter Psenak" initials="P." role="editor" <author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak"
surname="Psenak"> >
<organization>Cisco Systems, Inc.</organization> <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Apollo Business Center</street> <street>Apollo Business Center</street>
<street>Mlynske nivy 43</street> <street>Mlynske nivy 43</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>821 09</code> <code>821 09</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stefano Previdi" initials="S." role="editor" surname="Prev
<author fullname="Stefano Previdi" initials="S." role="editor" idi">
surname="Previdi"> <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Via Del Serafico, 200</street> <street>Via Del Serafico, 200</street>
<city>Rome</city> <city>Rome</city>
<code>00142</code> <code>00142</code>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>stefano@previdi.net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city>Brussels</city> <city>Brussels</city>
<region/> <region/>
<code/> <code/>
<country>Belgium</country> <country>Belgium</country>
</postal> </postal>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler"> <author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>RtBrick Inc.</organization> <organization showOnFrontPage="true">RtBrick Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/>
<country></country>
</postal> </postal>
<email>hannes@rtbrick.com</email> <email>hannes@rtbrick.com</email>
</address> </address>
</author> </author>
<author fullname="Rob Shakir" initials="R." surname="Shakir"> <author fullname="Rob Shakir" initials="R." surname="Shakir">
<organization>Google, Inc.</organization> <organization showOnFrontPage="true">Google, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city> <city>Mountain View</city>
<code>94043</code> <code>94043</code>
<region>CA</region> <region>CA</region>
<country>United States of America</country>
<country>US</country>
</postal> </postal>
<email>robjs@google.com</email> <email>robjs@google.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>
<postal> <postal>
<street>Copernicuslaan 50</street> <street>Copernicuslaan 50</street>
<city>Antwerp</city> <city>Antwerp</city>
<code>2018</code> <code>2018</code>
<country>Belgium</country>
<country>BE</country>
</postal> </postal>
<email>wim.henderickx@nokia.com</email> <email>wim.henderickx@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Apstra, Inc.</organization> <organization showOnFrontPage="true">Apstra, Inc.</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/>
<country></country>
</postal> </postal>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="12" year="2019"/>
<date/>
<area>Routing</area> <area>Routing</area>
<workgroup>Open Shortest Path First IGP</workgroup> <workgroup>Open Shortest Path First IGP</workgroup>
<keyword>MPLS</keyword> <keyword>MPLS</keyword>
<keyword>SID</keyword> <keyword>SID</keyword>
<keyword>IGP</keyword> <keyword>IGP</keyword>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<keyword>Label advertisement</keyword> <keyword>Label advertisement</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">Segment Routing (SR) allows a flexible definiti
<t>Segment Routing (SR) allows a flexible definition of end-to-end on of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised topological subpaths called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF).</t> by the link-state routing protocols (IS-IS and OSPF).</t>
<t pn="section-abstract-2">This document describes the OSPFv2 extensions r
<t>This draft describes the OSPFv2 extensions required for Segment Routing equired for Segment Routing.</t>
.</t>
</abstract> </abstract>
<boilerplate>
<note title="Requirements Language"> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "exclude" pn="section-boilerplate.1">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
document are to be interpreted as described in <xref >
target="RFC2119"></xref>.</t> <t pn="section-boilerplate.1-1">
</note> 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/rfc8665" 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-requirements-
language">Requirements Language</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-segment-routing-identifie
rs">Segment Routing Identifiers</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sid-label-sub
-tlv">SID/Label Sub-TLV</xref></t>
</li>
</ul>
</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-segment-routing-capabilit
ie">Segment Routing Capabilities</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-sr-algorithm-
tlv">SR-Algorithm TLV</xref></t>
</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-sid-label-ran
ge-tlv">SID/Label Range TLV</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3">
<t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derive
dContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-sr-local-bloc
k-tlv">SR Local Block TLV</xref></t>
</li>
<li pn="section-toc.1-1.3.2.4">
<t keepWithNext="true" pn="section-toc.1-1.3.2.4.1"><xref derive
dContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-srms-preferen
ce-tlv">SRMS Preference TLV</xref></t>
</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-ospf-extended-prefix-rang
e-">OSPF Extended Prefix Range TLV</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-prefix-sid-sub-tlv">Prefi
x-SID Sub-TLV</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-adjacency-segment-identif
ie">Adjacency Segment Identifier (Adj-SID)</xref></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-adj-sid-sub-t
lv">Adj-SID Sub-TLV</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-lan-adj-sid-s
ub-tlv">LAN Adj-SID Sub-TLV</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-elements-of-procedure">El
ements of Procedure</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derive
dContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-intra-area-se
gment-routing-">Intra-area Segment Routing in OSPFv2</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derive
dContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-inter-area-se
gment-routing-">Inter-area Segment Routing in OSPFv2</xref></t>
</li>
<li pn="section-toc.1-1.7.2.3">
<t keepWithNext="true" pn="section-toc.1-1.7.2.3.1"><xref derive
dContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-segment-routi
ng-for-externa">Segment Routing for External Prefixes</xref></t>
</li>
<li pn="section-toc.1-1.7.2.4">
<t keepWithNext="true" pn="section-toc.1-1.7.2.4.1"><xref derive
dContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-advertisement
-of-adj-sid">Advertisement of Adj-SID</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.7.2.4.2">
<li pn="section-toc.1-1.7.2.4.2.1">
<t keepWithNext="true" pn="section-toc.1-1.7.2.4.2.1.1"><xre
f derivedContent="7.4.1" format="counter" sectionFormat="of" target="section-7.4
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a
dvertisement-of-adj-sid-on">Advertisement of Adj-SID on Point-to-Point Links</xr
ef></t>
</li>
<li pn="section-toc.1-1.7.2.4.2.2">
<t keepWithNext="true" pn="section-toc.1-1.7.2.4.2.2.1"><xre
f derivedContent="7.4.2" format="counter" sectionFormat="of" target="section-7.4
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a
djacency-sid-on-broadcast-">Adjacency SID on Broadcast or NBMA Interfaces</xref>
</t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t keepWithNext="true" pn="section-toc.1-1.8.2.1.1"><xref derive
dContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-ospf-router-i
nformation-ri-">OSPF Router Information (RI) TLVs Registry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t keepWithNext="true" pn="section-toc.1-1.8.2.2.1"><xref derive
dContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-extend
ed-prefix-opaq">OSPFv2 Extended Prefix Opaque LSA TLVs Registry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t keepWithNext="true" pn="section-toc.1-1.8.2.3.1"><xref derive
dContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-extend
ed-prefix-tlv-">OSPFv2 Extended Prefix TLV Sub-TLVs Registry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.4">
<t keepWithNext="true" pn="section-toc.1-1.8.2.4.1"><xref derive
dContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-extend
ed-link-tlv-su">OSPFv2 Extended Link TLV Sub-TLVs Registry</xref></t>
</li>
<li pn="section-toc.1-1.8.2.5">
<t keepWithNext="true" pn="section-toc.1-1.8.2.5.1"><xref derive
dContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-igp-algorithm
-types-registr">IGP Algorithm Types Registry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-tlv-sub-tlv-error-handlin
g">TLV/Sub-TLV Error Handling</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedConten
t="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-security-considerations
">Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedConten
t="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedC
ontent="" format="title" sectionFormat="of" target="name-references">References<
/xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t keepWithNext="true" pn="section-toc.1-1.11.2.1.1"><xref deriv
edContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-normative-
references">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t keepWithNext="true" pn="section-toc.1-1.11.2.2.1"><xref deriv
edContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-informativ
e-references">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derived
Content="" format="title" sectionFormat="of" target="name-acknowledgements">Ackn
owledgements</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derived
Content="" format="title" sectionFormat="of" target="name-contributors">Contribu
tors</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedConten
t="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derived
Content="" format="title" sectionFormat="of" target="name-authors-addresses">Aut
hors' 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>Segment Routing (SR) allows a flexible definition of end-to-end <name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">Segment Routing (SR) allows a flexible definition of e
nd-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised topological subpaths called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF). Prefix segments by the link-state routing protocols (IS-IS and OSPF). Prefix segments
represent an ECMP-aware shortest-path to a prefix (or a node), as per represent an ECMP-aware shortest path to a prefix (or a node), as per
the state of the IGP topology. Adjacency segments represent a hop over a the state of the IGP topology. Adjacency segments represent a hop over a
specific adjacency between two nodes in the IGP. A prefix segment is typic ally specific adjacency between two nodes in the IGP. A prefix segment is typic ally
a multi-hop path while an adjacency segment, in most cases, is a one-hop p ath. SR's a multi-hop path while an adjacency segment, in most cases, is a one-hop p ath. SR's
control-plane can be applied to both IPv6 and MPLS data-planes, and control plane can be applied to both IPv6 and MPLS data planes, and it
does not require any additional signalling (other than IGP extensions). does not require any additional signaling (other than IGP extensions).
The IPv6 data plane is out of the scope of this specification - it is not The IPv6 data plane is out of the scope of this specification; it is not a
applicable pplicable
to OSPFv2 which only supports the IPv4 address-family. When used in MPLS to OSPFv2, which only supports the IPv4 address family. When used in MPLS
networks, SR paths do not require any LDP or RSVP-TE signalling. However, networks, SR paths do not require any LDP or RSVP-TE signaling. However, S
SR can R can
interoperate in the presence of LSPs established with RSVP or LDP.</t> interoperate in the presence of LSPs established with RSVP or LDP.</t>
<t pn="section-1-2">There are additional segment types, e.g., Binding Segm
<t>There are additional segment types, e.g., Binding SID defined in <xref ent Identifier (SID) defined in <xref target="RFC8402" format="default" sectionF
target="I-D.ietf-spring-segment-routing"/>.</t> ormat="of" derivedContent="RFC8402"/>.</t>
<t pn="section-1-3">This document describes the OSPF extensions required f
<t>This draft describes the OSPF extensions required for Segment Routing.< or Segment Routing.</t>
/t> <t pn="section-1-4">Segment Routing architecture is described in <xref tar
get="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t
<t>Segment Routing architecture is described in <xref >
target="I-D.ietf-spring-segment-routing"/>.</t> <t pn="section-1-5">Segment Routing use cases are described in <xref targe
t="RFC7855" format="default" sectionFormat="of" derivedContent="RFC7855"/>.</t>
<t>Segment Routing use cases are described in <xref target="RFC7855"/>.</t <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1
> ">
<name slugifiedName="name-requirements-language">Requirements Language</
name>
<t pn="section-1.1-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT 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" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section title="Segment Routing Identifiers"> <name slugifiedName="name-segment-routing-identifiers">Segment Routing Ide
<t>Segment Routing defines various types of Segment Identifiers (SIDs): ntifiers</name>
Prefix-SID, Adjacency-SID, LAN Adjacency SID, and Binding SID.</t> <t pn="section-2-1">Segment Routing defines various types of Segment Ident
ifiers (SIDs):
<t>Extended Prefix/Link Opaque LSAs defined in <xref target="RFC7684"/> ar Prefix-SID, Adjacency SID, LAN Adjacency SID, and Binding SID.</t>
e used for <t pn="section-2-2">Extended Prefix/Link Opaque Link State Advertisements
(LSAs) defined in <xref target="RFC7684" format="default" sectionFormat="of" der
ivedContent="RFC7684"/> are used for
advertisements of the various SID types.</t> advertisements of the various SID types.</t>
<section anchor="SIDLABEL" numbered="true" toc="include" removeInRFC="fals
<section anchor="SIDLABEL" title="SID/Label Sub-TLV"> e" pn="section-2.1">
<t>The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined <name slugifiedName="name-sid-label-sub-tlv">SID/Label Sub-TLV</name>
<t pn="section-2.1-1">The SID/Label Sub-TLV appears in multiple TLVs or
sub-TLVs defined
later in this document. It is used to advertise the SID or label later in this document. It is used to advertise the SID or label
associated with a prefix or adjacency. The SID/Label Sub-TLV has followi associated with a prefix or adjacency. The SID/Label Sub-TLV has the fol
ng lowing
format:<figure> format:</t>
<artwork> 0 1 2 <artwork name="" type="" align="left" alt="" pn="section-2.1-2"> 0
3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) | | SID/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
<t pn="section-2.1-3">where:</t>
where: <ul empty="true" bare="false" spacing="normal" pn="section-2.1-4">
</artwork> <li pn="section-2.1-4.1">
</figure><list style="hanging"> <dl newline="false" spacing="normal" pn="section-2.1-4.1.1">
<t>Type: 1</t> <dt pn="section-2.1-4.1.1.1">Type:</dt>
<dd pn="section-2.1-4.1.1.2">1</dd>
<t>Length: Variable, 3 or 4 octet</t> <dt pn="section-2.1-4.1.1.3">Length:</dt>
<dd pn="section-2.1-4.1.1.4">3 or 4 octets</dd>
<t>SID/Label: If length is set to 3, then the 20 rightmost bits <dt pn="section-2.1-4.1.1.5">SID/Label:</dt>
represent a label. If length is set to 4, then the value represents <dd pn="section-2.1-4.1.1.6">
<t pn="section-2.1-4.1.1.6.1">If the length is set to 3, then th
e 20 rightmost bits
represent a label. If the length is set to 4, then the value represe
nts
a 32-bit SID.</t> a 32-bit SID.</t>
</dd>
<t>The receiving router MUST ignore the SID/Label Sub-TLV if the len </dl>
gth </li>
is other then 3 or 4.</t> </ul>
</list></t>
</section> </section>
</section> </section>
<section anchor="SRCAP" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="SRCAP" title="Segment Routing Capabilities"> ="section-3">
<t>Segment Routing requires some additional router capabilities to be adve <name slugifiedName="name-segment-routing-capabilitie">Segment Routing Cap
rtised abilities</name>
<t pn="section-3-1">Segment Routing requires some additional router capabi
lities to be advertised
to other routers in the area.</t> to other routers in the area.</t>
<t pn="section-3-2">These SR capabilities are advertised in the Router Inf
<t>These SR capabilities are advertised in the Router Information Opaque L ormation Opaque LSA
SA (defined in <xref target="RFC7770" format="default" sectionFormat="of" der
(defined in <xref target="RFC7770"/>). The TLVs defined below are applicab ivedContent="RFC7770"/>). The TLVs defined below are applicable to
le to
both OSPFv2 and OSPFv3; see also both OSPFv2 and OSPFv3; see also
<xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></t> <xref target="RFC8666" format="default" sectionFormat="of" derivedContent
="RFC8666"/>.</t>
<section anchor="SRALGO" title="SR-Algorithm TLV"> <section anchor="SRALGO" numbered="true" toc="include" removeInRFC="false"
<t>The SR-Algorithm TLV is a top-level TLV of the Router Information Opa pn="section-3.1">
que LSA <name slugifiedName="name-sr-algorithm-tlv">SR-Algorithm TLV</name>
(defined in <xref target="RFC7770"/>).</t> <t pn="section-3.1-1">The SR-Algorithm TLV is a top-level TLV of the Rou
ter Information Opaque LSA
<t>The SR-Algorithm TLV is optional. It SHOULD only be advertised once (defined in <xref target="RFC7770" format="default" sectionFormat="of" d
erivedContent="RFC7770"/>).</t>
<t pn="section-3.1-2">The SR-Algorithm TLV is optional. It <bcp14>SHOULD
</bcp14> only be advertised once
in the Router Information Opaque LSA. If the SR-Algorithm TLV is not adv ertised in the Router Information Opaque LSA. If the SR-Algorithm TLV is not adv ertised
by the node, such node is considered as not being segment routing capabl by the node, such a node is considered as not being Segment Routing capa
e.</t> ble.</t>
<t pn="section-3.1-3"> An SR Router can use various algorithms when calc
<t> An SR Router can use various algorithms when calculating reachabilit ulating reachability
y
to OSPF routers or prefixes in an OSPF area. Examples of these algorithm s are to OSPF routers or prefixes in an OSPF area. Examples of these algorithm s are
metric based Shortest Path First (SPF), various flavors of Constrained S PF, etc. metric-based Shortest Path First (SPF), various flavors of Constrained S PF, etc.
The SR-Algorithm TLV allows a router to advertise the algorithms current ly used The SR-Algorithm TLV allows a router to advertise the algorithms current ly used
by the router to other routers in an OSPF area. The SR-Algorithm TLV has by the router to other routers in an OSPF area. The SR-Algorithm TLV has
following format: <figure> the following format: </t>
<artwork> <artwork name="" type="" align="left" alt="" pn="section-3.1-4">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm n | | | Algorithm 1 | Algorithm... | Algorithm n | |
+- -+ +- -+
| | | |
+ + + +
</artwork>
where:</artwork> <t pn="section-3.1-5">where:</t>
</figure><list style="hanging"> <ul empty="true" bare="false" spacing="normal" pn="section-3.1-6">
<t>Type: 8</t> <li pn="section-3.1-6.1">
<dl newline="false" spacing="normal" pn="section-3.1-6.1.1">
<t>Variable, in octets, dependent on number of algorithms advertised <dt pn="section-3.1-6.1.1.1">Type:</dt>
.</t> <dd pn="section-3.1-6.1.1.2">8</dd>
<dt pn="section-3.1-6.1.1.3">Length:</dt>
<t> Algorithm: Single octet identifying the algorithm. The following <dd pn="section-3.1-6.1.1.4">Variable, in octets, depending on the
values are defined by this document:<list style="hanging"> number of algorithms advertised</dd>
<dt pn="section-3.1-6.1.1.5">Algorithm:</dt>
<t>0: Shortest Path First (SPF) algorithm based on link metric. <dd pn="section-3.1-6.1.1.6">
This is <t pn="section-3.1-6.1.1.6.1">Single octet identifying the algor
the standard shortest path algorithm as computed by the OSPF pro ithm. The following
tocol. values are defined by this document:</t>
Consistent with the deployed practice for link-state protocols, <dl newline="false" spacing="normal" indent="6" pn="section-3.1-
Algorithm 0 6.1.1.6.2">
permits any node to overwrite the SPF path with a different path <dt pn="section-3.1-6.1.1.6.2.1">0:</dt>
based on <dd pn="section-3.1-6.1.1.6.2.2">Shortest Path First (SPF) alg
its local policy. If the SR-Algorithm TLV is advertised, Algorit orithm based on link
hm 0 metric. This is the standard shortest path algorithm as computed
MUST be included.</t> by the OSPF protocol. Consistent with the deployed practice for
link-state protocols, Algorithm 0 permits any node to overwrite
<t>1: Strict Shortest Path First (SPF) algorithm based on link m the SPF path with a different path based on its local policy. If
etric. the SR-Algorithm TLV is advertised, Algorithm 0
The algorithm is identical to Algorithm 0 but Algorithm 1 requir <bcp14>MUST</bcp14> be included.</dd>
es that <dt pn="section-3.1-6.1.1.6.2.3">1:</dt>
<dd pn="section-3.1-6.1.1.6.2.4">Strict Shortest Path First (S
PF) algorithm based on link metric.
The algorithm is identical to Algorithm 0, but Algorithm 1 requi
res that
all nodes along the path will honor the SPF routing decision. Lo cal policy all nodes along the path will honor the SPF routing decision. Lo cal policy
at the node claiming support for Algorithm 1 MUST NOT alter the at the node claiming support for Algorithm 1 <bcp14>MUST NOT</bc
SPF paths computed by Algorithm 1.</t> p14> alter the
SPF paths computed by Algorithm 1.</dd>
</list></t> </dl>
</list></t> </dd>
</dl>
<t>When multiple SR-Algorithm TLVs are received from a given router, the </li>
receiver </ul>
MUST use the first occurrence of the TLV in the Router Information LSA. <t pn="section-3.1-7">When multiple SR-Algorithm TLVs are received from
If a given router,
the SR-Algorithm TLV appears in multiple Router Information LSAs that ha the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in
ve the Router
different flooding scopes, the SR-Algorithm TLV in the Router Informatio Information Opaque LSA. If the SR-Algorithm TLV appears in multiple Rout
n LSA er
with the area-scoped flooding scope MUST be used. If the SR-Algorithm TL Information Opaque LSAs that have different flooding scopes, the SR-Algo
V appears rithm
in multiple Router Information LSAs that have the same flooding scope, t TLV in the Router Information Opaque LSA with the area-scoped flooding s
he cope
SR-Algorithm TLV in the Router Information (RI) LSA with the numerically <bcp14>MUST</bcp14> be used. If the SR-Algorithm TLV appears in multiple
smallest Router
Instance ID MUST be used and subsequent instances of the SR-Algorithm TL Information Opaque LSAs that have the same flooding scope, the SR-Algori
V thm
MUST be ignored.</t> TLV in the Router Information (RI) Opaque LSA with the numerically small
est
<t>The RI LSA can be advertised at any of the defined opaque flooding Instance ID <bcp14>MUST</bcp14> be used and subsequent instances of the
SR-Algorithm
TLV <bcp14>MUST</bcp14> be ignored.</t>
<t pn="section-3.1-8">The RI LSA can be advertised at any of the defined
opaque flooding
scopes (link, area, or Autonomous System (AS)). For the purpose of scopes (link, area, or Autonomous System (AS)). For the purpose of
SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED.</t> SR-Algorithm TLV advertisement, area-scoped flooding is <bcp14>REQUIRED< /bcp14>.</t>
</section> </section>
<section anchor="SIDRANGE" numbered="true" toc="include" removeInRFC="fals
<section anchor="SIDRANGE" title="SID/Label Range TLV"> e" pn="section-3.2">
<name slugifiedName="name-sid-label-range-tlv">SID/Label Range TLV</name
<t>Prefix SIDs MAY be advertised in a form of an index as described in >
<xref target="PREFIXSID"/>. Such index defines the offset in the SID/Lab <t pn="section-3.2-1">Prefix-SIDs <bcp14>MAY</bcp14> be advertised in th
el space e form of an index as described in
<xref target="PREFIXSID" format="default" sectionFormat="of" derivedCont
ent="Section 5"/>. Such an index defines the offset in the SID/Label space
advertised by the router. The SID/Label Range TLV is used to advertise s uch SID/Label advertised by the router. The SID/Label Range TLV is used to advertise s uch SID/Label
space.</t> space.</t>
<t pn="section-3.2-2">The SID/Label Range TLV is a top-level TLV of the
<t>The SID/Label Range TLV is a top-level TLV of the Router Information Router Information
Opaque LSA (defined in <xref target="RFC7770"/>).</t> Opaque LSA (defined in <xref target="RFC7770" format="default" sectionFo
rmat="of" derivedContent="RFC7770"/>).</t>
<t>The SID/Label Range TLV MAY appear multiple times and has the followi <t pn="section-3.2-3">The SID/Label Range TLV <bcp14>MAY</bcp14> appear
ng multiple times and has the following
format:<figure> format:</t>
<artwork> <artwork name="" type="" align="left" alt="" pn="section-3.2-4">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size | Reserved | | Range Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+- -+ +- -+
| | | |
+ + + +</artwork>
<t pn="section-3.2-5">where:</t>
where:</artwork> <ul empty="true" bare="false" spacing="normal" pn="section-3.2-6">
</figure><list style="hanging"> <li pn="section-3.2-6.1">
<t>Type: 9</t> <dl newline="false" spacing="normal" pn="section-3.2-6.1.1">
<dt pn="section-3.2-6.1.1.1">Type:</dt>
<t>Length: Variable, in octets, dependent on Sub-TLVs.</t> <dd pn="section-3.2-6.1.1.2">9</dd>
<dt pn="section-3.2-6.1.1.3">Length:</dt>
<t>Range Size: 3-octet SID/label range size (i.e., the number of SID <dd pn="section-3.2-6.1.1.4">Variable, in octets, depending on the
s or labels sub-TLVs</dd>
in the range including the first SID/label). It MUST be greater t <dt pn="section-3.2-6.1.1.5">Range Size:</dt>
han 0.</t> <dd pn="section-3.2-6.1.1.6">3-octet SID/label range size (i.e., t
he number of SIDs or labels
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored in the range including the first SID/label). It <bcp14>MUST</bcp1
on reception.</t> 4> be greater than 0.</dd>
</list></t> <dt pn="section-3.2-6.1.1.7">Reserved:</dt>
<dd pn="section-3.2-6.1.1.8">
<t>Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as def <bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUS
ined T</bcp14> be ignored on reception</dd>
in <xref target="SIDLABEL"/>. The SID/Label Sub-TLV MUST be included </dl>
</li>
</ul>
<t pn="section-3.2-7">Initially, the only supported sub-TLV is the SID/L
abel Sub-TLV as defined
in <xref target="SIDLABEL" format="default" sectionFormat="of" derivedCo
ntent="Section 2.1"/>. The SID/Label Sub-TLV <bcp14>MUST</bcp14> be included
in the SID/Label Range TLV. The SID/Label advertised in the SID/Label Su b-TLV in the SID/Label Range TLV. The SID/Label advertised in the SID/Label Su b-TLV
represents the first SID/Label in the advertised range. </t> represents the first SID/Label in the advertised range. </t>
<t pn="section-3.2-8">Only a single SID/Label Sub-TLV <bcp14>MAY</bcp14>
<t>Only a single SID/Label Sub-TLV MAY be advertised in SID/Label Range be advertised in the SID/Label Range TLV. If more
TLV. If more than one SID/Label Sub-TLV is present, the SID/Label Range TLV <bcp14>MU
then one SID/Label Sub-TLVs are present, the SID/Label Range TLV MUST be ST</bcp14> be ignored.</t>
ignored.</t> <t pn="section-3.2-9">Multiple occurrences of the SID/Label Range TLV <b
cp14>MAY</bcp14> be
<t>Multiple occurrences of the SID/Label Range TLV MAY be advertised in order to advertise multiple ranges. In such a case:</t>
advertised, in order to advertise multiple ranges. In such case:<list <ul spacing="normal" bare="false" empty="false" pn="section-3.2-10">
style="symbols"> <li pn="section-3.2-10.1">The originating router <bcp14>MUST</bcp14> e
ncode each range into a different SID/Label
<t>The originating router MUST encode each range into a different SI Range TLV. </li>
D/Label <li pn="section-3.2-10.2">The originating router decides the order in
Range TLV. </t> which the set of SID/Label
<t>The originating router decides the order in which the set of SID/
Label
Range TLVs are advertised inside the Router Information Opaque LSA. The Range TLVs are advertised inside the Router Information Opaque LSA. The
originating router MUST ensure the order is the same after a gracefu originating router <bcp14>MUST</bcp14> ensure the order is the same
l restart after a graceful restart
(using checkpointing, non-volatile storage, or any other mechanism) (using checkpointing, nonvolatile storage, or any other mechanism) i
in order n order
to assure the SID/label range and SID index correspondence is preser to ensure the SID/Label range and SID index correspondence is preser
ved ved
across graceful restarts.</t> across graceful restarts.</li>
<li pn="section-3.2-10.3"> The receiving router <bcp14>MUST</bcp14> ad
<t> The receiving router MUST adhere to the order in which the range here to the order in which the ranges are
s are advertised when calculating a SID/Label from a SID index.</li>
advertised when calculating a SID/label from a SID index.</t> <li pn="section-3.2-10.4">The originating router <bcp14>MUST NOT</bcp1
4> advertise overlapping ranges.</li>
<t>The originating router MUST NOT advertise overlapping ranges.</t> <li pn="section-3.2-10.5">When a router receives multiple overlapping
ranges, it <bcp14>MUST</bcp14> conform
<t>When a router receives multiple overlapping ranges, it MUST confo to the procedures defined in <xref target="RFC8660" format="defau
rm lt" sectionFormat="of" derivedContent="RFC8660"/>.</li>
to the procedures defined in <xref target="I-D.ietf-spring-segmen </ul>
t-routing-mpls"/>.</t> <t pn="section-3.2-11">The following example illustrates the advertiseme
</list></t> nt of multiple ranges.</t>
<t pn="section-3.2-12">The originating router advertises the following r
<t>The following example illustrates the advertisement of multiple range anges:</t>
s:<figure <artwork name="" type="" align="left" alt="" pn="section-3.2-13">
suppress-title="true">
<artwork>
The originating router advertises the following ranges:
Range 1: Range Size: 100 SID/Label Sub-TLV: 100 Range 1: Range Size: 100 SID/Label Sub-TLV: 100
Range 1: Range Size: 100 SID/Label Sub-TLV: 1000 Range 1: Range Size: 100 SID/Label Sub-TLV: 1000
Range 1: Range Size: 100 SID/Label Sub-TLV: 500 Range 1: Range Size: 100 SID/Label Sub-TLV: 500</artwork>
<t pn="section-3.2-14">The receiving routers concatenate the ranges and
The receiving routers concatenate the ranges and build the Segment build the Segment
Routing Global Block (SRGB) as follows: Routing Global Block (SRGB) as follows:</t>
<artwork name="" type="" align="left" alt="" pn="section-3.2-15">
SRGB = [100, 199] SRGB = [100, 199]
[1000, 1099] [1000, 1099]
[500, 599] [500, 599]</artwork>
<t pn="section-3.2-16">The indexes span multiple ranges:</t>
The indexes span multiple ranges: <artwork name="" type="" align="left" alt="" pn="section-3.2-17">
index 0 means label 100
index=0 means label 100
... ...
index 99 means label 199 index 99 means label 199
index 100 means label 1000 index 100 means label 1000
index 199 means label 1099 index 199 means label 1099
... ...
index 200 means label 500 index 200 means label 500
... ...</artwork>
</artwork> <t pn="section-3.2-18">The RI LSA can be advertised at any of the define
</figure></t> d flooding scopes
<t>The RI LSA can be advertised at any of the defined flooding scopes
(link, area, or autonomous system (AS)). For the purpose of (link, area, or autonomous system (AS)). For the purpose of
SID/Label Range TLV advertisement, area-scoped flooding is REQUIRED.</t> SID/Label Range TLV advertisement, area-scoped flooding is <bcp14>REQUIR ED</bcp14>.</t>
</section> </section>
<section anchor="SRLB" numbered="true" toc="include" removeInRFC="false" p
<section anchor="SRLB" title="SR Local Block TLV"> n="section-3.3">
<name slugifiedName="name-sr-local-block-tlv">SR Local Block TLV</name>
<t>The SR Local Block TLV (SRLB TLV) contains the range of labels the <t pn="section-3.3-1">The SR Local Block TLV (SRLB TLV) contains the ran
node has reserved for local SIDs. SIDs from the SRLB MAY be used ge of labels the
for node has reserved for Local SIDs. SIDs from the SRLB <bcp14>MAY</
Adjacency-SIDs, but also by components other than the OSPF protoc bcp14> be used for
ol. Adjacency SIDs but also by components other than the OSPF protoco
l.
As an example, an application or a controller can instruct the ro uter As an example, an application or a controller can instruct the ro uter
to allocate a specific local SID. Some controllers or application to allocate a specific Local SID. Some controllers or application
s can s can
use the control plane to discover the available set of local SIDs use the control plane to discover the available set of Local SIDs
on on
a particular router. In such cases, the SRLB is advertised in the control plane. a particular router. In such cases, the SRLB is advertised in the control plane.
The requirement to advertise the SRLB is further described in The requirement to advertise the SRLB is further described in
<xref target="I-D.ietf-spring-segment-routing-mpls"/>. <xref target="RFC8660" format="default" sectionFormat="of" derive dContent="RFC8660"/>.
The SRLB TLV is used to advertise the SRLB.</t> The SRLB TLV is used to advertise the SRLB.</t>
<t pn="section-3.3-2">The SRLB TLV is a top-level TLV of the Router Info
<t>The SRLB TLV is a top-level TLV of the Router Information rmation
Opaque LSA (defined in <xref target="RFC7770"/>).</t> Opaque LSA (defined in <xref target="RFC7770" format="default" sectionFo
rmat="of" derivedContent="RFC7770"/>).</t>
<t>The SRLB TLV MAY appear multiple times in the Router Information <t pn="section-3.3-3">The SRLB TLV <bcp14>MAY</bcp14> appear multiple ti
Opaque LSA and has the following format:<figure> mes in the Router Information
<artwork> Opaque LSA and has the following format:</t>
<artwork name="" type="" align="left" alt="" pn="section-3.3-4">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size | Reserved | | Range Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+- -+ +- -+
| | | |
+ + + +</artwork>
<t pn="section-3.3-5">where:</t>
where:</artwork> <ul empty="true" bare="false" spacing="normal" pn="section-3.3-6">
</figure> <li pn="section-3.3-6.1">
<list style="hanging"> <dl newline="false" spacing="normal" pn="section-3.3-6.1.1">
<t>Type: 14</t> <dt pn="section-3.3-6.1.1.1">Type:</dt>
<dd pn="section-3.3-6.1.1.2">14</dd>
<t>Length: Variable, in octets, dependent on Sub-TLVs.</t> <dt pn="section-3.3-6.1.1.3">Length:</dt>
<dd pn="section-3.3-6.1.1.4">Variable, in octets, depending on the
<t>Range Size: 3-octet SID/label range size (i.e., the number of SID sub-TLVs</dd>
s or labels <dt pn="section-3.3-6.1.1.5">Range Size:</dt>
in the range including the first SID/label). It MUST be greater t <dd pn="section-3.3-6.1.1.6">3-octet SID/Label range size (i.e., t
han 0.</t> he number of SIDs or labels
in the range including the first SID/Label). It <bcp14>MUST</bcp1
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored 4> be greater than 0.</dd>
on reception.</t> <dt pn="section-3.3-6.1.1.7">Reserved:</dt>
</list></t> <dd pn="section-3.3-6.1.1.8">
<bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUS
<t>Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as def T</bcp14> be ignored on reception</dd>
ined </dl>
in <xref target="SIDLABEL"/>. The SID/Label Sub-TLV MUST be included </li>
</ul>
<t pn="section-3.3-7">Initially, the only supported sub-TLV is the SID/L
abel Sub-TLV as defined
in <xref target="SIDLABEL" format="default" sectionFormat="of" derivedCo
ntent="Section 2.1"/>. The SID/Label Sub-TLV <bcp14>MUST</bcp14> be included
in the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV repre sents in the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV repre sents
the first SID/Label in the advertised range.</t> the first SID/Label in the advertised range.</t>
<t pn="section-3.3-8">Only a single SID/Label Sub-TLV <bcp14>MAY</bcp14>
<t>Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. If be advertised in the SRLB TLV. If more
more than one SID/Label Sub-TLV is present, the SRLB TLV <bcp14>MUST</bcp14>
then one SID/Label Sub-TLVs are present, the SRLB TLV MUST be ignored.</ be ignored.</t>
t> <t pn="section-3.3-9">The originating router <bcp14>MUST NOT</bcp14> adv
ertise overlapping ranges.</t>
<t>The originating router MUST NOT advertise overlapping ranges.</t> <t pn="section-3.3-10">Each time a SID from the SRLB is allocated, it <b
cp14>SHOULD</bcp14> also be reported to all
<t>Each time a SID from the SRLB is allocated, it SHOULD also be reporte
d to all
components (e.g., controller or applications) in order for these components to components (e.g., controller or applications) in order for these components to
have an up-to-date view of the current SRLB allocation. This is r equired to avoid have an up-to-date view of the current SRLB allocation. This is r equired to avoid
collisions between allocation instructions.</t> collisions between allocation instructions.</t>
<t pn="section-3.3-11">Within the context of OSPF, the reporting of Loca
<t>Within the context of OSPF, the reporting of local SIDs is don l SIDs is done through
e through OSPF sub-TLVs, such as the Adjacency SID (<xref target="ADJSID" f
OSPF Sub-TLVs such as the Adjacency-SID (<xref target="ADJSID"/>) ormat="default" sectionFormat="of" derivedContent="Section 6"/>). However,
. However, the reporting of allocated Local SIDs can also be done through ot
the reporting of allocated local SIDs can also be done through ot her means
her means and protocols, which are outside the scope of this document.</t>
and protocols which are outside the scope of this document.</t> <t pn="section-3.3-12">A router advertising the SRLB TLV <bcp14>MAY</bcp
14> also have other label ranges, outside
<t>A router advertising the SRLB TLV MAY also have other label ra of the SRLB, used for its local allocation purposes and not adver
nges, outside tised in
of the SRLB, used for its local allocation purposes which are not the SRLB TLV. For example, it is possible that an Adjacency SID i
advertised in s allocated using
the SRLB TLV. For example, it is possible that an Adjacency-SID i
s allocated using
a local label that is not part of the SRLB.</t> a local label that is not part of the SRLB.</t>
<t pn="section-3.3-13">The RI LSA can be advertised at any of the define
<t>The RI LSA can be advertised at any of the defined flooding scopes d flooding scopes
(link, area, or autonomous system (AS)). For the purpose of (link, area, or autonomous system (AS)). For the purpose of
SRLB TLV advertisement, area-scoped flooding is REQUIRED.</t> SRLB TLV advertisement, area-scoped flooding is <bcp14>REQUIRED</bcp14>
</section> .</t>
</section>
<section anchor="SRMS-Pref" title="SRMS Preference TLV"> <section anchor="SRMS-Pref" numbered="true" toc="include" removeInRFC="fal
se" pn="section-3.4">
<t>The Segment Routing Mapping Server Preference TLV (SRMS Preference TLV) <name slugifiedName="name-srms-preference-tlv">SRMS Preference TLV</name
is used to >
<t pn="section-3.4-1">The Segment Routing Mapping Server Preference TLV
(SRMS Preference TLV) is used to
advertise a preference associated with the node that acts as an SR Mapping Server. advertise a preference associated with the node that acts as an SR Mapping Server.
The role of an SRMS is described in <xref target="I-D.ietf-spring-segment- routing-ldp-interop"/>. The role of an SRMS is described in <xref target="RFC8661" format="default " sectionFormat="of" derivedContent="RFC8661"/>.
SRMS preference is defined in SRMS preference is defined in
<xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t> <xref target="RFC8661" format="default" sectionFormat="of" derivedContent=
"RFC8661"/>.</t>
<t>The SRMS Preference TLV is a top-level TLV of the <t pn="section-3.4-2">The SRMS Preference TLV is a top-level TLV of the
Router Information Opaque LSA (defined in <xref target="RFC7770"/>).</t> Router Information Opaque LSA (defined in <xref target="RFC7770" format="d
efault" sectionFormat="of" derivedContent="RFC7770"/>).</t>
<t>The SRMS Preference TLV MAY only be advertised <t pn="section-3.4-3">The SRMS Preference TLV <bcp14>MAY</bcp14> only be
once in the Router Information Opaque LSA and has the following format: advertised
<figure> once in the Router Information Opaque LSA and has the following format:
<artwork> </t>
<artwork name="" type="" align="left" alt="" pn="section-3.4-4">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | Reserved | | Preference | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
<t pn="section-3.4-5">where:</t>
where:</artwork> <ul empty="true" bare="false" spacing="normal" pn="section-3.4-6">
</figure> <li pn="section-3.4-6.1">
<list style="hanging"> <dl newline="false" spacing="normal" pn="section-3.4-6.1.1">
<t>Type: 15</t> <dt pn="section-3.4-6.1.1.1">Type:</dt>
<dd pn="section-3.4-6.1.1.2">15</dd>
<t>Length: 4 octets</t> <dt pn="section-3.4-6.1.1.3">Length:</dt>
<dd pn="section-3.4-6.1.1.4">4 octets</dd>
<t>Preference: 1 octet. SRMS preference value from 0 to 255.</t> <dt pn="section-3.4-6.1.1.5">Preference:</dt>
<dd pn="section-3.4-6.1.1.6">1 octet, with an SRMS preference valu
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored e from 0 to 255</dd>
on reception.</t> <dt pn="section-3.4-6.1.1.7">Reserved:</dt>
</list></t> <dd pn="section-3.4-6.1.1.8">
<bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUS
<t>When multiple SRMS Preference TLVs are received from a given router, the T</bcp14> be ignored on reception</dd>
receiver </dl>
MUST use the first occurrence of the TLV in the Router Information LSA. If t </li>
he </ul>
SRMS Preference TLV appears in multiple Router Information LSAs that have di <t pn="section-3.4-7">When multiple SRMS Preference TLVs are received fr
fferent om a given router, the receiver
flooding scopes, the SRMS Preference TLV in the Router Information LSA with <bcp14>MUST</bcp14> use the first occurrence of the TLV in the Router
the Information Opaque LSA. If the
narrowest flooding scope MUST be used. If the SRMS Preference TLV appears in SRMS Preference TLV appears in multiple Router Information Opaque LSAs that
multiple Router Information LSAs that have the same flooding scope, the SRMS have different
Preference TLV in the Router Information LSA with the numerically smallest I flooding scopes, the SRMS Preference TLV in the Router Information Opaque LS
nstance ID A with the
MUST be used and subsequent instances of the SRMS Preference TLV MUST be ign narrowest flooding scope <bcp14>MUST</bcp14> be used. If the SRMS Preference
ored.</t> TLV appears in
multiple Router Information Opaque LSAs that have the same flooding scope, t
<t>The RI LSA can be advertised at any of the defined flooding scopes (li he SRMS
nk, area, Preference TLV in the Router Information Opaque LSA with the numerically sma
llest Instance ID
<bcp14>MUST</bcp14> be used and subsequent instances of the SRMS Preference
TLV <bcp14>MUST</bcp14> be ignored.</t>
<t pn="section-3.4-8">The RI LSA can be advertised at any of the defined
flooding scopes (link, area,
or autonomous system (AS)). For the purpose of the SRMS or autonomous system (AS)). For the purpose of the SRMS
Preference TLV advertisement, AS-scoped flooding SHOULD be used. This is Preference TLV advertisement, AS-scoped flooding <bcp14>SHOULD</bcp14> be
because SRMS used. This is because SRMS
servers can be located in a different area then consumers of the SRMS adv servers can be located in a different area than consumers of the SRMS adv
ertisements. ertisements.
If the SRMS advertisements from the SRMS server are only used inside the SRMS server's If the SRMS advertisements from the SRMS server are only used inside the SRMS server's
area, area-scoped flooding MAY be used.</t> area, area-scoped flooding <bcp14>MAY</bcp14> be used.</t>
</section>
</section> </section>
<section anchor="PFXRANGE" numbered="true" toc="include" removeInRFC="false"
</section> pn="section-4">
<name slugifiedName="name-ospf-extended-prefix-range-">OSPF Extended Prefi
<section anchor="PFXRANGE" title="OSPF Extended Prefix Range TLV"> x Range TLV</name>
<t>In some cases it is useful to advertise attributes for a range of prefi <t pn="section-4-1">In some cases, it is useful to advertise attributes fo
xes. r a range of
The Segment Routing Mapping Server, which is described in prefixes. The SR Mapping Server, which is described in <xref target="RFC8
<xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>, is an exa 661" format="default" sectionFormat="of" derivedContent="RFC8661"/>, is an examp
mple le where we need a
where we need a single advertisement to advertise SIDs for multiple pre single advertisement to advertise SIDs for multiple prefixes from a
fixes from a contiguous address range.</t>
contiguous address range.</t> <t pn="section-4-2">The OSPF Extended Prefix Range TLV, which is a top-lev
el TLV of the
<t>The OSPF Extended Prefix Range TLV, which is a top level TLV of the Ext Extended Prefix LSA described in <xref target="RFC7684" format="default" s
ended ectionFormat="of" derivedContent="RFC7684"/> is defined for this purpose.</t>
Prefix LSA described in <xref target="RFC7684"/> is defined for this purpo <t pn="section-4-3">Multiple OSPF Extended Prefix Range TLVs <bcp14>MAY</b
se.</t> cp14> be
advertised in each OSPF Extended Prefix Opaque LSA, but all prefix
<t>Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each OSPF ranges included in a single OSPF Extended Prefix Opaque LSA
Extended Prefix Opaque LSA, but all prefix ranges included in a single OSP <bcp14>MUST</bcp14> have the same flooding scope. The OSPF Extended
F Extended Prefix Range TLV has the following format:</t>
Prefix Opaque LSA MUST have the same flooding scope. The OSPF Extended Pre <artwork name="" type="" align="left" alt="" pn="section-4-4">
fix Range
TLV has the following format: <figure>
<artwork>
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | AF | Range Size | | Prefix Length | AF | Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+- -+ +- -+
| | | |
</artwork>
where: </artwork> <t pn="section-4-5">where:</t>
</figure><list style="hanging"> <ul empty="true" bare="false" spacing="normal" pn="section-4-6">
<t>Type: 2</t> <li pn="section-4-6.1">
<dl newline="false" spacing="normal" pn="section-4-6.1.1">
<t>Length: Variable, in octets, dependent on Sub-TLVs.</t> <dt pn="section-4-6.1.1.1">Type:</dt>
<dd pn="section-4-6.1.1.2">2</dd>
<t>Prefix length: Length of prefix in bits.</t> <dt pn="section-4-6.1.1.3">Length:</dt>
<dd pn="section-4-6.1.1.4">Variable, in octets, depending on the sub
<t>AF: Address family for the prefix. Currently, the only supported -TLVs</dd>
value is 0 for IPv4 unicast. The inclusion of address family in <dt pn="section-4-6.1.1.5">Prefix Length:</dt>
this TLV allows for future extension.</t> <dd pn="section-4-6.1.1.6">Length of prefix in bits</dd>
<dt pn="section-4-6.1.1.7">AF:</dt>
<t>Range size: Represents the number of prefixes that are covered by <dd pn="section-4-6.1.1.8">Address family for the prefix. Currently
the , the only supported
advertisement. The Range Size MUST NOT exceed the number of value is 0 for IPv4 unicast. The inclusion of address family in this
prefixes that could be satisfied by the prefix length wit TLV allows for future extension.</dd>
hout <dt pn="section-4-6.1.1.9">Range Size:</dt>
including the IPv4 multicast address range (224.0.0.0/3). <dd pn="section-4-6.1.1.10">Represents the number of prefixes that a
</t> re covered by the
advertisement. The Range Size <bcp14>MUST NOT</bcp14> exceed the
<t>Flags: Single octet field. The following flags are def number of prefixes that could be satisfied by the Prefix Length
ined: <figure without including the IPv4 multicast address range (224.0.0.0/3).</dd>
align="center"> <dt pn="section-4-6.1.1.11">Flags:</dt>
<artwork> <dd pn="section-4-6.1.1.12">
<t pn="section-4-6.1.1.12.1">Single-octet field. The following fla
0 1 2 3 4 5 6 7 gs are defined:</t>
+--+--+--+--+--+--+--+--+ <artwork name="" type="" align="left" alt="" pn="section-4-6.1.1.1
|IA| | | | | | | | 2.2">
+--+--+--+--+--+--+--+--+ 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
where:</artwork> |IA| | | | | | | |
</figure><list style="hanging"> +--+--+--+--+--+--+--+--+</artwork>
<t>IA-Flag: Inter-Area flag. If set, advertisement is of inter-a <t pn="section-4-6.1.1.12.3">where:</t>
rea type. <ul empty="true" bare="false" spacing="normal" pn="section-4-6.1.1
An ABR that is advertising the OSPF Extended Prefix Range TLV be .12.4">
tween areas <li pn="section-4-6.1.1.12.4.1">
MUST set this bit. </t> <dl newline="false" spacing="normal" pn="section-4-6.1.1.12.4.
1.1">
<t>This bit is used to prevent redundant flooding of Prefix Rang <dt pn="section-4-6.1.1.12.4.1.1.1">IA-Flag:</dt>
e TLVs <dd pn="section-4-6.1.1.12.4.1.1.2">
between areas as follows: <t pn="section-4-6.1.1.12.4.1.1.2.1">Inter-Area Flag. If s
<list style="hanging"> et, advertisement is of
inter-area type. An Area Border Router (ABR) that is
<t> An ABR only propagates an inter-area Prefix Range advertisem advertising the OSPF Extended Prefix Range TLV between areas
ent from <bcp14>MUST</bcp14> set this bit.
the backbone area to connected non-backbone areas if the adverti </t>
sement <t pn="section-4-6.1.1.12.4.1.1.2.2">This bit is used to p
is considered to be the best one. The following rules are used t revent redundant flooding of Prefix
o select the Range TLVs between areas as follows:</t>
best range from the set of advertisements for the same Prefix R <ul empty="true" bare="false" spacing="normal" pn="section
ange: -4-6.1.1.12.4.1.1.2.3">
<list style="hanging"> <li pn="section-4-6.1.1.12.4.1.1.2.3.1">
<t pn="section-4-6.1.1.12.4.1.1.2.3.1.1">
<t> An ABR always prefers intra-area Prefix Range advertisem An ABR only propagates an inter-area Prefix Range
ents over advertisement from the backbone area to connected
inter-area advertisements.</t> nonbackbone areas if the advertisement is considered
to be the best one. The following rules are used to
<t> An ABR does not consider inter-area Prefix Range adverti select the best range from the set of advertisements
sements coming for the same Prefix Range:</t>
from non-backbone areas.</t> <ul empty="true" bare="false" spacing="normal" pn="sec
tion-4-6.1.1.12.4.1.1.2.3.1.2">
</list></t> <li pn="section-4-6.1.1.12.4.1.1.2.3.1.2.1">An ABR a
</list></t> lways prefers intra-area Prefix Range
</list></t> advertisements over inter-area advertisements.</li>
<li pn="section-4-6.1.1.12.4.1.1.2.3.1.2.2">An ABR d
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored oes not consider inter-area Prefix Range
on reception.</t> advertisements coming from nonbackbone areas.</li>
</ul>
<t>Address Prefix: For the address family IPv4 unicast, the prefix i </li>
tself is </ul>
encoded as a 32-bit value. The default route is represented by a </dd>
prefix of </dl>
length 0. Prefix encoding for other address families is beyond th </li>
e scope of </ul>
this specification.</t> </dd>
</list></t> <dt pn="section-4-6.1.1.13">Reserved:</dt>
<dd pn="section-4-6.1.1.14">
<bcp14>SHOULD</bcp14> be set to 0 on transmission and
<bcp14>MUST</bcp14> be ignored on reception</dd>
<dt pn="section-4-6.1.1.15">Address Prefix:</dt>
<dd pn="section-4-6.1.1.16">For the address family IPv4 unicast, the
prefix itself is
encoded as a 32-bit value. The default route is represented by
a prefix of length 0. Prefix encoding for other address
families is beyond the scope of this specification.</dd>
</dl>
</li>
</ul>
</section> </section>
<section anchor="PREFIXSID" numbered="true" toc="include" removeInRFC="false
<section anchor="PREFIXSID" title="Prefix SID Sub-TLV"> " pn="section-5">
<t>The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV des <name slugifiedName="name-prefix-sid-sub-tlv">Prefix-SID Sub-TLV</name>
cribed <t pn="section-5-1">The Prefix-SID Sub-TLV is a sub-TLV of the OSPF Extend
in <xref target="RFC7684"/> and the OSPF Extended Prefix Range ed Prefix TLV described
TLV described in <xref target="PFXRANGE"/>. It MAY appear more than once i in <xref target="RFC7684" format="default" sectionFormat="of" derivedConte
n the nt="RFC7684"/> and the OSPF Extended Prefix Range
parent TLV and has the following format: <figure> TLV described in <xref target="PFXRANGE" format="default" sectionFormat="o
<artwork> f" derivedContent="Section 4"/>. It <bcp14>MAY</bcp14> appear more than once in
the
parent TLV and has the following format: </t>
<artwork name="" type="" align="left" alt="" pn="section-5-2">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | MT-ID | Algorithm | | Flags | Reserved | MT-ID | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) | | SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
<t pn="section-5-3">where:</t>
where:</artwork> <ul empty="true" bare="false" spacing="normal" pn="section-5-4">
</figure><list style="hanging"> <li pn="section-5-4.1">
<t>Type: 2</t> <dl newline="false" spacing="normal" pn="section-5-4.1.1">
<dt pn="section-5-4.1.1.1">Type:</dt>
<t>Length: 7 or 8 octets, dependent on the V-flag</t> <dd pn="section-5-4.1.1.2">2</dd>
<dt pn="section-5-4.1.1.3">Length:</dt>
<t>Flags: Single octet field. The following flags are defined: <figu <dd pn="section-5-4.1.1.4">7 or 8 octets, depending on the V-Flag</d
re d>
align="center"> <dt pn="section-5-4.1.1.5">Flags:</dt>
<artwork> <dd pn="section-5-4.1.1.6">
<t pn="section-5-4.1.1.6.1">Single-octet field. The following flag
0 1 2 3 4 5 6 7 s are defined: </t>
+--+--+--+--+--+--+--+--+ <artwork name="" type="" align="left" alt="" pn="section-5-4.1.1.6
| |NP|M |E |V |L | | | .2">
+--+--+--+--+--+--+--+--+ 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
where:</artwork> | |NP|M |E |V |L | | |
</figure><list style="hanging"> +--+--+--+--+--+--+--+--+</artwork>
<t pn="section-5-4.1.1.6.3">where:</t>
<t>NP-Flag: No-PHP flag. If set, then the penultimate hop MUST <ul empty="true" bare="false" spacing="normal" pn="section-5-4.1.1
NOT pop the Prefix-SID before delivering packets to the .6.4">
node that advertised the Prefix-SID.</t> <li pn="section-5-4.1.1.6.4.1">
<dl newline="false" spacing="normal" pn="section-5-4.1.1.6.4.1
<t>M-Flag: Mapping Server Flag. If set, the SID was advertised .1">
by a Segment Routing Mapping Server as described in <dt pn="section-5-4.1.1.6.4.1.1.1">NP-Flag:</dt>
<xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t <dd pn="section-5-4.1.1.6.4.1.1.2">No-PHP (Penultimate Hop P
> opping) Flag. If set, then the
penultimate hop <bcp14>MUST NOT</bcp14> pop the Prefix-SID before
<t>E-Flag: Explicit-Null Flag. If set, any upstream neighbor delivering packets to the node that advertised the
of the Prefix-SID originator MUST replace the Prefix-SID with Prefix-SID.</dd>
the Explicit-NULL label (0 for IPv4) before forwarding the packe <dt pn="section-5-4.1.1.6.4.1.1.3">M-Flag:</dt>
t.</t> <dd pn="section-5-4.1.1.6.4.1.1.4">Mapping Server Flag. If
set, the SID was advertised
<t>V-Flag: Value/Index Flag. If set, then the Prefix-SID by an SR Mapping Server as described in
<xref target="RFC8661" format="default" sectionFormat="of" deriv
edContent="RFC8661"/>.</dd>
<dt pn="section-5-4.1.1.6.4.1.1.5">E-Flag:</dt>
<dd pn="section-5-4.1.1.6.4.1.1.6">Explicit Null Flag. If se
t, any upstream neighbor of the
Prefix-SID originator <bcp14>MUST</bcp14> replace the Prefix-SID
with the Explicit NULL label (0 for IPv4) before forwarding the
packet.</dd>
<dt pn="section-5-4.1.1.6.4.1.1.7">V-Flag:</dt>
<dd pn="section-5-4.1.1.6.4.1.1.8">Value/Index Flag. If set,
then the Prefix-SID
carries an absolute value. If not set, then the Prefix-SID carri es carries an absolute value. If not set, then the Prefix-SID carri es
an index.</t> an index.</dd>
<dt pn="section-5-4.1.1.6.4.1.1.9">L-Flag:</dt>
<t>L-Flag: Local/Global Flag. If set, then the value/index <dd pn="section-5-4.1.1.6.4.1.1.10">Local/Global Flag. If se
t, then the value/index
carried by the Prefix-SID has local significance. If not set, th en carried by the Prefix-SID has local significance. If not set, th en
the value/index carried by this Sub-TLV has global significance. the value/index carried by this sub-TLV has global significance.
</t> </dd>
<dt pn="section-5-4.1.1.6.4.1.1.11">Other bits:</dt>
<t>Other bits: Reserved. These MUST be zero when sent and are ig <dd pn="section-5-4.1.1.6.4.1.1.12">Reserved. These <bcp14>M
nored when UST</bcp14> be zero when sent and are
received.</t> ignored when received.</dd>
</list></t> </dl>
</li>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored </ul>
on reception.</t> </dd>
<dt pn="section-5-4.1.1.7">Reserved:</dt>
<t>MT-ID: Multi-Topology ID (as defined in <xref <dd pn="section-5-4.1.1.8">
target="RFC4915"/>).</t> <bcp14>SHOULD</bcp14> be set to 0 on transmission and
<bcp14>MUST</bcp14> be ignored on reception</dd>
<t>Algorithm: Single octet identifying the algorithm the Prefix-SID <dt pn="section-5-4.1.1.9">MT-ID:</dt>
is associated with as defined in <xref target="SRALGO"/>.</t> <dd pn="section-5-4.1.1.10">Multi-Topology ID (as defined in <xref t
arget="RFC4915" format="default" sectionFormat="of" derivedContent="RFC4915"/>)<
<t>A router receiving a Prefix-SID from a remote node and with an a /dd>
lgorithm <dt pn="section-5-4.1.1.11">Algorithm:</dt>
value that such remote node has not advertised in the SR-Algorithm S <dd pn="section-5-4.1.1.12">
ub-TLV <t pn="section-5-4.1.1.12.1">Single octet identifying the algorith
(<xref target="SRALGO"/>) MUST ignore the Prefix-SID Sub-TLV.</t> m the Prefix-SID is
associated with as defined in <xref target="SRALGO" format="default" sec
<t>SID/Index/Label: According to the V and L flags, it contains: tionFormat="of" derivedContent="Section 3.1"/></t>
<list style="hanging"> <t pn="section-5-4.1.1.12.2">A router receiving a Prefix-SID from
a remote node and with an
<t>V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label fi algorithm value that the remote node has not advertised in the
eld SR-Algorithm TLV (<xref target="SRALGO" format="default" sectionFormat="
is a 4 octet index defining the offset in the SID/Labe of" derivedContent="Section 3.1"/>)
l space <bcp14>MUST</bcp14> ignore the Prefix-SID Sub-TLV.</t>
advertised by this router</t> </dd>
<dt pn="section-5-4.1.1.13">SID/Index/Label:</dt>
<t>V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label fi <dd pn="section-5-4.1.1.14">
eld <t pn="section-5-4.1.1.14.1">According to the V- and L-Flags, it c
is a 3 octet local label where the 20 rightmost bits a ontains:
re used for </t>
encoding the label value.</t> <ul empty="true" bare="false" spacing="normal" pn="section-5-4.1.1
.14.2">
<t>All other combinations of V-flag and L-flag are invalid and any S <li pn="section-5-4.1.1.14.2.1">V-Flag is set to 0 and L-Flag is
ID set to 0: The SID/Index/Label
advertisement received with an invalid setting for V a field is a 4-octet index defining the offset in the SID/Label
nd L flags MUST space advertised by this router.</li>
be ignored.</t> <li pn="section-5-4.1.1.14.2.2">V-Flag is set to 1 and L-Flag is
</list></t> set to 1: The SID/Index/Label
field is a 3-octet local label where the 20 rightmost bits are
</list></t> used for encoding the label value.</li>
<li pn="section-5-4.1.1.14.2.3">All other combinations of V-Flag
<t>If an OSPF router advertises multiple Prefix-SIDs for the same prefix and L-Flag are invalid and
, any SID Advertisement received with an invalid setting for V- and L-
topology and algorithm, all of them MUST be ignored.</t> Flags <bcp14>MUST</bcp14> be ignored.</li>
</ul>
<t>When calculating the outgoing label for the prefix, the router MUST </dd>
take into account, as described below, the E, NP and M flags advertised </dl>
by the next-hop router if </li>
that router advertised the SID for the prefix. This MUST be done </ul>
<t pn="section-5-5">If an OSPF router advertises multiple Prefix-SIDs for
the same prefix,
topology, and algorithm, all of them <bcp14>MUST</bcp14> be ignored.</t>
<t pn="section-5-6">When calculating the outgoing label for the prefix, th
e router <bcp14>MUST</bcp14>
take into account, as described below, the E-, NP-, and M-Flags advertis
ed by the next-hop router if
that router advertised the SID for the prefix. This <bcp14>MUST</bcp14>
be done
regardless of whether the next-hop router contributes to the best path t o the regardless of whether the next-hop router contributes to the best path t o the
prefix.</t> prefix.</t>
<t pn="section-5-7">The NP-Flag (No-PHP) <bcp14>MUST</bcp14> be set and th
<t>The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Pre e E-Flag
fix-SIDs <bcp14>MUST</bcp14> be clear for Prefix-SIDs
allocated to inter-area prefixes that are originated by the ABR based on intra-area allocated to inter-area prefixes that are originated by the ABR based on intra-area
or inter-area reachability between areas, unless the advertised prefix i s directly or inter-area reachability between areas unless the advertised prefix is directly
attached to the ABR.</t> attached to the ABR.</t>
<t pn="section-5-8">The NP-Flag (No-PHP) <bcp14>MUST</bcp14> be set and th
<t>The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Pre e E-Flag
fix-SIDs <bcp14>MUST</bcp14> be clear for Prefix-SIDs
allocated to redistributed prefixes, unless the redistributed prefix is directly allocated to redistributed prefixes, unless the redistributed prefix is directly
attached to the ASBR.</t> attached to the Autonomous System Boundary Router (ASBR).</t>
<t pn="section-5-9">If the NP-Flag is not set, then:
<t>If the NP-Flag is not set, then any upstream neighbor of the Prefix-S </t>
ID <ul empty="true" bare="false" spacing="normal" pn="section-5-10">
originator MUST pop the Prefix-SID. This is equivalent to the penultimat <li pn="section-5-10.1">Any upstream neighbor of the Prefix-SID originat
e or <bcp14>MUST</bcp14> pop
hop popping mechanism used in the MPLS dataplane. If the NP-flag is not the Prefix-SID. This is equivalent to the penultimate hop-popping mechanism
set, used in the MPLS data plane.
then the received E-flag is ignored.</t> </li>
<li pn="section-5-10.2">The received E-Flag is ignored.
<t>If the NP-flag is set then:<list style="hanging"> </li>
</ul>
<t> If the E-flag is not set, then any upstream neighbor of the Prefix-S <t pn="section-5-11">If the NP-Flag is set and the E-Flag is not set, then
ID :
originator MUST keep the Prefix-SID on top of the stack. This is useful </t>
when <ul empty="true" bare="false" spacing="normal" pn="section-5-12">
the originator of the Prefix-SID need to stitch the incoming packet into <li pn="section-5-12.1">Any upstream neighbor of the Prefix-SID originat
a continuing or <bcp14>MUST</bcp14>
MPLS LSP to the final destination. This could occur at an Area Border Ro keep the Prefix-SID on top of the stack. This is useful when the originator of
uter the Prefix-SID needs to stitch the incoming packet into a continuing MPLS LSP
(prefix propagation from one area to another) or at an AS Boundary Route to the final destination. This could occur at an ABR (prefix propagation from
r one area to another) or at an ASBR (prefix propagation from one
(prefix propagation from one domain to another).</t> domain to another).
</li>
<t>If the E-flag is set, then any upstream neighbor of the Prefix-SID o </ul>
riginator <t pn="section-5-13">If both the NP-Flag and E-Flag are set, then:
MUST replace the Prefix-SID with an Explicit-NULL label. This </t>
is useful, e.g., when the originator of the Prefix-SID is the final des <ul empty="true" bare="false" spacing="normal" pn="section-5-14">
tination <li pn="section-5-14.1">Any upstream neighbor of the Prefix-SID originat
for the related prefix and the originator wishes to receive the packet or <bcp14>MUST</bcp14>
with the replace the Prefix-SID with an Explicit NULL label. This is useful, e.g., when
original EXP bits.</t> the originator of the Prefix-SID is the final destination for the related
</list></t> prefix and the originator wishes to receive the packet with the original EXP
bits.
<t>When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at </li>
reception.</t> </ul>
<t pn="section-5-15">When the M-Flag is set, the NP-Flag and the E-Flag <b
<t>As the Mapping Server does not specify the originator of a prefix adv cp14>MUST</bcp14> be ignored on reception.</t>
ertisement, <t pn="section-5-16">As the Mapping Server does not specify the originator
of a prefix advertisement,
it is not possible to determine PHP behavior solely based on the Mapping Server it is not possible to determine PHP behavior solely based on the Mapping Server
advertisement. However, PHP behavior SHOULD be done in following cases: Advertisement. However, PHP behavior <bcp14>SHOULD</bcp14> be done in th
<list style="hanging"> e following cases:
<t>The Prefix is intra-area type and the downstream neighbor is t </t>
he originator <ul empty="true" bare="false" spacing="normal" pn="section-5-17">
of the prefix.</t> <li pn="section-5-17.1">The Prefix is intra-area type and the downstream
neighbor is the originator
<t>The Prefix is inter-area type and downstream neighbor is an AB of the prefix.</li>
R, which is <li pn="section-5-17.2">The Prefix is inter-area type and the downstream
advertising prefix reachability and is also generating the Extend neighbor is an
ed Prefix ABR, which is advertising prefix reachability and is also generating
TLV with the A-flag set for this prefix as described in section 2 the Extended Prefix TLV with the A-Flag set for this prefix as
.1 of described in <xref target="RFC7684" sectionFormat="of" section="2.1" form
<xref target="RFC7684"/>.</t> at="default" derivedLink="https://rfc-editor.org/rfc/rfc7684#section-2.1" derive
dContent="RFC7684"/>.</li>
<t> The Prefix is external type and downstream neighbor is an ASB <li pn="section-5-17.3"> The Prefix is external type and the downstream
R, which is neighbor is an ASBR,
advertising prefix reachability and is also generating the Extend which is advertising prefix reachability and is also generating the
ed Prefix Extended Prefix TLV with the A-Flag set for this prefix as described
TLV with the A-flag set for this prefix as described in section 2 in <xref target="RFC7684" sectionFormat="of" section="2.1" format="defau
.1 of lt" derivedLink="https://rfc-editor.org/rfc/rfc7684#section-2.1" derivedContent=
<xref target="RFC7684"/>.</t> "RFC7684"/>.</li>
</list></t> </ul>
<t pn="section-5-18">When a Prefix-SID is advertised in an Extended Prefix
<t>When a Prefix-SID is advertised in an Extended Prefix Range TL Range TLV, then
V, then the value the value advertised in the Prefix-SID Sub-TLV is interpreted as a
advertised in the Prefix SID Sub-TLV is interpreted as a startin starting SID/Label value.</t>
g SID/Label value.</t> <t pn="section-5-19">Example 1: If the following router addresses (loopbac
k addresses)
<t>Example 1: If the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix-SID indexes: </t>
need to be mapped into the corresponding Prefix SID indexes: <figure <artwork name="" type="" align="left" alt="" pn="section-5-20">
suppress-title="true">
<artwork>
Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-A: 192.0.2.1/32, Prefix-SID: Index 1
Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-B: 192.0.2.2/32, Prefix-SID: Index 2
Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-C: 192.0.2.3/32, Prefix-SID: Index 3
Router-D: 192.0.2.4/32, Prefix-SID: Index 4 Router-D: 192.0.2.4/32, Prefix-SID: Index 4</artwork>
</artwork> <t pn="section-5-21">then the Prefix field in the Extended Prefix Range TL
</figure></t> V would be set to
<t>then the Prefix field in the Extended Prefix Range TLV would be set t
o
192.0.2.1, Prefix Length would be set to 32, Range Size would be set to 4, and 192.0.2.1, Prefix Length would be set to 32, Range Size would be set to 4, and
the Index value in the Prefix-SID Sub-TLV would be set to 1.</t> the Index value in the Prefix-SID Sub-TLV would be set to 1.</t>
<t pn="section-5-22">Example 2: If the following prefixes need to be mappe
<t>Example 2: If the following prefixes need to be mapped into the d into the
corresponding Prefix-SID indexes: <figure suppress-title="true"> corresponding Prefix-SID indexes: </t>
<artwork> <artwork name="" type="" align="left" alt="" pn="section-5-23">
192.0.2.0/30, Prefix-SID: Index 51 192.0.2.0/30, Prefix-SID: Index 51
192.0.2.4/30, Prefix-SID: Index 52 192.0.2.4/30, Prefix-SID: Index 52
192.0.2.8/30, Prefix-SID: Index 53 192.0.2.8/30, Prefix-SID: Index 53
192.0.2.12/30, Prefix-SID: Index 54 192.0.2.12/30, Prefix-SID: Index 54
192.0.2.16/30, Prefix-SID: Index 55 192.0.2.16/30, Prefix-SID: Index 55
192.0.2.20/30, Prefix-SID: Index 56 192.0.2.20/30, Prefix-SID: Index 56
192.0.2.24/30, Prefix-SID: Index 57 192.0.2.24/30, Prefix-SID: Index 57</artwork>
</artwork> <t pn="section-5-24">then the Prefix field in the Extended Prefix Range TL
</figure></t> V would be set to
<t>then the Prefix field in the Extended Prefix Range TLV would be set t
o
192.0.2.0, Prefix Length would be set to 30, Range Size would be 7, and 192.0.2.0, Prefix Length would be set to 30, Range Size would be 7, and
the Index value in the Prefix-SID Sub-TLV would be set to 51.</t> the Index value in the Prefix-SID Sub-TLV would be set to 51.</t>
</section> </section>
<section anchor="ADJSID" numbered="true" toc="include" removeInRFC="false" p
<section anchor="ADJSID" title="Adjacency Segment Identifier (Adj-SID)"> n="section-6">
<t>An Adjacency Segment Identifier (Adj-SID) represents a router <name slugifiedName="name-adjacency-segment-identifie">Adjacency Segment I
dentifier (Adj-SID)</name>
<t pn="section-6-1">An Adjacency Segment Identifier (Adj-SID) represents a
router
adjacency in Segment Routing.</t> adjacency in Segment Routing.</t>
<section anchor="ADJSIDSUBTLV" numbered="true" toc="include" removeInRFC="
<section anchor="ADJSIDSUBTLV" title="Adj-SID Sub-TLV"> false" pn="section-6.1">
<t>Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in <name slugifiedName="name-adj-sid-sub-tlv">Adj-SID Sub-TLV</name>
<xref target="RFC7684"/>. It MAY appear multiple times <t pn="section-6.1-1">Adj-SID is an optional sub-TLV of the Extended Lin
k TLV defined in
<xref target="RFC7684" format="default" sectionFormat="of" derivedConten
t="RFC7684"/>. It <bcp14>MAY</bcp14> appear multiple times
in the Extended Link TLV. in the Extended Link TLV.
The Adj-SID Sub-TLV has the following format: <figure> The Adj-SID Sub-TLV has the following format: </t>
<artwork> <artwork name="" type="" align="left" alt="" pn="section-6.1-2">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | MT-ID | Weight | | Flags | Reserved | MT-ID | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+</artwork>
<t pn="section-6.1-3">where:</t>
where:</artwork> <ul empty="true" bare="false" spacing="normal" pn="section-6.1-4">
</figure><list style="hanging"> <li pn="section-6.1-4.1">
<t>Type: 2</t> <dl newline="false" spacing="normal" pn="section-6.1-4.1.1">
<dt pn="section-6.1-4.1.1.1">Type:</dt>
<t>Length: 7 or 8 octets, dependent on the V flag.</t> <dd pn="section-6.1-4.1.1.2">2</dd>
<dt pn="section-6.1-4.1.1.3">Length:</dt>
<t>Flags: Single octet field containing the following flags:<figure <dd pn="section-6.1-4.1.1.4">7 or 8 octets, depending on the V-Fla
align="center"> g</dd>
<artwork> <dt pn="section-6.1-4.1.1.5">Flags:</dt>
0 1 2 3 4 5 6 7 <dd pn="section-6.1-4.1.1.6">
+-+-+-+-+-+-+-+-+ <t pn="section-6.1-4.1.1.6.1">Single-octet field containing the
|B|V|L|G|P| | following flags:</t>
+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt="" pn="section-6.1-4.1
.1.6.2">
where:</artwork> 0 1 2 3 4 5 6 7
</figure><list style="hanging"> +-+-+-+-+-+-+-+-+
<t>B-Flag: Backup Flag. If set, the Adj-SID refers to an |B|V|L|G|P| |
adjacency that is eligible for protection (e.g., using IPFRR or +-+-+-+-+-+-+-+-+</artwork>
MPLS-FRR) <t pn="section-6.1-4.1.1.6.3">where:</t>
as described in section 3.5 of <xref <ul empty="true" bare="false" spacing="normal" pn="section-6.1-4
target="I-D.ietf-spring-segment-routing"/>.</t> .1.1.6.4">
<li pn="section-6.1-4.1.1.6.4.1">
<t>The V-Flag: Value/Index Flag. If set, then the Adj-SID <dl newline="false" spacing="normal" pn="section-6.1-4.1.1.6
.4.1.1">
<dt pn="section-6.1-4.1.1.6.4.1.1.1">B-Flag:</dt>
<dd pn="section-6.1-4.1.1.6.4.1.1.2">Backup Flag. If set,
the Adj-SID refers to an
adjacency that is eligible for protection (e.g., using IP Fast
Reroute or MPLS-FRR (MPLS-Fast Reroute)
as described in <xref target="RFC8402" sectionFormat="of" sectio
n="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section
-2.1" derivedContent="RFC8402"/>.</dd>
<dt pn="section-6.1-4.1.1.6.4.1.1.3">V-Flag:</dt>
<dd pn="section-6.1-4.1.1.6.4.1.1.4">Value/Index Flag. If
set, then the Adj-SID
carries an absolute value. If not set, then the Adj-SID carries carries an absolute value. If not set, then the Adj-SID carries
an index.</t> an index.</dd>
<dt pn="section-6.1-4.1.1.6.4.1.1.5">L-Flag:</dt>
<t>The L-Flag: Local/Global Flag. If set, then the value/index <dd pn="section-6.1-4.1.1.6.4.1.1.6">Local/Global Flag. If
set, then the value/index
carried by the Adj-SID has local significance. If not set, then carried by the Adj-SID has local significance. If not set, then
the value/index carried by this Sub-TLV has global significance. the value/index carried by this sub-TLV has global significance.
</t> </dd>
<dt pn="section-6.1-4.1.1.6.4.1.1.7">G-Flag:</dt>
<t>The G-Flag: Group Flag. When set, the G-Flag indicates that t <dd pn="section-6.1-4.1.1.6.4.1.1.8">Group Flag. When set,
he the G-Flag indicates that the
Adj-SID refers to a group of adjacencies (and therefore MAY be a Adj-SID refers to a group of adjacencies (and therefore <bcp14>M
ssigned AY</bcp14> be assigned
to other adjacencies as well).</t> to other adjacencies as well).</dd>
<dt pn="section-6.1-4.1.1.6.4.1.1.9">P-Flag:</dt>
<t>P-Flag. Persistent flag. When set, the P-Flag indicates that <dd pn="section-6.1-4.1.1.6.4.1.1.10">Persistent Flag. Whe
n set, the P-Flag indicates that
the Adj-SID is persistently allocated, i.e., the Adj- SID value the Adj-SID is persistently allocated, i.e., the Adj- SID value
remains consistent across router restart and/or inter remains consistent across router restart and/or inter
face flap.</t> face flap.</dd>
<dt pn="section-6.1-4.1.1.6.4.1.1.11">Other bits:</dt>
<t>Other bits: Reserved. These MUST be zero when sent and are ig <dd pn="section-6.1-4.1.1.6.4.1.1.12">Reserved. These <bcp
nored when 14>MUST</bcp14> be zero when sent and are ignored when
received.</t> received.</dd>
</list></t> </dl>
</li>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored </ul>
on reception.</t> </dd>
<dt pn="section-6.1-4.1.1.7">Reserved:</dt>
<t>MT-ID: Multi-Topology ID (as defined in <xref <dd pn="section-6.1-4.1.1.8">
target="RFC4915"/>.</t> <bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUS
T</bcp14> be ignored on reception</dd>
<t>Weight: Weight used for load-balancing purposes. The use of the <dt pn="section-6.1-4.1.1.9">MT-ID:</dt>
weight is defined in <xref <dd pn="section-6.1-4.1.1.10">Multi-Topology ID (as defined in <xr
target="I-D.ietf-spring-segment-routing"/>.</t> ef target="RFC4915" format="default" sectionFormat="of" derivedContent="RFC4915"
/></dd>
<t>SID/Index/Label: as described in <xref target="PREFIXSID"/>.</t> <dt pn="section-6.1-4.1.1.11">Weight:</dt>
<dd pn="section-6.1-4.1.1.12"> Weight used for load-balancing purp
</list></t> oses. The use of the
weight is defined in <xref target="RFC8402" format="default" section
<t>An SR capable router MAY allocate an Adj-SID for each of its Format="of" derivedContent="RFC8402"/>.</dd>
<dt pn="section-6.1-4.1.1.13">SID/Index/Label:</dt>
<dd pn="section-6.1-4.1.1.14">As described in <xref target="PREFIX
SID" format="default" sectionFormat="of" derivedContent="Section 5"/></dd>
</dl>
</li>
</ul>
<t pn="section-6.1-5">An SR-capable router <bcp14>MAY</bcp14> allocate a
n Adj-SID for each of its
adjacencies and set the B-Flag when the adjacency is eligible for protec tion by adjacencies and set the B-Flag when the adjacency is eligible for protec tion by
an FRR mechanism (IP or MPLS) as described in section 3.5 of <xref an FRR mechanism (IP or MPLS) as described in
target="I-D.ietf-spring-segment-routing"/>.</t> <xref target="RFC8402" sectionFormat="of" section="3.5" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc8402#section-3.5" derivedContent="RFC
<t>An SR capable router MAY allocate more than one Adj-SID to an adjacen 8402"/>.</t>
cy</t> <t pn="section-6.1-6">An SR-capable router <bcp14>MAY</bcp14> allocate m
ore than one Adj-SID to an adjacency.</t>
<t>An SR capable router MAY allocate the same Adj-SID to different adjac <t pn="section-6.1-7">An SR-capable router <bcp14>MAY</bcp14> allocate t
encies</t> he same Adj-SID to different adjacencies.</t>
<t pn="section-6.1-8">When the P-Flag is not set, the Adj-SID <bcp14>MAY
<t>When the P-flag is not set, the Adj-SID MAY be persistent. When </bcp14> be persistent. When
the P-flag is set, the Adj-SID MUST be persistent.</t> the P-Flag is set, the Adj-SID <bcp14>MUST</bcp14> be persistent.</t>
</section> </section>
<section anchor="LANADJSIDSUBTLV" numbered="true" toc="include" removeInRF
<section anchor="LANADJSIDSUBTLV" title="LAN Adj-SID Sub-TLV"> C="false" pn="section-6.2">
<t>LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined i <name slugifiedName="name-lan-adj-sid-sub-tlv">LAN Adj-SID Sub-TLV</name
n >
<xref target="RFC7684"/>. It MAY appear multiple <t pn="section-6.2-1">The LAN Adjacency SID is an optional sub-TLV of th
times in the Extended-Link TLV. It is used to advertise a SID/Label for e Extended Link TLV defined in
an adjacency <xref target="RFC7684" format="default" sectionFormat="of" derivedConten
to a non-DR router on a broadcast, NBMA, or hybrid <xref target="RFC6845 t="RFC7684"/>. It <bcp14>MAY</bcp14> appear multiple
"/> network. times in the Extended Link TLV. It is used to advertise a SID/Label for
<figure> an adjacency
<artwork> to a non-DR (Designated Router) router on a broadcast, Non-Broadcast Mul
ti-Access (NBMA), or hybrid <xref target="RFC6845" format="default" sectionForma
t="of" derivedContent="RFC6845"/> network.
</t>
<artwork name="" type="" align="left" alt="" pn="section-6.2-2">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | MT-ID | Weight | | Flags | Reserved | MT-ID | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID | | Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+</artwork>
<t pn="section-6.2-3">where:</t>
where:</artwork> <ul empty="true" bare="false" spacing="normal" pn="section-6.2-4">
</figure><list style="hanging"> <li pn="section-6.2-4.1">
<t>Type: 3</t> <dl newline="false" spacing="normal" pn="section-6.2-4.1.1">
<dt pn="section-6.2-4.1.1.1">Type:</dt>
<t>Length: 11 or 12 octets, dependent on V-flag.</t> <dd pn="section-6.2-4.1.1.2">3</dd>
<dt pn="section-6.2-4.1.1.3">Length:</dt>
<t>Flags: same as in <xref target="ADJSIDSUBTLV"/></t> <dd pn="section-6.2-4.1.1.4">11 or 12 octets, depending on the V-F
lag</dd>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored <dt pn="section-6.2-4.1.1.5">Flags:</dt>
on reception.</t> <dd pn="section-6.2-4.1.1.6">Same as in <xref target="ADJSIDSUBTLV
" format="default" sectionFormat="of" derivedContent="Section 6.1"/></dd>
<t>MT-ID: Multi-Topology ID (as defined in <xref <dt pn="section-6.2-4.1.1.7">Reserved:</dt>
target="RFC4915"/>.</t> <dd pn="section-6.2-4.1.1.8">
<bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUS
<t>Weight: Weight used for load-balancing purposes. The use of the T</bcp14> be ignored on reception</dd>
weight is defined in <xref target="I-D.ietf-spring-segment-routing"/ <dt pn="section-6.2-4.1.1.9">MT-ID:</dt>
>.</t> <dd pn="section-6.2-4.1.1.10">Multi-Topology ID (as defined in <xr
ef target="RFC4915" format="default" sectionFormat="of" derivedContent="RFC4915"
<t>Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- />)</dd>
SID is <dt pn="section-6.2-4.1.1.11">Weight:</dt>
advertised.</t> <dd pn="section-6.2-4.1.1.12">Weight used for load-balancing purpo
ses. The use of the
<t>SID/Index/Label: as described in <xref target="PREFIXSID"/>.</t> weight is defined in <xref target="RFC8402" format="default" section
Format="of" derivedContent="RFC8402"/>.</dd>
<t>When the P-flag is not set, the Adj-SID MAY be persistent. When <dt pn="section-6.2-4.1.1.13">Neighbor ID:</dt>
the P-flag is set, the Adj-SID MUST be persistent.</t> <dd pn="section-6.2-4.1.1.14">The Router ID of the neighbor for wh
ich the LAN Adjacency SID is
</list></t> advertised</dd>
<dt pn="section-6.2-4.1.1.15">SID/Index/Label:</dt>
<dd pn="section-6.2-4.1.1.16">
<t pn="section-6.2-4.1.1.16.1">As described in <xref target="PRE
FIXSID" format="default" sectionFormat="of" derivedContent="Section 5"/></t>
</dd>
</dl>
</li>
</ul>
<t pn="section-6.2-5">When the P-Flag is not set, the LAN Adjacency SID
<bcp14>MAY</bcp14> be persistent. When
the P-Flag is set, the LAN Adjacency SID <bcp14>MUST</bcp14> be persistent.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<section title="Elements of Procedure"> <name slugifiedName="name-elements-of-procedure">Elements of Procedure</na
<section title="Intra-area Segment routing in OSPFv2 "> me>
<t>An OSPFv2 router that supports segment routing MAY advertise Prefix- <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1
">
<name slugifiedName="name-intra-area-segment-routing-">Intra-area Segmen
t Routing in OSPFv2</name>
<t pn="section-7.1-1">An OSPFv2 router that supports Segment Routing <bc
p14>MAY</bcp14> advertise Prefix-
SIDs for any prefix to which it is advertising reachability (e.g., SIDs for any prefix to which it is advertising reachability (e.g.,
a loopback IP address as described in <xref target="PREFIXSID"/>).</t> a loopback IP address as described in <xref target="PREFIXSID" format="d
efault" sectionFormat="of" derivedContent="Section 5"/>).</t>
<t>A Prefix-SID can also be advertised by the SR Mapping Servers (as <t pn="section-7.1-2">A Prefix-SID can also be advertised by the SR Mapp
described in <xref ing Servers (as
target="I-D.ietf-spring-segment-routing-ldp-interop"/>). A Mapping described in <xref target="RFC8661" format="default" sectionFormat="of"
derivedContent="RFC8661"/>). A Mapping
Server advertises Prefix-SIDs for remote prefixes that exist in the Server advertises Prefix-SIDs for remote prefixes that exist in the
OSPFv2 routing domain. Multiple Mapping Servers can advertise Prefix-SID s OSPFv2 routing domain. Multiple Mapping Servers can advertise Prefix-SID s
for the same prefix, in which case the same Prefix-SID MUST be advertise d by for the same prefix; in which case, the same Prefix-SID <bcp14>MUST</bcp 14> be advertised by
all of them. The flooding scope of the OSPF Extended Prefix Opaque LSA all of them. The flooding scope of the OSPF Extended Prefix Opaque LSA
that is generated by the SR Mapping Server could be either area-scoped that is generated by the SR Mapping Server could be either area scoped
or AS-scoped and is determined based on the configuration of the or AS scoped and is determined based on the configuration of the
SR Mapping Server.</t> SR Mapping Server.</t>
<t pn="section-7.1-3">An SR Mapping Server <bcp14>MUST</bcp14> use the O
<t>An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when SPF Extended Prefix Range TLV when advertising SIDs
advertising SIDs for prefixes. Prefixes of different route types can be combined in a sin
for prefixes. Prefixes of different route-types can be combined in a sin gle OSPF
gle OSPF
Extended Prefix Range TLV advertised by an SR Mapping Server. Because th e OSPF Extended Prefix Range TLV advertised by an SR Mapping Server. Because th e OSPF
Extended Prefix Range TLV doesn't include a Route-Type field, as in the OSPF Extended Prefix Range TLV doesn't include a Route-Type field, as in the OSPF
Extended Prefix TLV, it is possible to include adjacent prefixes from di fferent Extended Prefix TLV, it is possible to include adjacent prefixes from di fferent
Route-Types in the OSPF Extended Prefix Range TLV.</t> route types in the OSPF Extended Prefix Range TLV.</t>
<t pn="section-7.1-4">Area-scoped OSPF Extended Prefix Range TLVs are pr
<t>Area-scoped OSPF Extended Prefix Range TLVs are propagated between ar opagated between areas. Similar
eas. Similar
to propagation of prefixes between areas, an ABR only propagates the OSP F Extended to propagation of prefixes between areas, an ABR only propagates the OSP F Extended
Prefix Range TLV that it considers to be the best from the set it receiv ed. The Prefix Range TLV that it considers to be the best from the set it receiv ed. The
rules used to pick the best OSPF Extended Prefix Range TLV are described in rules used to pick the best OSPF Extended Prefix Range TLV are described in
<xref target="PFXRANGE"/>.</t> <xref target="PFXRANGE" format="default" sectionFormat="of" derivedConte
nt="Section 4"/>.</t>
<t>When propagating an OSPF Extended Prefix Range TLV between areas, ABR <t pn="section-7.1-5">When propagating an OSPF Extended Prefix Range TLV
s MUST set the between areas, ABRs <bcp14>MUST</bcp14> set the
IA-Flag, that is used to prevent redundant flooding of the OSPF Extended IA-Flag. This is used to prevent redundant flooding of the OSPF Extended
Prefix Range TLV between areas as described in <xref target="PFXRANGE"/> Prefix Range TLV between areas as described in <xref target="PFXRANGE" f
.</t> ormat="default" sectionFormat="of" derivedContent="Section 4"/>.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.2
<section title="Inter-area Segment routing in OSPFv2"> ">
<t>In order to support SR in a multi-area environment, OSPFv2 MUST <name slugifiedName="name-inter-area-segment-routing-">Inter-area Segmen
t Routing in OSPFv2</name>
<t pn="section-7.2-1">In order to support SR in a multiarea environment,
OSPFv2 <bcp14>MUST</bcp14>
propagate Prefix-SID information between areas. The following propagate Prefix-SID information between areas. The following
procedure is used to propagate Prefix SIDs between areas.</t> procedure is used to propagate Prefix-SIDs between areas.</t>
<t pn="section-7.2-2">When an OSPF ABR advertises a Type-3 Summary LSA f
<t>When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area rom an intra-area
prefix to all its connected areas, it will also originate an Extended prefix to all its connected areas, it will also originate an OSPF Extend
Prefix Opaque LSA, as described in <xref target="RFC7684"/>. ed
The flooding scope of the Extended Prefix Opaque LSA type will be set to Prefix Opaque LSA as described in <xref target="RFC7684" format="default
area-local scope. The route-type in the OSPF Extended Prefix TLV is set " sectionFormat="of" derivedContent="RFC7684"/>.
to The flooding scope of the OSPF Extended Prefix Opaque LSA type will be s
et to
area-local scope. The route type in the OSPF Extended Prefix TLV is set
to
inter-area. The Prefix-SID Sub-TLV will be included in this LSA and inter-area. The Prefix-SID Sub-TLV will be included in this LSA and
the Prefix-SID value will be set as follows: <list style="hanging"> the Prefix-SID value will be set as follows: </t>
<t>The ABR will look at its best path to the prefix in the source <ul empty="true" spacing="normal" bare="false" pn="section-7.2-3">
<li pn="section-7.2-3.1">The ABR will look at its best path to the pre
fix in the source
area and find the advertising router associated with the best area and find the advertising router associated with the best
path to that prefix.</t> path to that prefix.</li>
<li pn="section-7.2-3.2">The ABR will then determine if this router ad
<t>The ABR will then determine if such router advertised a Prefix-SI vertised a
D Prefix-SID for the prefix and use it when advertising the
for the prefix and use it when advertising the Prefix-SID Prefix-SID to other connected areas.</li>
to other <li pn="section-7.2-3.3">If no Prefix-SID was advertised for the prefi
connected areas.</t> x in the source
<t>If no Prefix-SID was advertised for the prefix in the source
area by the router that contributes to the best path to the area by the router that contributes to the best path to the
prefix, the originating ABR will use the Prefix-SID advertised by an y prefix, the originating ABR will use the Prefix-SID advertised by an y
other router when propagating the Prefix-SID for the prefix to other other router when propagating the Prefix-SID for the prefix to other
areas.</t> areas.</li>
</list></t> </ul>
<t pn="section-7.2-4">When an OSPF ABR advertises Type-3 Summary LSAs fr
<t>When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area om an inter-area
route to all its connected areas, it will also originate an Extended route to all its connected areas, it will also originate an OSPF Extende
Prefix Opaque LSA, as described in <xref target="RFC7684"/>. d
The flooding scope of the Extended Prefix Opaque LSA type will be set to Prefix Opaque LSA as described in <xref target="RFC7684" format="default
area-local scope. The route-type in OSPF Extended Prefix TLV is set to " sectionFormat="of" derivedContent="RFC7684"/>.
The flooding scope of the OSPF Extended Prefix Opaque LSA type will be s
et to
area-local scope. The route type in the OSPF Extended Prefix TLV is set
to
inter-area. The Prefix-SID Sub-TLV will be included in this LSA and inter-area. The Prefix-SID Sub-TLV will be included in this LSA and
the Prefix-SID will be set as follows: <list style="hanging"> the Prefix-SID will be set as follows: </t>
<t>The ABR will look at its best path to the prefix in the backbone <ul empty="true" spacing="normal" bare="false" pn="section-7.2-5">
<li pn="section-7.2-5.1">The ABR will look at its best path to the pre
fix in the backbone
area and find the advertising router associated with the best area and find the advertising router associated with the best
path to that prefix.</t> path to that prefix.</li>
<li pn="section-7.2-5.2">The ABR will then determine if such a router
<t>The ABR will then determine if such router advertised a Prefix-SI advertised a
D Prefix-SID for the prefix and use it when advertising the Prefix-SID
for the prefix and use it when advertising the Prefix-SID to other to other connected areas.</li>
connected areas.</t> <li pn="section-7.2-5.3">If no Prefix-SID was advertised for the prefi
x in the backbone
<t>If no Prefix-SID was advertised for the prefix in the backbone
area by the ABR that contributes to the best path to the prefix, area by the ABR that contributes to the best path to the prefix,
the originating ABR will use the Prefix-SID advertised by any the originating ABR will use the Prefix-SID advertised by any
other router when propagating the Prefix-SID for the prefix to other other router when propagating the Prefix-SID for the prefix to other
areas.</t> areas.</li>
</list></t> </ul>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.3
<section title="Segment Routing for External Prefixes"> ">
<t>Type-5 LSAs are flooded domain wide. When an ASBR, which supports <name slugifiedName="name-segment-routing-for-externa">Segment Routing f
SR, generates Type-5 LSAs, it SHOULD also originate Extended Prefix or External Prefixes</name>
Opaque LSAs, as described in <xref target="RFC7684"/>. <t pn="section-7.3-1">Type-5 LSAs are flooded domain wide. When an ASBR,
The flooding scope of the Extended Prefix Opaque LSA type is set to AS-w which supports
ide scope. SR, generates Type-5 LSAs, it <bcp14>SHOULD</bcp14> also originate
The route-type in the OSPF Extended Prefix TLV is set to external. The OSPF Extended Prefix Opaque LSAs as described in <xref target="RFC7684"
Prefix-SID Sub-TLV is included in this LSA and the Prefix-SID value will format="default" sectionFormat="of" derivedContent="RFC7684"/>. The flooding sc
be set ope of the
to the SID that has been reserved for that prefix.</t> OSPF Extended Prefix Opaque LSA type is set to AS-wide scope. The route
type in the OSPF Extended Prefix TLV is set to external. The
<t>When an NSSA <xref target="RFC3101"/> ABR translates Type-7 LSAs into Prefix-SID Sub-TLV is included in this LSA and the Prefix-SID value
Type-5 will be set to the SID that has been reserved for that prefix.</t>
LSAs, it SHOULD also advertise the Prefix-SID for the prefix. The NSSA A <t pn="section-7.3-2">When a Not-So-Stubby Area (NSSA) <xref target="RFC
BR determines 3101" format="default" sectionFormat="of" derivedContent="RFC3101"/> ABR transla
tes Type-7 LSAs into Type-5
LSAs, it <bcp14>SHOULD</bcp14> also advertise the Prefix-SID for the pre
fix. The NSSA ABR determines
its best path to the prefix advertised in the translated Type-7 LSA its best path to the prefix advertised in the translated Type-7 LSA
and finds the advertising router associated with that path. If the and finds the advertising router associated with that path. If the
advertising router has advertised a Prefix-SID for the prefix, then advertising router has advertised a Prefix-SID for the prefix, then
the NSSA ABR uses it when advertising the Prefix-SID for the Type-5 the NSSA ABR uses it when advertising the Prefix-SID for the Type-5
prefix. Otherwise, the Prefix-SID advertised by any other router will prefix. Otherwise, the Prefix-SID advertised by any other router will
be used.</t> be used.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7.4
<section title="Advertisement of Adj-SID"> ">
<t>The Adjacency Segment Routing Identifier (Adj-SID) is advertised <name slugifiedName="name-advertisement-of-adj-sid">Advertisement of Adj
using the Adj-SID Sub-TLV as described in <xref target="ADJSID"/>.</t> -SID</name>
<t pn="section-7.4-1">The Adjacency Segment Routing Identifier (Adj-SID)
<section title="Advertisement of Adj-SID on Point-to-Point Links"> is advertised
<t>An Adj-SID MAY be advertised for any adjacency on a P2P link that i using the Adj-SID Sub-TLV as described in <xref target="ADJSID" format="
s default" sectionFormat="of" derivedContent="Section 6"/>.</t>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7
.4.1">
<name slugifiedName="name-advertisement-of-adj-sid-on">Advertisement o
f Adj-SID on Point-to-Point Links</name>
<t pn="section-7.4.1-1">An Adj-SID <bcp14>MAY</bcp14> be advertised fo
r any adjacency on a point-to-point (P2P) link that is
in neighbor state 2-Way or higher. If the adjacency on a P2P link in neighbor state 2-Way or higher. If the adjacency on a P2P link
transitions from the FULL state, then the Adj-SID for that adjacency transitions from the FULL state, then the Adj-SID for that adjacency
MAY be removed from the area. If the adjacency transitions to a <bcp14>MAY</bcp14> be removed from the area. If the adjacency transiti
state lower then 2-Way, then the Adj-SID advertisement MUST be withdra ons to a
wn from the state lower than 2-Way, then the Adj-SID Advertisement <bcp14>MUST</bc
p14> be withdrawn from the
area.</t> area.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7
<section title="Adjacency SID on Broadcast or NBMA Interfaces"> .4.2">
<t>Broadcast, NBMA, or hybrid <xref target="RFC6845"/> networks in OSP <name slugifiedName="name-adjacency-sid-on-broadcast-">Adjacency SID o
F are n Broadcast or NBMA Interfaces</name>
<t pn="section-7.4.2-1">Broadcast, NBMA, or hybrid <xref target="RFC68
45" format="default" sectionFormat="of" derivedContent="RFC6845"/> networks in O
SPF are
represented by a star topology where the Designated Router (DR) is the central represented by a star topology where the Designated Router (DR) is the central
point to which all other routers on the broadcast, NBMA, or hybrid net work connect. point to which all other routers on the broadcast, NBMA, or hybrid net work connect.
As a result, routers on the broadcast, NBMA, or hybrid network adverti se only As a result, routers on the broadcast, NBMA, or hybrid network adverti se only
their adjacency to the DR. Routers that do not act as DR do not form o r their adjacency to the DR. Routers that do not act as DR do not form o r
advertise adjacencies with each other. They do, however, maintain 2-Wa y adjacency advertise adjacencies with each other. They do, however, maintain 2-Wa y adjacency
state with each other and are directly reachable.</t> state with each other and are directly reachable.</t>
<t pn="section-7.4.2-2">When Segment Routing is used, each router on t
<t>When Segment Routing is used, each router on the broadcast, NBMA, o he broadcast, NBMA, or hybrid
r hybrid network <bcp14>MAY</bcp14> advertise the Adj-SID for its adjacency to
network MAY advertise the Adj-SID for its adjacency to the DR using the DR using
the Adj-SID Sub-TLV as described in <xref target="ADJSIDSUBTLV"/>.</t> the Adj-SID Sub-TLV as described in <xref target="ADJSIDSUBTLV" format
="default" sectionFormat="of" derivedContent="Section 6.1"/>.</t>
<t>SR capable routers MAY also advertise a LAN-Adj-SID for other neigh <t pn="section-7.4.2-3">SR-capable routers <bcp14>MAY</bcp14> also adv
bors ertise a LAN Adjacency SID for other neighbors
(e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid network using (e.g., Backup Designated Router, DR-OTHER, etc.) on the broadcast, NBM
the A, or hybrid network using the
LAN-ADJ-SID Sub-TLV as described in <xref target="LANADJSIDSUBTLV"/>.< LAN Adj-SID Sub-TLV as described in <xref target="LANADJSIDSUBTLV" for
/t> mat="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-8">
<t>This specification updates several existing OSPF registries.</t> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t pn="section-8-1">This specification updates several existing OSPF
<section anchor="RITLVREG" title="OSPF Router Information (RI) TLVs Reg registries and creates a new IGP registry.</t>
istry"> <section anchor="RITLVREG" numbered="true" toc="include" removeInRFC="fals
e" pn="section-8.1">
<t>o 8 (IANA Preallocated) - SR-Algorithm TLV</t> <name slugifiedName="name-ospf-router-information-ri-">OSPF Router Infor
mation (RI) TLVs Registry</name>
<t>o 9 (IANA Preallocated) - SID/Label Range TLV</t> <t pn="section-8.1-1">The following values have been allocated:</t>
<table anchor="IANA1" align="left" pn="table-1">
<t>o 14 - SR Local Block TLV</t> <name slugifiedName="name-ospf-router-information-ri-t">OSPF Router In
formation (RI) TLVs</name>
<t>o 15 - SRMS Preference TLV</t> <thead>
<tr>
</section> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">TLV Name</th>
<section anchor="EPLTLVREG" title="OSPFv2 Extended Prefix Opaque LSA TLVs <th align="left" colspan="1" rowspan="1">Reference</th>
Registry"> </tr>
</thead>
<t>Following values are allocated:</t> <tbody>
<tr>
<t>o 2 - OSPF Extended Prefix Range TLV</t> <td align="left" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">SR-Algorithm TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">SID/Label Range TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">SR Local Block TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">SRMS Preference TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="EPLTLVREG" numbered="true" toc="include" removeInRFC="fal
<section anchor="EPLSTLVREG" title="OSPFv2 Extended Prefix TLV Sub-TLVs Re se" pn="section-8.2">
gistry"> <name slugifiedName="name-ospfv2-extended-prefix-opaq">OSPFv2 Extended P
refix Opaque LSA TLVs Registry</name>
<t>Following values are allocated:</t> <t pn="section-8.2-1">The following values have been allocated:
</t>
<t>o 1 - SID/Label Sub-TLV</t> <table anchor="IANA2" align="left" pn="table-2">
<name slugifiedName="name-ospfv2-extended-prefix-opaqu">OSPFv2 Extende
<t>o 2 - Prefix SID Sub-TLV</t> d Prefix Opaque LSA TLVs</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">OSPF Extended Prefix Rang
e TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="EPLSTLVREG" numbered="true" toc="include" removeInRFC="fa
<section anchor="ELLSTLVREG" title="OSPFv2 Extended Link TLV Sub-TLVs Regi lse" pn="section-8.3">
stry"> <name slugifiedName="name-ospfv2-extended-prefix-tlv-">OSPFv2 Extended P
refix TLV Sub-TLVs Registry</name>
<t>Following initial values are allocated:</t> <t pn="section-8.3-1">The following values have been allocated:</t>
<table anchor="IANA3" align="left" pn="table-3">
<t>o 1 - SID/Label Sub-TLV</t> <name slugifiedName="name-ospfv2-extended-prefix-tlv-s">OSPFv2 Extende
d Prefix TLV Sub-TLVs</name>
<t>o 2 - Adj-SID Sub-TLV</t> <thead>
<tr>
<t>o 3 - LAN Adj-SID/Label Sub-TLV</t> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">SID/Label Sub-TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">Prefix-SID Sub-TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="ELLSTLVREG" numbered="true" toc="include" removeInRFC="fa
<section anchor="IGPALGOREG" title="IGP Algorithm Type Registry"> lse" pn="section-8.4">
<name slugifiedName="name-ospfv2-extended-link-tlv-su">OSPFv2 Extended L
<t>IANA is requested to set up a registry called "IGP Algorithm Type" under ink TLV Sub-TLVs Registry</name>
a new <t pn="section-8.4-1">The following initial values have been allocated:<
category of "Interior Gateway Protocol (IGP) Parameters" IANA registries. /t>
<table anchor="IANA4" align="left" pn="table-4">
<name slugifiedName="name-ospfv2-extended-link-tlv-sub">OSPFv2 Extende
d Link TLV Sub-TLVs</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">SID/Label Sub-TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">Adj-SID Sub-TLV</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">LAN Adj-SID/Label Sub-TLV
</td>
<td align="left" colspan="1" rowspan="1">This document</td>
</tr>
</tbody>
</table>
</section>
<section anchor="IGPALGOREG" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-8.5">
<name slugifiedName="name-igp-algorithm-types-registr">IGP Algorithm Typ
es Registry</name>
<t pn="section-8.5-1">IANA has set up a subregistry called "IGP Algorith
m Type" under the
"Interior Gateway Protocol (IGP) Parameters" registry.
The registration policy for this registry is "Standards Action" The registration policy for this registry is "Standards Action"
(<xref target="RFC8126"/> and <xref target="RFC7120"/>).</t> (<xref target="RFC8126" format="default" sectionFormat="of" derivedConten
t="RFC8126"/> and <xref target="RFC7120" format="default" sectionFormat="of" der
<t>Values in this registry come from the range 0-255.</t> ivedContent="RFC7120"/>).</t>
<t pn="section-8.5-2">Values in this registry come from the range 0-255.
<t> The initial values in the IGP Algorithm Type registry are:<list style='ha </t>
nging'> <t pn="section-8.5-3"> The initial values in the IGP Algorithm Type regi
stry are
<t>0: Shortest Path First (SPF) algorithm based on link metric. as follows:</t>
This is <table anchor="IANA5" align="left" pn="table-5">
<name slugifiedName="name-igp-algorithm-types">IGP Algorithm Types</na
me>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">Shortest Path First (SPF)
algorithm based on link metric. This is
the standard shortest path algorithm as computed by the IGP prot ocol. the standard shortest path algorithm as computed by the IGP prot ocol.
Consistent with the deployed practice for link-state protocols, Algorithm 0 Consistent with the deployed practice for link-state protocols, Algorithm 0
permits any node to overwrite the SPF path with a different path based on permits any node to overwrite the SPF path with a different path based on
its local policy.</t> its local policy.</td>
<td align="left" colspan="1" rowspan="1">This document</td>
<t>1: Strict Shortest Path First (SPF) algorithm based on link m </tr>
etric. <tr>
The algorithm is identical to Algorithm 0 but Algorithm 1 requir <td align="left" colspan="1" rowspan="1">1</td>
es that <td align="left" colspan="1" rowspan="1">Strict Shortest Path Firs
t (SPF) algorithm based on link metric.
The algorithm is identical to Algorithm 0, but Algorithm 1 requi
res that
all nodes along the path will honor the SPF routing decision. Lo cal policy all nodes along the path will honor the SPF routing decision. Lo cal policy
at the node claiming support for Algorithm 1 MUST NOT alter the at the node claiming support for Algorithm 1 <bcp14>MUST NOT</bc
SPF paths computed by Algorithm 1.</t> p14> alter the
SPF paths computed by Algorithm 1.</td>
</list></t> <td align="left" colspan="1" rowspan="1">This document</td>
</section> </tr>
</tbody>
</table>
</section>
</section> </section>
<section anchor="Error-handling" numbered="true" toc="include" removeInRFC="
<section anchor="Implementation" title="Implementation Status"> false" pn="section-9">
<name slugifiedName="name-tlv-sub-tlv-error-handling">TLV/Sub-TLV Error Ha
<t>An implementation survey with seven questions related to the ndling</name>
implementer's support of OSPFv2 Segment Routing was sent to <t pn="section-9-1">For any new TLVs/sub-TLVs defined in this document, if
the OSPF WG list and several known implementers. This section the length is
contains responses from three implementers who completed the survey. invalid, the LSA in which it is advertised is considered malformed and <bcp14>MU
No external means were used to verify the accuracy of the information ST</bcp14> be
submitted by the respondents. The respondents are considered experts ignored. An error <bcp14>SHOULD</bcp14> be logged subject to rate limiting.
on the products they reported on. Additionally, responses were </t>
omitted from implementers who indicated that they have not </section>
implemented the function yet.</t> <section anchor="Security" numbered="true" toc="include" removeInRFC="false"
pn="section-10">
<t>This section will be removed before publication as an RFC.</t> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t>Responses from Nokia (former Alcatel-Lucent):</t> <t pn="section-10-1">With the OSPFv2 Segment Routing extensions defined he
rein,
<t>Link to a web page describing the implementation: OSPFv2 will now program the MPLS data plane <xref target="RFC3031" format=
https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename. "default" sectionFormat="of" derivedContent="RFC3031"/> in addition to the IP
cgi/3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Unicast%2 data plane. Previously, LDP <xref target="RFC5036" format="default" sectio
0Routing%20Protocols%20Guide%20R14.0.R1.pdf</t> nFormat="of" derivedContent="RFC5036"/> or another label distribution
<t>The implementation's level of maturity: Production.</t>
<t>Coverage: We have implemented all sections and have support fo
r the latest draft.</t>
<t>Licensing: Part of the software package that needs to be purch
ased.</t>
<t>Implementation experience: Great spec. We also performed inter
-operability
testing with Cisco's OSPF Segment Routing implementation. </t>
<t>Contact information: wim.henderickx@nokia.com </t>
<t> Responses from Cisco Systems: </t>
<t> Link to a web page describing the implementation:</t>
<t> http://www.segment-routing.net/home/tutorial</t>
<t> The implementation's level of maturity: Production.</t>
<t> Coverage: All sections have been implemented according to the
latest draft.</t>
<t> Licensing: Part of a commercial software package.</t>
<t> Implementation experience: Many aspects of the draft are resu
lt of the
actual implementation experience, as the draft evolved from its i
nitial version
to the current one. Interoperability testing with Alcatel-Lucent
was performed, which confirmed the draft's ability to serve as a
reference for the
implementors.</t>
<t> Contact information: ppsenak@cisco.com </t>
<t> Responses from Juniper: </t>
<t> The implementation's name and/or a link to a web page describ
ing
the implementation:</t>
<t> Feature name is OSPF SPRING</t>
<t> The implementation's level of maturity:
To be released in 16.2 (second half of 2016)</t>
<t> Coverage: All sections implemented except Sections 4, and 6.<
/t>
<t> Licensing: JUNOS Licensing needed.</t>
<t> Implementation experience: NA</t>
<t> Contact information: shraddha@juniper.net </t>
</section>
<section anchor="Security" title="Security Considerations">
<t>With the OSPFv2 segment routing extensions defined herein,
OSPFv2 will now program the MPLS data plane [RFC3031] in addition to the I
P
data plane. Previously, LDP [RFC5036] or another label distribution
mechanism was required to advertise MPLS labels and program the MPLS data plane.</t> mechanism was required to advertise MPLS labels and program the MPLS data plane.</t>
<t pn="section-10-2">In general, the same types of attacks that can be car
<t>In general, the same types of attacks that can be carried out on the IP ried out on the IP
control plane can be carried out on the MPLS control plane resulting in tr affic control plane can be carried out on the MPLS control plane resulting in tr affic
being misrouted in the respective data planes. However, the latter can be more being misrouted in the respective data planes. However, the latter can be more
difficult to detect and isolate.</t> difficult to detect and isolate.</t>
<t pn="section-10-3">Existing security extensions as described in <xref ta
<t>Existing security extensions as described in <xref target="RFC2328"></x rget="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> an
ref> and d
<xref target="RFC7684"></xref> apply to these segment routing extensions. <xref target="RFC7684" format="default" sectionFormat="of" derivedContent
While ="RFC7684"/> apply to these Segment Routing extensions. While
OSPF is under a single administrative domain, there can be deployments wh ere OSPF is under a single administrative domain, there can be deployments wh ere
potential attackers have access to one or more networks in the OSPF routi ng domain. potential attackers have access to one or more networks in the OSPF routi ng domain.
In these deployments, stronger authentication mechanisms such as those sp ecified In these deployments, stronger authentication mechanisms such as those sp ecified
in <xref target="RFC7474"></xref> SHOULD be used.</t> in <xref target="RFC7474" format="default" sectionFormat="of" derivedCont
ent="RFC7474"/> <bcp14>SHOULD</bcp14> be used.</t>
<t>Implementations MUST assure that malformed TLV and Sub-TLV defined in <t pn="section-10-4">Implementations <bcp14>MUST</bcp14> assure that malfo
this document rmed TLVs and sub-TLVs defined in this document
are detected and do not provide a vulnerability for attackers to crash th e OSPFv2 are detected and do not provide a vulnerability for attackers to crash th e OSPFv2
router or routing process. Reception of malformed TLV or Sub-TLV SHOULD b router or routing process. Reception of malformed TLVs or sub-TLVs <bcp14
e counted >SHOULD</bcp14> be counted
and/or logged for further analysis. Logging of malformed TLVs and Sub-TLV and/or logged for further analysis. Logging of malformed TLVs and sub-TLV
s SHOULD s <bcp14>SHOULD</bcp14>
be rate-limited to prevent a Denial of Service (DoS) attack (distributed be rate limited to prevent a Denial of Service (DoS) attack (distributed
or otherwise) or otherwise)
from overloading the OSPF control plane.</t> from overloading the OSPF control plane.</t>
</section>
<section anchor="Contributors" title="Contributors">
<t>The following people gave a substantial contribution to the content
of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, Bruno Dec
raene,
Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to thank Anton Smirnov for his contribution.</t>
<t>Thanks to Acee Lindem for the detail review of the draft, corrections,
as well as discussion about details of the encoding.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-11">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <name slugifiedName="name-references">References</name>
FC.2119.xml"?> <references pn="section-11.1">
<name slugifiedName="name-normative-references">Normative References</na
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R me>
FC.7770.xml"?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <front>
FC.4915.xml"?> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <author initials="S." surname="Bradner" fullname="S. Bradner">
FC.7684.xml"?> <organization showOnFrontPage="true"/>
</author>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <date year="1997" month="March"/>
FC.6845.xml"?> <abstract>
<t>In many standards track documents several words are used to sig
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R nify the requirements in the specification. These words are often capitalized.
FC.8126.xml"?> 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
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R Community, and requests discussion and suggestions for improvements.</t>
FC.7120.xml"?> </abstract>
</front>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <seriesInfo name="BCP" value="14"/>
FC.3101.xml"?> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R </reference>
FC.2328.xml"?> <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2
328" quoteTitle="true" derivedAnchor="RFC2328">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference. <front>
I-D.ietf-spring-segment-routing.xml"?> <title>OSPF Version 2</title>
<author initials="J." surname="Moy" fullname="J. Moy">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference. <organization showOnFrontPage="true"/>
I-D.ietf-spring-segment-routing-ldp-interop.xml"?> </author>
<date year="1998" month="April"/>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference. <abstract>
I-D.ietf-spring-segment-routing-mpls.xml"?> <t>This memo documents version 2 of the OSPF protocol. OSPF is a
link- state routing protocol. [STANDARDS-TRACK]</t>
<?rfc ?> </abstract>
</references> </front>
<seriesInfo name="STD" value="54"/>
<references title="Informative References"> <seriesInfo name="RFC" value="2328"/>
<seriesInfo name="DOI" value="10.17487/RFC2328"/>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R </reference>
FC.7855.xml"?> <reference anchor="RFC3101" target="https://www.rfc-editor.org/info/rfc3
101" quoteTitle="true" derivedAnchor="RFC3101">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R <front>
FC.7474.xml"?> <title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
<author initials="P." surname="Murphy" fullname="P. Murphy">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference. <organization showOnFrontPage="true"/>
I-D.ietf-ospf-ospfv3-segment-routing-extensions.xml"?> </author>
<date year="2003" month="January"/>
<abstract>
<t>This memo documents an optional type of Open Shortest Path Firs
t (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area
(or NSSA). NSSAs are similar to the existing OSPF stub area configuration optio
n but have the additional capability of importing AS external routes in a limite
d fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functio
nal differences between this memo and RFC 1587 are explained in Appendix F. All
differences, while expanding capability, are backward-compatible in nature. Imp
lementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="3101"/>
<seriesInfo name="DOI" value="10.17487/RFC3101"/>
</reference>
<reference anchor="RFC4915" target="https://www.rfc-editor.org/info/rfc4
915" quoteTitle="true" derivedAnchor="RFC4915">
<front>
<title>Multi-Topology (MT) Routing in OSPF</title>
<author initials="P." surname="Psenak" fullname="P. Psenak">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Mirtorabi" fullname="S. Mirtorabi">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Roy" fullname="A. Roy">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Nguyen" fullname="L. Nguyen">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Pillay-Esnault" fullname="P. Pillay-E
snault">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="June"/>
<abstract>
<t>This document describes an extension to Open Shortest Path Firs
t (OSPF) in order to define independent IP topologies called Multi- Topologies (
MTs). The Multi-Topologies extension can be used for computing different paths
for unicast traffic, multicast traffic, different classes of service based on fl
exible criteria, or an in- band network management topology.</t>
<t>An optional extension to exclude selected links from the defaul
t topology is also described. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4915"/>
<seriesInfo name="DOI" value="10.17487/RFC4915"/>
</reference>
<reference anchor="RFC6845" target="https://www.rfc-editor.org/info/rfc6
845" quoteTitle="true" derivedAnchor="RFC6845">
<front>
<title>OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type<
/title>
<author initials="N." surname="Sheth" fullname="N. Sheth">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Wang" fullname="L. Wang">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Zhang" fullname="J. Zhang">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="January"/>
<abstract>
<t>This document describes a mechanism to model a broadcast networ
k as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF
operation. Neighbor discovery and maintenance as well as Link State Advertisem
ent (LSA) database synchronization are performed using the broadcast model, but
the network is represented using the point-to-multipoint model in the router-LSA
s of the routers connected to it. This allows an accurate representation of the
cost of communication between different routers on the network, while maintaini
ng the network efficiency of broadcast operation. This approach is relatively s
imple and requires minimal changes to OSPF.</t>
<t>This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 53
40). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6845"/>
<seriesInfo name="DOI" value="10.17487/RFC6845"/>
</reference>
<reference anchor="RFC7120" target="https://www.rfc-editor.org/info/rfc7
120" quoteTitle="true" derivedAnchor="RFC7120">
<front>
<title>Early IANA Allocation of Standards Track Code Points</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="January"/>
<abstract>
<t>This memo describes the process for early allocation of code po
ints by IANA from registries for which "Specification Required", "RFC
Required", "IETF Review", or "Standards Action" policies apply. Th
is process can be used to alleviate the problem where code point allocation is n
eeded to facilitate desired or required implementation and deployment experience
prior to publication of an RFC, which would normally trigger code point allocat
ion. The procedures in this document are intended to apply only to IETF Stream
documents.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="100"/>
<seriesInfo name="RFC" value="7120"/>
<seriesInfo name="DOI" value="10.17487/RFC7120"/>
</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="RFC7770" target="https://www.rfc-editor.org/info/rfc7
770" quoteTitle="true" derivedAnchor="RFC7770">
<front>
<title>Extensions to OSPF for Advertising Optional Router Capabiliti
es</title>
<author initials="A." surname="Lindem" fullname="A. Lindem" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Shen" fullname="N. Shen">
<organization showOnFrontPage="true"/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Shaffer" fullname="S. Shaffer">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="February"/>
<abstract>
<t>It is useful for routers in an OSPFv2 or OSPFv3 routing domain
to know the capabilities of their neighbors and other routers in the routing dom
ain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising opt
ional router capabilities. The Router Information (RI) Link State Advertisement
(LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented w
ith an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a uni
que LSA type function code. In both protocols, the RI LSA can be advertised at
any of the defined flooding scopes (link, area, or autonomous system (AS)). Thi
s document obsoletes RFC 4970 by providing a revised specification that includes
support for advertisement of multiple instances of the RI LSA and a TLV for fun
ctional capabilities.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7770"/>
<seriesInfo name="DOI" value="10.17487/RFC7770"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations are often coordinated by a central record keeper. For IETF protocols
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</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 MPLS Data Plane</title>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
role="editor">
<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>
<seriesInfo name="RFC" value="8660"/>
<seriesInfo name="DOI" value="10.17487/RFC8660"/>
</reference>
<reference anchor="RFC8661" target="https://www.rfc-editor.org/info/rfc8
661" quoteTitle="true" derivedAnchor="RFC8661">
<front>
<title>Segment Routing Interworking with LDP</title>
<author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C" surname="Filsfils" fullname="Clarence Filsfils"
role="editor">
<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>
<date month="December" year="2019"/>
</front>
<seriesInfo name="RFC" value="8661"/>
<seriesInfo name="DOI" value="10.17487/RFC8661"/>
</reference>
</references>
<references pn="section-11.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<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="RFC5036" target="https://www.rfc-editor.org/info/rfc5
036" quoteTitle="true" derivedAnchor="RFC5036">
<front>
<title>LDP Specification</title>
<author initials="L." surname="Andersson" fullname="L. Andersson" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Minei" fullname="I. Minei" role="edit
or">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Thomas" fullname="B. Thomas" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="October"/>
<abstract>
<t>The architecture for Multiprotocol Label Switching (MPLS) is de
scribed in RFC 3031. A fundamental concept in MPLS is that two Label Switching
Routers (LSRs) must agree on the meaning of the labels used to forward traffic b
etween and through them. This common understanding is achieved by using a set o
f procedures, called a label distribution protocol, by which one LSR informs ano
ther of label bindings it has made. This document defines a set of such procedu
res called LDP (for Label Distribution Protocol) by which LSRs distribute labels
to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5036"/>
<seriesInfo name="DOI" value="10.17487/RFC5036"/>
</reference>
<reference anchor="RFC7474" target="https://www.rfc-editor.org/info/rfc7
474" quoteTitle="true" derivedAnchor="RFC7474">
<front>
<title>Security Extension for OSPFv2 When Using Manual Key Managemen
t</title>
<author initials="M." surname="Bhatia" fullname="M. Bhatia">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Hartman" fullname="S. Hartman">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Zhang" fullname="D. Zhang">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Lindem" fullname="A. Lindem" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="April"/>
<abstract>
<t>The current OSPFv2 cryptographic authentication mechanism as de
fined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- sessi
on replay attacks when using manual keying. Additionally, the existing cryptogr
aphic authentication mechanism does not cover the IP header. This omission can
be exploited to carry out various types of attacks.</t>
<t>This document defines changes to the authentication sequence nu
mber mechanism that will protect OSPFv2 from both inter-session and intra- sessi
on replay attacks when using manual keys for securing OSPFv2 protocol packets.
Additionally, we also describe some changes in the cryptographic hash computatio
n that will eliminate attacks resulting from OSPFv2 not protecting the IP header
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7474"/>
<seriesInfo name="DOI" value="10.17487/RFC7474"/>
</reference>
<reference anchor="RFC7855" target="https://www.rfc-editor.org/info/rfc7
855" quoteTitle="true" derivedAnchor="RFC7855">
<front>
<title>Source Packet Routing in Networking (SPRING) Problem Statemen
t and Requirements</title>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
="editor">
<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="M." surname="Horneffer" fullname="M. Horneffer">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="May"/>
<abstract>
<t>The ability for a node to specify a forwarding path, other than
the normal shortest path, that a particular packet will traverse, benefits a nu
mber of network functions. Source-based routing mechanisms have previously been
specified for network protocols but have not seen widespread adoption. In this
context, the term "source" means "the point at which the explicit route is impo
sed"; therefore, it is not limited to the originator of the packet (i.e., the no
de imposing the explicit route may be the ingress node of an operator's network)
.</t>
<t>This document outlines various use cases, with their requiremen
ts, that need to be taken into account by the Source Packet Routing in Networkin
g (SPRING) architecture for unicast traffic. Multicast use cases and requiremen
ts are out of scope for this document.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7855"/>
<seriesInfo name="DOI" value="10.17487/RFC7855"/>
</reference>
<reference anchor="RFC8666" target="https://www.rfc-editor.org/info/rfc8
666" quoteTitle="true" derivedAnchor="RFC8666">
<front>
<title>OSPFv3 Extensions for Segment Routing</title>
<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>
<date month="December" year="2019"/>
</front>
<seriesInfo name="RFC" value="8666"/>
<seriesInfo name="DOI" value="10.17487/RFC8666"/>
</reference>
</references> </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">We would like to thank Anton Smirnov for his
contribution.</t>
<t pn="section-appendix.a-2">Thanks to Acee Lindem for the detailed review
of the document, corrections,
as well as discussion about details of the encoding.</t>
</section>
<section anchor="Contributors" numbered="false" toc="include" removeInRFC="f
alse" pn="section-appendix.b">
<name slugifiedName="name-contributors">Contributors</name>
<t pn="section-appendix.b-1">The following people gave a substantial contr
ibution to the content
of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, Bruno Dec
raene,
Stephane Litkowski, Igor Milojevic, and Saku Ytti.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author fullname="Peter Psenak" initials="P." role="editor" surname="Psena
k">
<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Apollo Business Center</street>
<street>Mlynske nivy 43</street>
<city>Bratislava</city>
<code>821 09</code>
<country>Slovakia</country>
</postal>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." role="editor" surname="Pr
evidi">
<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Via Del Serafico, 200</street>
<city>Rome</city>
<code>00142</code>
<country>Italy</country>
</postal>
<email>stefano@previdi.net</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<city>Brussels</city>
<region/>
<code/>
<country>Belgium</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization showOnFrontPage="true">RtBrick Inc.</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>hannes@rtbrick.com</email>
</address>
</author>
<author fullname="Rob Shakir" initials="R." surname="Shakir">
<organization showOnFrontPage="true">Google, Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<code>94043</code>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>robjs@google.com</email>
</address>
</author>
<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
<organization showOnFrontPage="true">Nokia</organization>
<address>
<postal>
<street>Copernicuslaan 50</street>
<city>Antwerp</city>
<code>2018</code>
<country>Belgium</country>
</postal>
<email>wim.henderickx@nokia.com</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization showOnFrontPage="true">Apstra, Inc.</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>jefftant.ietf@gmail.com</email>
</address>
</author>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 161 change blocks. 
1235 lines changed or deleted 2231 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/