<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-ospf-segment-routing-extensions-27"ipr="trust200902">indexInclude="true" ipr="trust200902" number="8665" prepTime="2019-12-04T21:10:11" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions-27" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8665" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="OSPF Extensions for Segment Routing">OSPF Extensions for Segment Routing</title> <seriesInfo name="RFC" value="8665" stream="IETF"/> <author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak"><organization>Cisco<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="Previdi"><organization>Cisco<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>Cisco<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>RtBrick<organization showOnFrontPage="true">RtBrick Inc.</organization> <address> <postal> <street/> <city/> <region/> <code/><country></country><country/> </postal> <email>hannes@rtbrick.com</email> </address> </author> <author fullname="Rob Shakir" initials="R." surname="Shakir"><organization>Google,<organization showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <code>94043</code> <region>CA</region><country>US</country><country>United States of America</country> </postal> <email>robjs@google.com</email> </address> </author> <author fullname="Wim Henderickx" initials="W." surname="Henderickx"><organization>Nokia</organization><organization showOnFrontPage="true">Nokia</organization> <address> <postal> <street>Copernicuslaan 50</street> <city>Antwerp</city> <code>2018</code><country>BE</country><country>Belgium</country> </postal> <email>wim.henderickx@nokia.com</email> </address> </author> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura"><organization>Apstra,<organization showOnFrontPage="true">Apstra, Inc.</organization> <address> <postal> <street/> <city/> <region/> <code/><country></country><country/> </postal> <email>jefftant.ietf@gmail.com</email> </address> </author><date/><date month="12" year="2019"/> <area>Routing</area> <workgroup>Open Shortest Path First IGP</workgroup> <keyword>MPLS</keyword> <keyword>SID</keyword> <keyword>IGP</keyword> <keyword>OSPF</keyword> <keyword>Label advertisement</keyword> <keyword>Segment Routing</keyword><abstract> <t>Segment<abstract pn="section-abstract"> <t pn="section-abstract-1">Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topologicalsub-paths,subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).</t><t>This draft<t pn="section-abstract-2">This document describes the OSPFv2 extensions required for Segment Routing.</t> </abstract><note title="Requirements Language"> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",<boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and"OPTIONAL"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 thisdocument aredocument, any errata, and how to provide feedback on it may beinterpretedobtained at <eref target="https://www.rfc-editor.org/info/rfc8665" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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<xref target="RFC2119"></xref>.</t> </note>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" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.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 derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>. <xref 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 derivedContent="" format="title" sectionFormat="of" target="name-segment-routing-identifiers">Segment Routing Identifiers</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref 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 derivedContent="" format="title" sectionFormat="of" target="name-segment-routing-capabilitie">Segment Routing Capabilities</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref 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 derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sid-label-range-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 derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sr-local-block-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 derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-srms-preference-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 derivedContent="" format="title" sectionFormat="of" target="name-ospf-extended-prefix-range-">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 derivedContent="" format="title" sectionFormat="of" target="name-prefix-sid-sub-tlv">Prefix-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 derivedContent="" format="title" sectionFormat="of" target="name-adjacency-segment-identifie">Adjacency Segment Identifier (Adj-SID)</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-adj-sid-sub-tlv">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 derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-lan-adj-sid-sub-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 derivedContent="" format="title" sectionFormat="of" target="name-elements-of-procedure">Elements of Procedure</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-intra-area-segment-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 derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-inter-area-segment-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 derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-segment-routing-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 derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>. <xref 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="section-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"><xref derivedContent="7.4.1" format="counter" sectionFormat="of" target="section-7.4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-advertisement-of-adj-sid-on">Advertisement of Adj-SID on Point-to-Point Links</xref></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"><xref derivedContent="7.4.2" format="counter" sectionFormat="of" target="section-7.4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-adjacency-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 derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ospf-router-information-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 derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-extended-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 derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-extended-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 derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-extended-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 derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>. <xref 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 derivedContent="" format="title" sectionFormat="of" target="name-tlv-sub-tlv-error-handling">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 derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" 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 derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-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 derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.13"> <t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t> </li> <li pn="section-toc.1-1.14"> <t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <sectiontitle="Introduction"> <t>Segmentnumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t pn="section-1-1">Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topologicalsub-paths,subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). Prefix segments represent an ECMP-awareshortest-pathshortest path to a prefix (or a node), as per 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 typically a multi-hop path while an adjacency segment, in most cases, is a one-hop path. SR'scontrol-planecontrol plane can be applied to both IPv6 and MPLSdata-planes,data planes, and it does not require any additionalsignallingsignaling (other than IGP extensions). The IPv6 data plane is out of the scope of thisspecification -specification; it is not applicable toOSPFv2OSPFv2, which only supports the IPv4address-family.address family. When used in MPLS networks, SR paths do not require any LDP or RSVP-TEsignalling.signaling. However, SR can interoperate in the presence of LSPs established with RSVP or LDP.</t><t>There<t pn="section-1-2">There are additional segment types, e.g., BindingSIDSegment Identifier (SID) defined in <xreftarget="I-D.ietf-spring-segment-routing"/>.</t> <t>This drafttarget="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t> <t pn="section-1-3">This document describes the OSPF extensions required for Segment Routing.</t><t>Segment<t pn="section-1-4">Segment Routing architecture is described in <xreftarget="I-D.ietf-spring-segment-routing"/>.</t> <t>Segmenttarget="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</t> <t pn="section-1-5">Segment Routing use cases are described in <xreftarget="RFC7855"/>.</t>target="RFC7855" format="default" sectionFormat="of" derivedContent="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>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> </section> <sectiontitle="Segmentnumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-segment-routing-identifiers">Segment RoutingIdentifiers"> <t>SegmentIdentifiers</name> <t pn="section-2-1">Segment Routing defines various types of Segment Identifiers (SIDs): Prefix-SID,Adjacency-SID,Adjacency SID, LAN Adjacency SID, and Binding SID.</t><t>Extended<t pn="section-2-2">Extended Prefix/Link OpaqueLSAsLink State Advertisements (LSAs) defined in <xreftarget="RFC7684"/>target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> are used for advertisements of the various SID types.</t> <section anchor="SIDLABEL"title="SID/Label Sub-TLV"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2.1"> <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 orSub-TLVssub-TLVs defined 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 the followingformat:<figure> <artwork>format:</t> <artwork name="" type="" align="left" alt="" pn="section-2.1-2"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label (variable) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: </artwork> </figure><list style="hanging"> <t>Type: 1</t> <t>Length: Variable, 3+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> <t pn="section-2.1-3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-2.1-4"> <li pn="section-2.1-4.1"> <dl newline="false" spacing="normal" pn="section-2.1-4.1.1"> <dt pn="section-2.1-4.1.1.1">Type:</dt> <dd pn="section-2.1-4.1.1.2">1</dd> <dt pn="section-2.1-4.1.1.3">Length:</dt> <dd pn="section-2.1-4.1.1.4">3 or 4octet</t> <t>SID/Label: Ifoctets</dd> <dt pn="section-2.1-4.1.1.5">SID/Label:</dt> <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 the 20 rightmost bits represent a label. If the length is set to 4, then the value represents a 32-bit SID.</t><t>The receiving router MUST ignore the SID/Label Sub-TLV if the length is other then 3 or 4.</t> </list></t></dd> </dl> </li> </ul> </section> </section> <section anchor="SRCAP"title="Segmentnumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-segment-routing-capabilitie">Segment RoutingCapabilities"> <t>SegmentCapabilities</name> <t pn="section-3-1">Segment Routing requires some additional router capabilities to be advertised to other routers in the area.</t><t>These<t pn="section-3-2">These SR capabilities are advertised in the Router Information Opaque LSA (defined in <xreftarget="RFC7770"/>).target="RFC7770" format="default" sectionFormat="of" derivedContent="RFC7770"/>). The TLVs defined below are applicable to both OSPFv2 and OSPFv3; see also <xreftarget="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/></t>target="RFC8666" format="default" sectionFormat="of" derivedContent="RFC8666"/>.</t> <section anchor="SRALGO"title="SR-Algorithm TLV"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-sr-algorithm-tlv">SR-Algorithm TLV</name> <t pn="section-3.1-1">The SR-Algorithm TLV is a top-level TLV of the Router Information Opaque LSA (defined in <xreftarget="RFC7770"/>).</t> <t>Thetarget="RFC7770" format="default" sectionFormat="of" derivedContent="RFC7770"/>).</t> <t pn="section-3.1-2">The SR-Algorithm TLV is optional. ItSHOULD<bcp14>SHOULD</bcp14> only be advertised once in the Router Information Opaque LSA. If the SR-Algorithm TLV is not advertised by the node, such a node is considered as not beingsegment routingSegment Routing capable.</t><t><t pn="section-3.1-3"> An SR Router can use various algorithms when calculating reachability to OSPF routers or prefixes in an OSPF area. Examples of these algorithms aremetric basedmetric-based Shortest Path First (SPF), various flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a router to advertise the algorithms currently used by the router to other routers in an OSPF area. The SR-Algorithm TLV has the following format:<figure> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-3.1-4"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm 1 | Algorithm... | Algorithm n | | +- -+ | | + +where:</artwork> </figure><list style="hanging"> <t>Type: 8</t> <t>Variable,</artwork> <t pn="section-3.1-5">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-3.1-6"> <li pn="section-3.1-6.1"> <dl newline="false" spacing="normal" pn="section-3.1-6.1.1"> <dt pn="section-3.1-6.1.1.1">Type:</dt> <dd pn="section-3.1-6.1.1.2">8</dd> <dt pn="section-3.1-6.1.1.3">Length:</dt> <dd pn="section-3.1-6.1.1.4">Variable, in octets,dependentdepending on the number of algorithmsadvertised.</t> <t> Algorithm: Singleadvertised</dd> <dt pn="section-3.1-6.1.1.5">Algorithm:</dt> <dd pn="section-3.1-6.1.1.6"> <t pn="section-3.1-6.1.1.6.1">Single octet identifying the algorithm. The following values are defined by thisdocument:<list style="hanging"> <t>0: Shortestdocument:</t> <dl newline="false" spacing="normal" indent="6" pn="section-3.1-6.1.1.6.2"> <dt pn="section-3.1-6.1.1.6.2.1">0:</dt> <dd pn="section-3.1-6.1.1.6.2.2">Shortest Path First (SPF) algorithm based on link metric. This is the standard shortest path algorithm as computed by the OSPF protocol. 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 its local policy. If the SR-Algorithm TLV is advertised, Algorithm 0MUST<bcp14>MUST</bcp14> beincluded.</t> <t>1: Strictincluded.</dd> <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 (SPF) algorithm based on link metric. The algorithm is identical to Algorithm00, but Algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy at the node claiming support for Algorithm 1MUST NOT<bcp14>MUST NOT</bcp14> alter the SPF paths computed by Algorithm1.</t> </list></t> </list></t> <t>When1.</dd> </dl> </dd> </dl> </li> </ul> <t pn="section-3.1-7">When multiple SR-Algorithm TLVs are received from a given router, the receiverMUST<bcp14>MUST</bcp14> use the first occurrence of the TLV in the Router Information Opaque LSA. If the SR-Algorithm TLV appears in multiple Router Information Opaque LSAs that have different flooding scopes, the SR-Algorithm TLV in the Router Information Opaque LSA with the area-scoped flooding scopeMUST<bcp14>MUST</bcp14> be used. If the SR-Algorithm TLV appears in multiple Router Information Opaque LSAs that have the same flooding scope, the SR-Algorithm TLV in the Router Information (RI) Opaque LSA with the numerically smallest Instance IDMUST<bcp14>MUST</bcp14> be used and subsequent instances of the SR-Algorithm TLVMUST<bcp14>MUST</bcp14> be ignored.</t><t>The<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 SR-Algorithm TLV advertisement, area-scoped flooding isREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> </section> <section anchor="SIDRANGE"title="SID/Label Range TLV"> <t>Prefix SIDs MAYnumbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-sid-label-range-tlv">SID/Label Range TLV</name> <t pn="section-3.2-1">Prefix-SIDs <bcp14>MAY</bcp14> be advertised inathe form of an index as described in <xreftarget="PREFIXSID"/>.target="PREFIXSID" format="default" sectionFormat="of" derivedContent="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 such SID/Label space.</t><t>The<t pn="section-3.2-2">The SID/Label Range TLV is a top-level TLV of the Router Information Opaque LSA (defined in <xreftarget="RFC7770"/>).</t> <t>Thetarget="RFC7770" format="default" sectionFormat="of" derivedContent="RFC7770"/>).</t> <t pn="section-3.2-3">The SID/Label Range TLVMAY<bcp14>MAY</bcp14> appear multiple times and has the followingformat:<figure> <artwork>format:</t> <artwork name="" type="" align="left" alt="" pn="section-3.2-4"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | ++ where:</artwork> </figure><list style="hanging"> <t>Type: 9</t> <t>Length: Variable,+</artwork> <t pn="section-3.2-5">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-3.2-6"> <li pn="section-3.2-6.1"> <dl newline="false" spacing="normal" pn="section-3.2-6.1.1"> <dt pn="section-3.2-6.1.1.1">Type:</dt> <dd pn="section-3.2-6.1.1.2">9</dd> <dt pn="section-3.2-6.1.1.3">Length:</dt> <dd pn="section-3.2-6.1.1.4">Variable, in octets,dependentdepending onSub-TLVs.</t> <t>Range Size: 3-octetthe sub-TLVs</dd> <dt pn="section-3.2-6.1.1.5">Range Size:</dt> <dd pn="section-3.2-6.1.1.6">3-octet SID/label range size (i.e., the number of SIDs or labels in the range including the first SID/label). ItMUST<bcp14>MUST</bcp14> be greater than0.</t> <t>Reserved: SHOULD0.</dd> <dt pn="section-3.2-6.1.1.7">Reserved:</dt> <dd pn="section-3.2-6.1.1.8"> <bcp14>SHOULD</bcp14> be set to 0 on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> </list></t> <t>Initially,reception</dd> </dl> </li> </ul> <t pn="section-3.2-7">Initially, the only supportedSub-TLVsub-TLV is the SID/Label Sub-TLV as defined in <xreftarget="SIDLABEL"/>.target="SIDLABEL" format="default" sectionFormat="of" derivedContent="Section 2.1"/>. The SID/Label Sub-TLVMUST<bcp14>MUST</bcp14> be included in the SID/Label Range TLV. The SID/Label advertised in the SID/Label Sub-TLV represents the first SID/Label in the advertised range. </t><t>Only<t pn="section-3.2-8">Only a single SID/Label Sub-TLVMAY<bcp14>MAY</bcp14> be advertised in the SID/Label Range TLV. If morethenthan one SID/LabelSub-TLVs areSub-TLV is present, the SID/Label Range TLVMUST<bcp14>MUST</bcp14> be ignored.</t><t>Multiple<t pn="section-3.2-9">Multiple occurrences of the SID/Label Range TLVMAY<bcp14>MAY</bcp14> beadvertised,advertised in order to advertise multiple ranges. In suchcase:<list style="symbols"> <t>Thea case:</t> <ul spacing="normal" bare="false" empty="false" pn="section-3.2-10"> <li pn="section-3.2-10.1">The originating routerMUST<bcp14>MUST</bcp14> encode each range into a different SID/Label Range TLV.</t> <t>The</li> <li pn="section-3.2-10.2">The originating router decides the order in which the set of SID/Label Range TLVs are advertised inside the Router Information Opaque LSA. The originating routerMUST<bcp14>MUST</bcp14> ensure the order is the same after a graceful restart (using checkpointing,non-volatilenonvolatile storage, or any other mechanism) in order toassureensure theSID/labelSID/Label range and SID index correspondence is preserved across gracefulrestarts.</t> <t>restarts.</li> <li pn="section-3.2-10.3"> The receiving routerMUST<bcp14>MUST</bcp14> adhere to the order in which the ranges are advertised when calculating aSID/labelSID/Label from a SIDindex.</t> <t>Theindex.</li> <li pn="section-3.2-10.4">The originating routerMUST NOT<bcp14>MUST NOT</bcp14> advertise overlappingranges.</t> <t>Whenranges.</li> <li pn="section-3.2-10.5">When a router receives multiple overlapping ranges, itMUST<bcp14>MUST</bcp14> conform to the procedures defined in <xreftarget="I-D.ietf-spring-segment-routing-mpls"/>.</t> </list></t> <t>Thetarget="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>.</li> </ul> <t pn="section-3.2-11">The following example illustrates the advertisement of multipleranges:<figure suppress-title="true"> <artwork> Theranges.</t> <t pn="section-3.2-12">The originating router advertises the followingranges:ranges:</t> <artwork name="" type="" align="left" alt="" pn="section-3.2-13"> 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:500 The500</artwork> <t pn="section-3.2-14">The receiving routers concatenate the ranges and build the Segment Routing Global Block (SRGB) asfollows:follows:</t> <artwork name="" type="" align="left" alt="" pn="section-3.2-15"> SRGB = [100, 199] [1000, 1099] [500,599] The599]</artwork> <t pn="section-3.2-16">The indexes span multipleranges: index=0ranges:</t> <artwork name="" type="" align="left" alt="" pn="section-3.2-17"> index 0 means label 100 ... index 99 means label 199 index 100 means label 1000 index 199 means label 1099 ... index 200 means label 500... </artwork> </figure></t> <t>The...</artwork> <t pn="section-3.2-18">The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). For the purpose of SID/Label Range TLV advertisement, area-scoped flooding isREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> </section> <section anchor="SRLB"title="SRnumbered="true" toc="include" removeInRFC="false" pn="section-3.3"> <name slugifiedName="name-sr-local-block-tlv">SR Local BlockTLV"> <t>TheTLV</name> <t pn="section-3.3-1">The SR Local Block TLV (SRLB TLV) contains the range of labels the node has reserved forlocalLocal SIDs. SIDs from the SRLBMAY<bcp14>MAY</bcp14> be used forAdjacency-SIDs,Adjacency SIDs but also by components other than the OSPF protocol. As an example, an application or a controller can instruct the router to allocate a specificlocalLocal SID. Some controllers or applications can use the control plane to discover the available set oflocalLocal SIDs on a particular router. In such cases, the SRLB is advertised in the control plane. The requirement to advertise the SRLB is further described in <xreftarget="I-D.ietf-spring-segment-routing-mpls"/>.target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>. The SRLB TLV is used to advertise the SRLB.</t><t>The<t pn="section-3.3-2">The SRLB TLV is a top-level TLV of the Router Information Opaque LSA (defined in <xreftarget="RFC7770"/>).</t> <t>Thetarget="RFC7770" format="default" sectionFormat="of" derivedContent="RFC7770"/>).</t> <t pn="section-3.3-3">The SRLB TLVMAY<bcp14>MAY</bcp14> appear multiple times in the Router Information Opaque LSA and has the followingformat:<figure> <artwork>format:</t> <artwork name="" type="" align="left" alt="" pn="section-3.3-4"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | ++ where:</artwork> </figure> <list style="hanging"> <t>Type: 14</t> <t>Length: Variable,+</artwork> <t pn="section-3.3-5">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-3.3-6"> <li pn="section-3.3-6.1"> <dl newline="false" spacing="normal" pn="section-3.3-6.1.1"> <dt pn="section-3.3-6.1.1.1">Type:</dt> <dd pn="section-3.3-6.1.1.2">14</dd> <dt pn="section-3.3-6.1.1.3">Length:</dt> <dd pn="section-3.3-6.1.1.4">Variable, in octets,dependentdepending onSub-TLVs.</t> <t>Range Size: 3-octet SID/labelthe sub-TLVs</dd> <dt pn="section-3.3-6.1.1.5">Range Size:</dt> <dd pn="section-3.3-6.1.1.6">3-octet SID/Label range size (i.e., the number of SIDs or labels in the range including the firstSID/label).SID/Label). ItMUST<bcp14>MUST</bcp14> be greater than0.</t> <t>Reserved: SHOULD0.</dd> <dt pn="section-3.3-6.1.1.7">Reserved:</dt> <dd pn="section-3.3-6.1.1.8"> <bcp14>SHOULD</bcp14> be set to 0 on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> </list></t> <t>Initially,reception</dd> </dl> </li> </ul> <t pn="section-3.3-7">Initially, the only supportedSub-TLVsub-TLV is the SID/Label Sub-TLV as defined in <xreftarget="SIDLABEL"/>.target="SIDLABEL" format="default" sectionFormat="of" derivedContent="Section 2.1"/>. The SID/Label Sub-TLVMUST<bcp14>MUST</bcp14> be included in the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV represents the first SID/Label in the advertised range.</t><t>Only<t pn="section-3.3-8">Only a single SID/Label Sub-TLVMAY<bcp14>MAY</bcp14> be advertised in the SRLB TLV. If morethenthan one SID/LabelSub-TLVs areSub-TLV is present, the SRLB TLVMUST<bcp14>MUST</bcp14> be ignored.</t><t>The<t pn="section-3.3-9">The originating routerMUST NOT<bcp14>MUST NOT</bcp14> advertise overlapping ranges.</t><t>Each<t pn="section-3.3-10">Each time a SID from the SRLB is allocated, itSHOULD<bcp14>SHOULD</bcp14> also be reported to all 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 required to avoid collisions between allocation instructions.</t><t>Within<t pn="section-3.3-11">Within the context of OSPF, the reporting oflocalLocal SIDs is done through OSPFSub-TLVssub-TLVs, such as theAdjacency-SIDAdjacency SID (<xreftarget="ADJSID"/>).target="ADJSID" format="default" sectionFormat="of" derivedContent="Section 6"/>). However, the reporting of allocatedlocalLocal SIDs can also be done through other means andprotocolsprotocols, which are outside the scope of this document.</t><t>A<t pn="section-3.3-12">A router advertising the SRLB TLVMAY<bcp14>MAY</bcp14> also have other label ranges, outside of the SRLB, used for its local allocation purposeswhich areand not advertised in the SRLB TLV. For example, it is possible that anAdjacency-SIDAdjacency SID is allocated using a local label that is not part of the SRLB.</t><t>The<t pn="section-3.3-13">The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). For the purpose of SRLB TLV advertisement, area-scoped flooding isREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> </section> <section anchor="SRMS-Pref"title="SRMSnumbered="true" toc="include" removeInRFC="false" pn="section-3.4"> <name slugifiedName="name-srms-preference-tlv">SRMS PreferenceTLV"> <t>TheTLV</name> <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. The role of an SRMS is described in <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>.target="RFC8661" format="default" sectionFormat="of" derivedContent="RFC8661"/>. SRMS preference is defined in <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t> <t>Thetarget="RFC8661" format="default" sectionFormat="of" derivedContent="RFC8661"/>.</t> <t pn="section-3.4-2">The SRMS Preference TLV is a top-level TLV of the Router Information Opaque LSA (defined in <xreftarget="RFC7770"/>).</t> <t>Thetarget="RFC7770" format="default" sectionFormat="of" derivedContent="RFC7770"/>).</t> <t pn="section-3.4-3">The SRMS Preference TLVMAY<bcp14>MAY</bcp14> only be advertised once in the Router Information Opaque LSA and has the followingformat:<figure> <artwork>format:</t> <artwork name="" type="" align="left" alt="" pn="section-3.4-4"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference | Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:</artwork> </figure> <list style="hanging"> <t>Type: 15</t> <t>Length: 4 octets</t> <t>Preference: 1 octet.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> <t pn="section-3.4-5">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-3.4-6"> <li pn="section-3.4-6.1"> <dl newline="false" spacing="normal" pn="section-3.4-6.1.1"> <dt pn="section-3.4-6.1.1.1">Type:</dt> <dd pn="section-3.4-6.1.1.2">15</dd> <dt pn="section-3.4-6.1.1.3">Length:</dt> <dd pn="section-3.4-6.1.1.4">4 octets</dd> <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 value from 0 to255.</t> <t>Reserved: SHOULD255</dd> <dt pn="section-3.4-6.1.1.7">Reserved:</dt> <dd pn="section-3.4-6.1.1.8"> <bcp14>SHOULD</bcp14> be set to 0 on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> </list></t> <t>Whenreception</dd> </dl> </li> </ul> <t pn="section-3.4-7">When multiple SRMS Preference TLVs are received from a given router, the receiverMUST<bcp14>MUST</bcp14> use the first occurrence of the TLV in the Router Information Opaque LSA. If the SRMS Preference TLV appears in multiple Router Information Opaque LSAs that have different flooding scopes, the SRMS Preference TLV in the Router Information Opaque LSA with the narrowest flooding scopeMUST<bcp14>MUST</bcp14> be used. If the SRMS Preference TLV appears in multiple Router Information Opaque LSAs that have the same flooding scope, the SRMS Preference TLV in the Router Information Opaque LSA with the numerically smallest Instance IDMUST<bcp14>MUST</bcp14> be used and subsequent instances of the SRMS Preference TLVMUST<bcp14>MUST</bcp14> be ignored.</t><t>The<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 Preference TLV advertisement, AS-scoped floodingSHOULD<bcp14>SHOULD</bcp14> be used. This is because SRMS servers can be located in a different areathenthan consumers of the SRMS advertisements. If the SRMS advertisements from the SRMS server are only used inside the SRMS server's area, area-scoped floodingMAY<bcp14>MAY</bcp14> be used.</t> </section> </section> <section anchor="PFXRANGE"title="OSPFnumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-ospf-extended-prefix-range-">OSPF Extended Prefix RangeTLV"> <t>InTLV</name> <t pn="section-4-1">In somecasescases, it is useful to advertise attributes for a range of prefixes. TheSegment RoutingSR Mapping Server, which is described in <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>,target="RFC8661" format="default" sectionFormat="of" derivedContent="RFC8661"/>, is an example where we need a single advertisement to advertise SIDs for multiple prefixes from a contiguous address range.</t><t>The<t pn="section-4-2">The OSPF Extended Prefix Range TLV, which is atop leveltop-level TLV of the Extended Prefix LSA described in <xreftarget="RFC7684"/>target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> is defined for this purpose.</t><t>Multiple<t pn="section-4-3">Multiple OSPF Extended Prefix Range TLVsMAY<bcp14>MAY</bcp14> be advertised in each OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a single OSPF Extended Prefix Opaque LSAMUST<bcp14>MUST</bcp14> have the same flooding scope. The OSPF Extended Prefix Range TLV has the followingformat: <figure> <artwork>format:</t> <artwork name="" type="" align="left" alt="" pn="section-4-4"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | AF | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | |where:</artwork></figure><list style="hanging"> <t>Type: 2</t> <t>Length: Variable,<t pn="section-4-5">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-4-6"> <li pn="section-4-6.1"> <dl newline="false" spacing="normal" pn="section-4-6.1.1"> <dt pn="section-4-6.1.1.1">Type:</dt> <dd pn="section-4-6.1.1.2">2</dd> <dt pn="section-4-6.1.1.3">Length:</dt> <dd pn="section-4-6.1.1.4">Variable, in octets,dependentdepending onSub-TLVs.</t> <t>Prefix length: Lengththe sub-TLVs</dd> <dt pn="section-4-6.1.1.5">Prefix Length:</dt> <dd pn="section-4-6.1.1.6">Length of prefix inbits.</t> <t>AF: Addressbits</dd> <dt pn="section-4-6.1.1.7">AF:</dt> <dd pn="section-4-6.1.1.8">Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for futureextension.</t> <t>Range size: Representsextension.</dd> <dt pn="section-4-6.1.1.9">Range Size:</dt> <dd pn="section-4-6.1.1.10">Represents the number of prefixes that are covered by the advertisement. The Range SizeMUST NOT<bcp14>MUST NOT</bcp14> exceed the number of prefixes that could be satisfied by theprefix lengthPrefix Length without including the IPv4 multicast address range(224.0.0.0/3).</t> <t>Flags: Single octet(224.0.0.0/3).</dd> <dt pn="section-4-6.1.1.11">Flags:</dt> <dd pn="section-4-6.1.1.12"> <t pn="section-4-6.1.1.12.1">Single-octet field. The following flags aredefined: <figure align="center"> <artwork>defined:</t> <artwork name="" type="" align="left" alt="" pn="section-4-6.1.1.12.2"> 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |IA| | | | | | | |+--+--+--+--+--+--+--+--+ where:</artwork> </figure><list style="hanging"> <t>IA-Flag: Inter-Area flag.+--+--+--+--+--+--+--+--+</artwork> <t pn="section-4-6.1.1.12.3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-4-6.1.1.12.4"> <li pn="section-4-6.1.1.12.4.1"> <dl newline="false" spacing="normal" pn="section-4-6.1.1.12.4.1.1"> <dt pn="section-4-6.1.1.12.4.1.1.1">IA-Flag:</dt> <dd pn="section-4-6.1.1.12.4.1.1.2"> <t pn="section-4-6.1.1.12.4.1.1.2.1">Inter-Area Flag. If set, advertisement is of inter-area type. AnABRArea Border Router (ABR) that is advertising the OSPF Extended Prefix Range TLV between areasMUST<bcp14>MUST</bcp14> set this bit. </t><t>This<t pn="section-4-6.1.1.12.4.1.1.2.2">This bit is used to prevent redundant flooding of Prefix Range TLVs between areas asfollows: <list style="hanging"> <t>follows:</t> <ul empty="true" bare="false" spacing="normal" pn="section-4-6.1.1.12.4.1.1.2.3"> <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"> An ABR only propagates an inter-area Prefix Range advertisement from the backbone area to connectednon-backbonenonbackbone areas if the advertisement is considered to be the best one. The following rules are used to select the best range from the set of advertisements for the same PrefixRange: <list style="hanging"> <t> AnRange:</t> <ul empty="true" bare="false" spacing="normal" pn="section-4-6.1.1.12.4.1.1.2.3.1.2"> <li pn="section-4-6.1.1.12.4.1.1.2.3.1.2.1">An ABR always prefers intra-area Prefix Range advertisements over inter-areaadvertisements.</t> <t> Anadvertisements.</li> <li pn="section-4-6.1.1.12.4.1.1.2.3.1.2.2">An ABR does not consider inter-area Prefix Range advertisements coming fromnon-backbone areas.</t> </list></t> </list></t> </list></t> <t>Reserved: SHOULDnonbackbone areas.</li> </ul> </li> </ul> </dd> </dl> </li> </ul> </dd> <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 andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> <t>Address Prefix: Forreception</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 thisspecification.</t> </list></t>specification.</dd> </dl> </li> </ul> </section> <section anchor="PREFIXSID"title="Prefix SID Sub-TLV"> <t>The Prefix SIDnumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-prefix-sid-sub-tlv">Prefix-SID Sub-TLV</name> <t pn="section-5-1">The Prefix-SID Sub-TLV is aSub-TLVsub-TLV of the OSPF Extended Prefix TLV described in <xreftarget="RFC7684"/>target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> and the OSPF Extended Prefix Range TLV described in <xreftarget="PFXRANGE"/>.target="PFXRANGE" format="default" sectionFormat="of" derivedContent="Section 4"/>. ItMAY<bcp14>MAY</bcp14> appear more than once in the parent TLV and has the following format:<figure> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-5-2"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | MT-ID | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Index/Label (variable) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where:</artwork> </figure><list style="hanging"> <t>Type: 2</t> <t>Length: 7+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> <t pn="section-5-3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-5-4"> <li pn="section-5-4.1"> <dl newline="false" spacing="normal" pn="section-5-4.1.1"> <dt pn="section-5-4.1.1.1">Type:</dt> <dd pn="section-5-4.1.1.2">2</dd> <dt pn="section-5-4.1.1.3">Length:</dt> <dd pn="section-5-4.1.1.4">7 or 8 octets,dependentdepending on theV-flag</t> <t>Flags: Single octetV-Flag</dd> <dt pn="section-5-4.1.1.5">Flags:</dt> <dd pn="section-5-4.1.1.6"> <t pn="section-5-4.1.1.6.1">Single-octet field. The following flags are defined:<figure align="center"> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-5-4.1.1.6.2"> 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | |NP|M |E |V |L | | |+--+--+--+--+--+--+--+--+ where:</artwork> </figure><list style="hanging"> <t>NP-Flag: No-PHP flag.+--+--+--+--+--+--+--+--+</artwork> <t pn="section-5-4.1.1.6.3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-5-4.1.1.6.4"> <li pn="section-5-4.1.1.6.4.1"> <dl newline="false" spacing="normal" pn="section-5-4.1.1.6.4.1.1"> <dt pn="section-5-4.1.1.6.4.1.1.1">NP-Flag:</dt> <dd pn="section-5-4.1.1.6.4.1.1.2">No-PHP (Penultimate Hop Popping) Flag. If set, then the penultimate hopMUST NOT<bcp14>MUST NOT</bcp14> pop the Prefix-SID before delivering packets to the node that advertised thePrefix-SID.</t> <t>M-Flag: MappingPrefix-SID.</dd> <dt pn="section-5-4.1.1.6.4.1.1.3">M-Flag:</dt> <dd pn="section-5-4.1.1.6.4.1.1.4">Mapping Server Flag. If set, the SID was advertised bya Segment Routingan SR Mapping Server as described in <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t> <t>E-Flag: Explicit-Nulltarget="RFC8661" format="default" sectionFormat="of" derivedContent="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 set, any upstream neighbor of the Prefix-SID originatorMUST<bcp14>MUST</bcp14> replace the Prefix-SID with theExplicit-NULLExplicit NULL label (0 for IPv4) before forwarding thepacket.</t> <t>V-Flag: Value/Indexpacket.</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 carries anindex.</t> <t>L-Flag: Local/Globalindex.</dd> <dt pn="section-5-4.1.1.6.4.1.1.9">L-Flag:</dt> <dd pn="section-5-4.1.1.6.4.1.1.10">Local/Global Flag. If set, then the value/index carried by the Prefix-SID has local significance. If not set, then the value/index carried by thisSub-TLVsub-TLV has globalsignificance.</t> <t>Other bits: Reserved.significance.</dd> <dt pn="section-5-4.1.1.6.4.1.1.11">Other bits:</dt> <dd pn="section-5-4.1.1.6.4.1.1.12">Reserved. TheseMUST<bcp14>MUST</bcp14> be zero when sent and are ignored whenreceived.</t> </list></t> <t>Reserved: SHOULDreceived.</dd> </dl> </li> </ul> </dd> <dt pn="section-5-4.1.1.7">Reserved:</dt> <dd pn="section-5-4.1.1.8"> <bcp14>SHOULD</bcp14> be set to 0 on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> <t>MT-ID: Multi-Topologyreception</dd> <dt pn="section-5-4.1.1.9">MT-ID:</dt> <dd pn="section-5-4.1.1.10">Multi-Topology ID (as defined in <xreftarget="RFC4915"/>).</t> <t>Algorithm: Singletarget="RFC4915" format="default" sectionFormat="of" derivedContent="RFC4915"/>)</dd> <dt pn="section-5-4.1.1.11">Algorithm:</dt> <dd pn="section-5-4.1.1.12"> <t pn="section-5-4.1.1.12.1">Single octet identifying the algorithm the Prefix-SID is associated with as defined in <xreftarget="SRALGO"/>.</t> <t>Atarget="SRALGO" format="default" sectionFormat="of" derivedContent="Section 3.1"/></t> <t pn="section-5-4.1.1.12.2">A router receiving a Prefix-SID from a remote node and with an algorithm value thatsuchthe remote node has not advertised in the SR-AlgorithmSub-TLVTLV (<xreftarget="SRALGO"/>) MUSTtarget="SRALGO" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) <bcp14>MUST</bcp14> ignore the Prefix-SID Sub-TLV.</t><t>SID/Index/Label: According</dd> <dt pn="section-5-4.1.1.13">SID/Index/Label:</dt> <dd pn="section-5-4.1.1.14"> <t pn="section-5-4.1.1.14.1">According to theVV- andL flags,L-Flags, it contains:<list style="hanging"> <t>V-flag</t> <ul empty="true" bare="false" spacing="normal" pn="section-5-4.1.1.14.2"> <li pn="section-5-4.1.1.14.2.1">V-Flag is set to 0 andL-flagL-Flag is set to 0: The SID/Index/Label field is a4 octet4-octet index defining the offset in the SID/Label space advertised by thisrouter</t> <t>V-flagrouter.</li> <li pn="section-5-4.1.1.14.2.2">V-Flag is set to 1 andL-flagL-Flag is set to 1: The SID/Index/Label field is a3 octet3-octet local label where the 20 rightmost bits are used for encoding the labelvalue.</t> <t>Allvalue.</li> <li pn="section-5-4.1.1.14.2.3">All other combinations ofV-flagV-Flag andL-flagL-Flag are invalid and any SIDadvertisementAdvertisement received with an invalid setting forVV- andL flags MUSTL-Flags <bcp14>MUST</bcp14> beignored.</t> </list></t> </list></t> <t>Ifignored.</li> </ul> </dd> </dl> </li> </ul> <t pn="section-5-5">If an OSPF router advertises multiple Prefix-SIDs for the same prefix,topologytopology, and algorithm, all of themMUST<bcp14>MUST</bcp14> be ignored.</t><t>When<t pn="section-5-6">When calculating the outgoing label for the prefix, the routerMUST<bcp14>MUST</bcp14> take into account, as described below, theE, NPE-, NP-, andM flagsM-Flags advertised by the next-hop router if that router advertised the SID for the prefix. ThisMUST<bcp14>MUST</bcp14> be done regardless of whether the next-hop router contributes to the best path to the prefix.</t><t>The<t pn="section-5-7">The NP-Flag (No-PHP)MUST<bcp14>MUST</bcp14> be set and theE-flag MUSTE-Flag <bcp14>MUST</bcp14> be clear for Prefix-SIDs allocated to inter-area prefixes that are originated by the ABR based on intra-area or inter-area reachability betweenareas,areas unless the advertised prefix is directly attached to the ABR.</t><t>The<t pn="section-5-8">The NP-Flag (No-PHP)MUST<bcp14>MUST</bcp14> be set and theE-flag MUSTE-Flag <bcp14>MUST</bcp14> be clear for Prefix-SIDs allocated to redistributed prefixes, unless the redistributed prefix is directly attached to theASBR.</t> <t>IfAutonomous System Boundary Router (ASBR).</t> <t pn="section-5-9">If the NP-Flag is not set,then anythen: </t> <ul empty="true" bare="false" spacing="normal" pn="section-5-10"> <li pn="section-5-10.1">Any upstream neighbor of the Prefix-SID originatorMUST<bcp14>MUST</bcp14> pop the Prefix-SID. This is equivalent to the penultimatehop poppinghop-popping mechanism used in the MPLSdataplane. If the NP-flag is not set, then thedata plane. </li> <li pn="section-5-10.2">The receivedE-flagE-Flag isignored.</t> <t>Ifignored. </li> </ul> <t pn="section-5-11">If theNP-flagNP-Flag is setthen:<list style="hanging"> <t> Ifand theE-flagE-Flag is not set,then anythen: </t> <ul empty="true" bare="false" spacing="normal" pn="section-5-12"> <li pn="section-5-12.1">Any upstream neighbor of the Prefix-SID originatorMUST<bcp14>MUST</bcp14> keep the Prefix-SID on top of the stack. This is useful when the originator of the Prefix-SIDneedneeds to stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at anArea Border RouterABR (prefix propagation from one area to another) or at anAS Boundary RouterASBR (prefix propagation from one domain toanother).</t> <t>Ifanother). </li> </ul> <t pn="section-5-13">If both theE-flag isNP-Flag and E-Flag are set,then anythen: </t> <ul empty="true" bare="false" spacing="normal" pn="section-5-14"> <li pn="section-5-14.1">Any upstream neighbor of the Prefix-SID originatorMUST<bcp14>MUST</bcp14> replace the Prefix-SID with anExplicit-NULLExplicit NULL label. This is useful, e.g., when the originator of the Prefix-SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXPbits.</t> </list></t> <t>Whenbits. </li> </ul> <t pn="section-5-15">When the M-Flag is set, theNP-flagNP-Flag and theE-flag MUSTE-Flag <bcp14>MUST</bcp14> be ignoredaton reception.</t><t>As<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 Serveradvertisement.Advertisement. However, PHP behaviorSHOULD<bcp14>SHOULD</bcp14> be done in the following cases:<list style="hanging"> <t>The</t> <ul empty="true" bare="false" spacing="normal" pn="section-5-17"> <li pn="section-5-17.1">The Prefix is intra-area type and the downstream neighbor is the originator of theprefix.</t> <t>Theprefix.</li> <li pn="section-5-17.2">The Prefix is inter-area type and the downstream neighbor is an ABR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with theA-flagA-Flag set for this prefix as described insection 2.1 of<xreftarget="RFC7684"/>.</t> <t>target="RFC7684" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7684#section-2.1" derivedContent="RFC7684"/>.</li> <li pn="section-5-17.3"> The Prefix is external type and the downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with theA-flagA-Flag set for this prefix as described insection 2.1 of<xreftarget="RFC7684"/>.</t> </list></t> <t>Whentarget="RFC7684" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7684#section-2.1" derivedContent="RFC7684"/>.</li> </ul> <t pn="section-5-18">When a Prefix-SID is advertised in an Extended Prefix Range TLV, then the value advertised in thePrefix SIDPrefix-SID Sub-TLV is interpreted as a starting SID/Label value.</t><t>Example<t pn="section-5-19">Example 1: If the following router addresses (loopback addresses) need to be mapped into the correspondingPrefix SIDPrefix-SID indexes:<figure suppress-title="true"> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-5-20"> Router-A: 192.0.2.1/32, Prefix-SID: Index 1 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 Router-D: 192.0.2.4/32, Prefix-SID: Index4 </artwork> </figure></t> <t>then4</artwork> <t pn="section-5-21">then the Prefix field in the Extended Prefix Range TLV would be set to 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><t>Example<t pn="section-5-22">Example 2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes:<figure suppress-title="true"> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-5-23"> 192.0.2.0/30, Prefix-SID: Index 51 192.0.2.4/30, Prefix-SID: Index 52 192.0.2.8/30, Prefix-SID: Index 53 192.0.2.12/30, Prefix-SID: Index 54 192.0.2.16/30, Prefix-SID: Index 55 192.0.2.20/30, Prefix-SID: Index 56 192.0.2.24/30, Prefix-SID: Index57 </artwork> </figure></t> <t>then57</artwork> <t pn="section-5-24">then the Prefix field in the Extended Prefix Range TLV would be set to 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> </section> <section anchor="ADJSID"title="Adjacencynumbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-adjacency-segment-identifie">Adjacency Segment Identifier(Adj-SID)"> <t>An(Adj-SID)</name> <t pn="section-6-1">An Adjacency Segment Identifier (Adj-SID) represents a router adjacency in Segment Routing.</t> <section anchor="ADJSIDSUBTLV"title="Adj-SID Sub-TLV"> <t>Adj-SIDnumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-adj-sid-sub-tlv">Adj-SID Sub-TLV</name> <t pn="section-6.1-1">Adj-SID is an optionalSub-TLVsub-TLV of the Extended Link TLV defined in <xreftarget="RFC7684"/>.target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>. ItMAY<bcp14>MAY</bcp14> appear multiple times in the Extended Link TLV. The Adj-SID Sub-TLV has the following format:<figure> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-6.1-2"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | MT-ID | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) |+---------------------------------------------------------------+ where:</artwork> </figure><list style="hanging"> <t>Type: 2</t> <t>Length: 7+---------------------------------------------------------------+</artwork> <t pn="section-6.1-3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-6.1-4"> <li pn="section-6.1-4.1"> <dl newline="false" spacing="normal" pn="section-6.1-4.1.1"> <dt pn="section-6.1-4.1.1.1">Type:</dt> <dd pn="section-6.1-4.1.1.2">2</dd> <dt pn="section-6.1-4.1.1.3">Length:</dt> <dd pn="section-6.1-4.1.1.4">7 or 8 octets,dependentdepending on theV flag.</t> <t>Flags: Single octetV-Flag</dd> <dt pn="section-6.1-4.1.1.5">Flags:</dt> <dd pn="section-6.1-4.1.1.6"> <t pn="section-6.1-4.1.1.6.1">Single-octet field containing the followingflags:<figure align="center"> <artwork>flags:</t> <artwork name="" type="" align="left" alt="" pn="section-6.1-4.1.1.6.2"> 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |B|V|L|G|P| |+-+-+-+-+-+-+-+-+ where:</artwork> </figure><list style="hanging"> <t>B-Flag: Backup+-+-+-+-+-+-+-+-+</artwork> <t pn="section-6.1-4.1.1.6.3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-6.1-4.1.1.6.4"> <li pn="section-6.1-4.1.1.6.4.1"> <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., usingIPFRRIP Fast Reroute orMPLS-FRR)MPLS-FRR (MPLS-Fast Reroute) as described insection 3.5 of<xreftarget="I-D.ietf-spring-segment-routing"/>.</t> <t>The V-Flag: Value/Indextarget="RFC8402" sectionFormat="of" section="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 anindex.</t> <t>The L-Flag: Local/Globalindex.</dd> <dt pn="section-6.1-4.1.1.6.4.1.1.5">L-Flag:</dt> <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 the value/index carried by thisSub-TLVsub-TLV has globalsignificance.</t> <t>The G-Flag: Groupsignificance.</dd> <dt pn="section-6.1-4.1.1.6.4.1.1.7">G-Flag:</dt> <dd pn="section-6.1-4.1.1.6.4.1.1.8">Group Flag. When set, the G-Flag indicates that the Adj-SID refers to a group of adjacencies (and thereforeMAY<bcp14>MAY</bcp14> be assigned to other adjacencies aswell).</t> <t>P-Flag. Persistent flag.well).</dd> <dt pn="section-6.1-4.1.1.6.4.1.1.9">P-Flag:</dt> <dd pn="section-6.1-4.1.1.6.4.1.1.10">Persistent Flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interfaceflap.</t> <t>Other bits: Reserved.flap.</dd> <dt pn="section-6.1-4.1.1.6.4.1.1.11">Other bits:</dt> <dd pn="section-6.1-4.1.1.6.4.1.1.12">Reserved. TheseMUST<bcp14>MUST</bcp14> be zero when sent and are ignored whenreceived.</t> </list></t> <t>Reserved: SHOULDreceived.</dd> </dl> </li> </ul> </dd> <dt pn="section-6.1-4.1.1.7">Reserved:</dt> <dd pn="section-6.1-4.1.1.8"> <bcp14>SHOULD</bcp14> be set to 0 on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> <t>MT-ID: Multi-Topologyreception</dd> <dt pn="section-6.1-4.1.1.9">MT-ID:</dt> <dd pn="section-6.1-4.1.1.10">Multi-Topology ID (as defined in <xreftarget="RFC4915"/>.</t> <t>Weight:target="RFC4915" format="default" sectionFormat="of" derivedContent="RFC4915"/></dd> <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 purposes. The use of the weight is defined in <xreftarget="I-D.ietf-spring-segment-routing"/>.</t> <t>SID/Index/Label: astarget="RFC8402" format="default" sectionFormat="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 <xreftarget="PREFIXSID"/>.</t> </list></t> <t>An SR capabletarget="PREFIXSID" format="default" sectionFormat="of" derivedContent="Section 5"/></dd> </dl> </li> </ul> <t pn="section-6.1-5">An SR-capable routerMAY<bcp14>MAY</bcp14> allocate an Adj-SID for each of its adjacencies and set the B-Flag when the adjacency is eligible for protection by an FRR mechanism (IP or MPLS) as described insection 3.5 of<xreftarget="I-D.ietf-spring-segment-routing"/>.</t> <t>An SR capabletarget="RFC8402" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-3.5" derivedContent="RFC8402"/>.</t> <t pn="section-6.1-6">An SR-capable routerMAY<bcp14>MAY</bcp14> allocate more than one Adj-SID to anadjacency</t> <t>An SR capableadjacency.</t> <t pn="section-6.1-7">An SR-capable routerMAY<bcp14>MAY</bcp14> allocate the same Adj-SID to differentadjacencies</t> <t>Whenadjacencies.</t> <t pn="section-6.1-8">When theP-flagP-Flag is not set, the Adj-SIDMAY<bcp14>MAY</bcp14> be persistent. When theP-flagP-Flag is set, the Adj-SIDMUST<bcp14>MUST</bcp14> be persistent.</t> </section> <section anchor="LANADJSIDSUBTLV"title="LAN Adj-SID Sub-TLV"> <t>LANnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-lan-adj-sid-sub-tlv">LAN Adj-SID Sub-TLV</name> <t pn="section-6.2-1">The LAN Adjacency SID is an optionalSub-TLVsub-TLV of the Extended Link TLV defined in <xreftarget="RFC7684"/>.target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>. ItMAY<bcp14>MAY</bcp14> appear multiple times in theExtended-LinkExtended Link TLV. It is used to advertise a SID/Label for an adjacency to a non-DR (Designated Router) router on a broadcast,NBMA,Non-Broadcast Multi-Access (NBMA), or hybrid <xreftarget="RFC6845"/>target="RFC6845" format="default" sectionFormat="of" derivedContent="RFC6845"/> network.<figure> <artwork></t> <artwork name="" type="" align="left" alt="" pn="section-6.2-2"> 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | MT-ID | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID/Label/Index (variable) |+---------------------------------------------------------------+ where:</artwork> </figure><list style="hanging"> <t>Type: 3</t> <t>Length: 11+---------------------------------------------------------------+</artwork> <t pn="section-6.2-3">where:</t> <ul empty="true" bare="false" spacing="normal" pn="section-6.2-4"> <li pn="section-6.2-4.1"> <dl newline="false" spacing="normal" pn="section-6.2-4.1.1"> <dt pn="section-6.2-4.1.1.1">Type:</dt> <dd pn="section-6.2-4.1.1.2">3</dd> <dt pn="section-6.2-4.1.1.3">Length:</dt> <dd pn="section-6.2-4.1.1.4">11 or 12 octets,dependentdepending onV-flag.</t> <t>Flags: samethe V-Flag</dd> <dt pn="section-6.2-4.1.1.5">Flags:</dt> <dd pn="section-6.2-4.1.1.6">Same as in <xreftarget="ADJSIDSUBTLV"/></t> <t>Reserved: SHOULDtarget="ADJSIDSUBTLV" format="default" sectionFormat="of" derivedContent="Section 6.1"/></dd> <dt pn="section-6.2-4.1.1.7">Reserved:</dt> <dd pn="section-6.2-4.1.1.8"> <bcp14>SHOULD</bcp14> be set to 0 on transmission andMUST<bcp14>MUST</bcp14> be ignored onreception.</t> <t>MT-ID: Multi-Topologyreception</dd> <dt pn="section-6.2-4.1.1.9">MT-ID:</dt> <dd pn="section-6.2-4.1.1.10">Multi-Topology ID (as defined in <xreftarget="RFC4915"/>.</t> <t>Weight: Weighttarget="RFC4915" format="default" sectionFormat="of" derivedContent="RFC4915"/>)</dd> <dt pn="section-6.2-4.1.1.11">Weight:</dt> <dd pn="section-6.2-4.1.1.12">Weight used for load-balancing purposes. The use of the weight is defined in <xreftarget="I-D.ietf-spring-segment-routing"/>.</t> <t>Neighbor ID: Thetarget="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.</dd> <dt pn="section-6.2-4.1.1.13">Neighbor ID:</dt> <dd pn="section-6.2-4.1.1.14">The Router ID of the neighbor for which theLAN-Adj-SIDLAN Adjacency SID isadvertised.</t> <t>SID/Index/Label: asadvertised</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 <xreftarget="PREFIXSID"/>.</t> <t>Whentarget="PREFIXSID" format="default" sectionFormat="of" derivedContent="Section 5"/></t> </dd> </dl> </li> </ul> <t pn="section-6.2-5">When theP-flagP-Flag is not set, theAdj-SID MAYLAN Adjacency SID <bcp14>MAY</bcp14> be persistent. When theP-flagP-Flag is set, theAdj-SID MUSTLAN Adjacency SID <bcp14>MUST</bcp14> bepersistent.</t> </list></t>persistent. </t> </section> </section> <sectiontitle="Elementsnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-elements-of-procedure">Elements ofProcedure">Procedure</name> <sectiontitle="Intra-areanumbered="true" toc="include" removeInRFC="false" pn="section-7.1"> <name slugifiedName="name-intra-area-segment-routing-">Intra-area SegmentroutingRouting inOSPFv2 "> <t>AnOSPFv2</name> <t pn="section-7.1-1">An OSPFv2 router that supportssegment routing MAYSegment Routing <bcp14>MAY</bcp14> advertise Prefix- SIDs for any prefix to which it is advertising reachability (e.g., a loopback IP address as described in <xreftarget="PREFIXSID"/>).</t> <t>Atarget="PREFIXSID" format="default" sectionFormat="of" derivedContent="Section 5"/>).</t> <t pn="section-7.1-2">A Prefix-SID can also be advertised by the SR Mapping Servers (as described in <xreftarget="I-D.ietf-spring-segment-routing-ldp-interop"/>).target="RFC8661" format="default" sectionFormat="of" derivedContent="RFC8661"/>). A Mapping Server advertises Prefix-SIDs for remote prefixes that exist in the OSPFv2 routing domain. Multiple Mapping Servers can advertise Prefix-SIDs for the sameprefix,prefix; in whichcasecase, the same Prefix-SIDMUST<bcp14>MUST</bcp14> be advertised by all of them. The flooding scope of the OSPF Extended Prefix Opaque LSA that is generated by the SR Mapping Server could be eitherarea-scopedarea scoped orAS-scopedAS scoped and is determined based on the configuration of the SR Mapping Server.</t><t>An<t pn="section-7.1-3">An SR Mapping ServerMUST<bcp14>MUST</bcp14> use the OSPF Extended Prefix Range TLV when advertising SIDs for prefixes. Prefixes of differentroute-typesroute types can be combined in a single OSPF Extended Prefix Range TLV advertised by an SR Mapping Server. Because 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 differentRoute-Typesroute types in the OSPF Extended Prefix Range TLV.</t><t>Area-scoped<t pn="section-7.1-4">Area-scoped OSPF Extended Prefix Range TLVs are propagated between areas. Similar to propagation of prefixes between areas, an ABR only propagates the OSPF Extended Prefix Range TLV that it considers to be the best from the set it received. The rules used to pick the best OSPF Extended Prefix Range TLV are described in <xreftarget="PFXRANGE"/>.</t> <t>Whentarget="PFXRANGE" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t> <t pn="section-7.1-5">When propagating an OSPF Extended Prefix Range TLV between areas, ABRsMUST<bcp14>MUST</bcp14> set theIA-Flag, thatIA-Flag. This is used to prevent redundant flooding of the OSPF Extended Prefix Range TLV between areas as described in <xreftarget="PFXRANGE"/>.</t>target="PFXRANGE" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t> </section> <sectiontitle="Inter-areanumbered="true" toc="include" removeInRFC="false" pn="section-7.2"> <name slugifiedName="name-inter-area-segment-routing-">Inter-area SegmentroutingRouting inOSPFv2"> <t>InOSPFv2</name> <t pn="section-7.2-1">In order to support SR in amulti-areamultiarea environment, OSPFv2MUST<bcp14>MUST</bcp14> propagate Prefix-SID information between areas. The following procedure is used to propagatePrefix SIDsPrefix-SIDs between areas.</t><t>When<t pn="section-7.2-2">When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area prefix to all its connected areas, it will also originate an OSPF Extended Prefix OpaqueLSA,LSA as described in <xreftarget="RFC7684"/>.target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>. The flooding scope of the OSPF Extended Prefix Opaque LSA type will be set to area-local scope. Theroute-typeroute type in the OSPF Extended Prefix TLV is set to 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"> <t>The</t> <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 prefix in the source area and find the advertising router associated with the best path to thatprefix.</t> <t>Theprefix.</li> <li pn="section-7.2-3.2">The ABR will then determine ifsuchthis router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connectedareas.</t> <t>Ifareas.</li> <li pn="section-7.2-3.3">If no Prefix-SID was advertised for the prefix in the source area by the router that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to otherareas.</t> </list></t> <t>Whenareas.</li> </ul> <t pn="section-7.2-4">When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area route to all its connected areas, it will also originate an OSPF Extended Prefix OpaqueLSA,LSA as described in <xreftarget="RFC7684"/>.target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>. The flooding scope of the OSPF Extended Prefix Opaque LSA type will be set to area-local scope. Theroute-typeroute type in the OSPF Extended Prefix TLV is set to 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"> <t>The</t> <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 prefix in the backbone area and find the advertising router associated with the best path to thatprefix.</t> <t>Theprefix.</li> <li pn="section-7.2-5.2">The ABR will then determine if such a router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connectedareas.</t> <t>Ifareas.</li> <li pn="section-7.2-5.3">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, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to otherareas.</t> </list></t>areas.</li> </ul> </section> <sectiontitle="Segmentnumbered="true" toc="include" removeInRFC="false" pn="section-7.3"> <name slugifiedName="name-segment-routing-for-externa">Segment Routing for ExternalPrefixes"> <t>Type-5Prefixes</name> <t pn="section-7.3-1">Type-5 LSAs are flooded domain wide. When an ASBR, which supports SR, generates Type-5 LSAs, itSHOULD<bcp14>SHOULD</bcp14> also originate OSPF Extended Prefix OpaqueLSAs,LSAs as described in <xreftarget="RFC7684"/>.target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>. The flooding scope of the OSPF Extended Prefix Opaque LSA type is set to AS-wide scope. Theroute-typeroute type in the OSPF Extended Prefix TLV is set to external. The Prefix-SID Sub-TLV is included in this LSA and the Prefix-SID value will be set to the SID that has been reserved for that prefix.</t><t>When an NSSA<t pn="section-7.3-2">When a Not-So-Stubby Area (NSSA) <xreftarget="RFC3101"/>target="RFC3101" format="default" sectionFormat="of" derivedContent="RFC3101"/> ABR translates Type-7 LSAs into Type-5 LSAs, itSHOULD<bcp14>SHOULD</bcp14> also advertise the Prefix-SID for the prefix. The NSSA ABR determines its best path to the prefix advertised in the translated Type-7 LSA and finds the advertising router associated with that path. If the 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 prefix. Otherwise, the Prefix-SID advertised by any other router will be used.</t> </section> <sectiontitle="Advertisement of Adj-SID"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-7.4"> <name slugifiedName="name-advertisement-of-adj-sid">Advertisement of Adj-SID</name> <t pn="section-7.4-1">The Adjacency Segment Routing Identifier (Adj-SID) is advertised using the Adj-SID Sub-TLV as described in <xreftarget="ADJSID"/>.</t>target="ADJSID" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t> <sectiontitle="Advertisementnumbered="true" toc="include" removeInRFC="false" pn="section-7.4.1"> <name slugifiedName="name-advertisement-of-adj-sid-on">Advertisement of Adj-SID on Point-to-PointLinks"> <t>AnLinks</name> <t pn="section-7.4.1-1">An Adj-SIDMAY<bcp14>MAY</bcp14> be advertised for any adjacency on aP2Ppoint-to-point (P2P) link that is 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 adjacencyMAY<bcp14>MAY</bcp14> be removed from the area. If the adjacency transitions to a state lowerthenthan 2-Way, then the Adj-SIDadvertisement MUSTAdvertisement <bcp14>MUST</bcp14> be withdrawn from the area.</t> </section> <sectiontitle="Adjacencynumbered="true" toc="include" removeInRFC="false" pn="section-7.4.2"> <name slugifiedName="name-adjacency-sid-on-broadcast-">Adjacency SID on Broadcast or NBMAInterfaces"> <t>Broadcast,Interfaces</name> <t pn="section-7.4.2-1">Broadcast, NBMA, or hybrid <xreftarget="RFC6845"/>target="RFC6845" format="default" sectionFormat="of" derivedContent="RFC6845"/> networks in OSPF are 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 network connect. As a result, routers on the broadcast, NBMA, or hybrid network advertise only their adjacency to the DR. Routers that do not act as DR do not form or advertise adjacencies with each other. They do, however, maintain 2-Way adjacency state with each other and are directly reachable.</t><t>When<t pn="section-7.4.2-2">When Segment Routing is used, each router on the broadcast, NBMA, or hybrid networkMAY<bcp14>MAY</bcp14> advertise the Adj-SID for its adjacency to the DR using the Adj-SID Sub-TLV as described in <xreftarget="ADJSIDSUBTLV"/>.</t> <t>SR capabletarget="ADJSIDSUBTLV" format="default" sectionFormat="of" derivedContent="Section 6.1"/>.</t> <t pn="section-7.4.2-3">SR-capable routersMAY<bcp14>MAY</bcp14> also advertise aLAN-Adj-SIDLAN Adjacency SID for other neighbors (e.g.,BDR, DR-OTHER)Backup Designated Router, DR-OTHER, etc.) on the broadcast, NBMA, or hybrid network using theLAN-ADJ-SIDLAN Adj-SID Sub-TLV as described in <xreftarget="LANADJSIDSUBTLV"/>.</t>target="LANADJSIDSUBTLV" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t> </section> </section> </section> <section anchor="IANA"title="IANA Considerations"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t pn="section-8-1">This specification updates several existing OSPFregistries.</t>registries and creates a new IGP registry.</t> <section anchor="RITLVREG"title="OSPFnumbered="true" toc="include" removeInRFC="false" pn="section-8.1"> <name slugifiedName="name-ospf-router-information-ri-">OSPF Router Information (RI) TLVsRegistry"> <t>o 8 (IANA Preallocated) - SR-Algorithm TLV</t> <t>o 9 (IANA Preallocated) - SID/Label Range TLV</t> <t>o 14 - SRRegistry</name> <t pn="section-8.1-1">The following values have been allocated:</t> <table anchor="IANA1" align="left" pn="table-1"> <name slugifiedName="name-ospf-router-information-ri-t">OSPF Router Information (RI) TLVs</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">TLV Name</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <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 BlockTLV</t> <t>o 15 - SRMSTLV</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 PreferenceTLV</t>TLV</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> <section anchor="EPLTLVREG"title="OSPFv2numbered="true" toc="include" removeInRFC="false" pn="section-8.2"> <name slugifiedName="name-ospfv2-extended-prefix-opaq">OSPFv2 Extended Prefix Opaque LSA TLVsRegistry"> <t>FollowingRegistry</name> <t pn="section-8.2-1">The following valuesare allocated:</t> <t>o 2 - OSPFhave been allocated: </t> <table anchor="IANA2" align="left" pn="table-2"> <name slugifiedName="name-ospfv2-extended-prefix-opaqu">OSPFv2 Extended 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 RangeTLV</t>TLV</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> <section anchor="EPLSTLVREG"title="OSPFv2numbered="true" toc="include" removeInRFC="false" pn="section-8.3"> <name slugifiedName="name-ospfv2-extended-prefix-tlv-">OSPFv2 Extended Prefix TLV Sub-TLVsRegistry"> <t>FollowingRegistry</name> <t pn="section-8.3-1">The following valuesarehave been allocated:</t><t>o 1 - SID/Label Sub-TLV</t> <t>o 2 -<table anchor="IANA3" align="left" pn="table-3"> <name slugifiedName="name-ospfv2-extended-prefix-tlv-s">OSPFv2 Extended PrefixSID Sub-TLV</t>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">Prefix-SID Sub-TLV</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> <section anchor="ELLSTLVREG"title="OSPFv2numbered="true" toc="include" removeInRFC="false" pn="section-8.4"> <name slugifiedName="name-ospfv2-extended-link-tlv-su">OSPFv2 Extended Link TLV Sub-TLVsRegistry"> <t>FollowingRegistry</name> <t pn="section-8.4-1">The following initial valuesarehave been allocated:</t><t>o 1 - SID/Label Sub-TLV</t> <t>o 2 - Adj-SID Sub-TLV</t> <t>o 3 - LAN<table anchor="IANA4" align="left" pn="table-4"> <name slugifiedName="name-ospfv2-extended-link-tlv-sub">OSPFv2 Extended 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/LabelSub-TLV</t>Sub-TLV</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> <section anchor="IGPALGOREG"title="IGPnumbered="true" toc="include" removeInRFC="false" pn="section-8.5"> <name slugifiedName="name-igp-algorithm-types-registr">IGP AlgorithmType Registry"> <t>IANA is requested toTypes Registry</name> <t pn="section-8.5-1">IANA has set up aregistrysubregistry called "IGP Algorithm Type" undera new category ofthe "Interior Gateway Protocol (IGP) Parameters"IANA registries.registry. The registration policy for this registry is "Standards Action" (<xreftarget="RFC8126"/>target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/> and <xreftarget="RFC7120"/>).</t> <t>Valuestarget="RFC7120" format="default" sectionFormat="of" derivedContent="RFC7120"/>).</t> <t pn="section-8.5-2">Values in this registry come from the range 0-255.</t><t><t pn="section-8.5-3"> The initial values in the IGP Algorithm Type registryare:<list style='hanging'> <t>0: Shortestare as follows:</t> <table anchor="IANA5" align="left" pn="table-5"> <name slugifiedName="name-igp-algorithm-types">IGP Algorithm Types</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">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 protocol. 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 its localpolicy.</t> <t>1: Strictpolicy.</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1">Strict Shortest Path First (SPF) algorithm based on link metric. The algorithm is identical to Algorithm00, but Algorithm 1 requires that all nodes along the path will honor the SPF routing decision. Local policy at the node claiming support for Algorithm 1MUST NOT<bcp14>MUST NOT</bcp14> alter the SPF paths computed by Algorithm1.</t> </list></t>1.</td> <td align="left" colspan="1" rowspan="1">This document</td> </tr> </tbody> </table> </section> </section> <sectionanchor="Implementation" title="Implementation Status"> <t>An implementation survey with seven questions relatedanchor="Error-handling" numbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-tlv-sub-tlv-error-handling">TLV/Sub-TLV Error Handling</name> <t pn="section-9-1">For any new TLVs/sub-TLVs defined in this document, if the length is invalid, the LSA in which it is advertised is considered malformed and <bcp14>MUST</bcp14> be ignored. An error <bcp14>SHOULD</bcp14> be logged subject to rate limiting. </t> </section> <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-10"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t pn="section-10-1">With theimplementer's support ofOSPFv2 Segment Routingwas sent to the OSPF WG list and several known implementers. This section contains responses from three implementers who completedextensions defined herein, OSPFv2 will now program thesurvey. No external means were used to verify the accuracy of the information submitted by the respondents. The respondents are considered experts on the products they reported on. Additionally, responses were omitted from implementers who indicated that they have not implemented the function yet.</t> <t>This section will be removed before publication as an RFC.</t> <t>Responses from Nokia (former Alcatel-Lucent):</t> <t>Link to a web page describing the implementation: https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Unicast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf</t> <t>The implementation's level of maturity: Production.</t> <t>Coverage: We have implemented all sections and have support for the latest draft.</t> <t>Licensing: Part of the software package that needs to be purchased.</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 result of the actual implementation experience, as the draft evolved from its initial 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 describing 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 additionMPLS data plane <xref target="RFC3031" format="default" sectionFormat="of" derivedContent="RFC3031"/> in addition to the IP data plane. Previously, LDP[RFC5036]<xref target="RFC5036" format="default" sectionFormat="of" derivedContent="RFC5036"/> or another label distribution mechanism was required to advertise MPLS labels and program the MPLS data plane.</t><t>In<t pn="section-10-2">In general, the same types of attacks that can be carried out on the IP control plane can be carried out on the MPLS control plane resulting in traffic being misrouted in the respective data planes. However, the latter can be more difficult to detect and isolate.</t><t>Existing<t pn="section-10-3">Existing security extensions as described in <xreftarget="RFC2328"></xref>target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> and <xreftarget="RFC7684"></xref>target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> apply to thesesegment routingSegment Routing extensions. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in <xreftarget="RFC7474"></xref> SHOULDtarget="RFC7474" format="default" sectionFormat="of" derivedContent="RFC7474"/> <bcp14>SHOULD</bcp14> be used.</t><t>Implementations MUST<t pn="section-10-4">Implementations <bcp14>MUST</bcp14> assure that malformedTLVTLVs andSub-TLVsub-TLVs defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv2 router or routing process. Reception of malformedTLVTLVs orSub-TLV SHOULDsub-TLVs <bcp14>SHOULD</bcp14> be counted and/or logged for further analysis. Logging of malformed TLVs andSub-TLVs SHOULDsub-TLVs <bcp14>SHOULD</bcp14> berate-limitedrate limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) 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 Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti.</t> </section> <section anchor="Acknowledgements" title="Acknowledgements"> <t>We would like to thank Anton Smirnov</middle> <back> <references pn="section-11"> <name slugifiedName="name-references">References</name> <references pn="section-11.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words forhis contribution.</t> <t>Thanksuse in RFCs toAcee Lindem forIndicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="March"/> <abstract> <t>In many standards track documents several words are used to signify thedetail review ofrequirements in thedraft, corrections, as wellspecification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussionabout detailsand suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quoteTitle="true" derivedAnchor="RFC2328"> <front> <title>OSPF Version 2</title> <author initials="J." surname="Moy" fullname="J. Moy"> <organization showOnFrontPage="true"/> </author> <date year="1998" month="April"/> <abstract> <t>This memo documents version 2 of theencoding.</t> </section> </middle> <back>OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="54"/> <seriesInfo name="RFC" value="2328"/> <seriesInfo name="DOI" value="10.17487/RFC2328"/> </reference> <reference anchor="RFC3101" target="https://www.rfc-editor.org/info/rfc3101" quoteTitle="true" derivedAnchor="RFC3101"> <front> <title>The OSPF Not-So-Stubby Area (NSSA) Option</title> <author initials="P." surname="Murphy" fullname="P. Murphy"> <organization showOnFrontPage="true"/> </author> <date year="2003" month="January"/> <abstract> <t>This memo documents an optional type of Open Shortest Path First (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 option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations 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/rfc4915" 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-Esnault"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="June"/> <abstract> <t>This document describes an extension to Open Shortest Path First (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 flexible criteria, or an in- band network management topology.</t> <t>An optional extension to exclude selected links from the default 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/rfc6845" 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 network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as Link State Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.</t> <t>This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). [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/rfc7120" 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 points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. 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/rfc7684" 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 links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully 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/rfc7770" quoteTitle="true" derivedAnchor="RFC7770"> <front> <title>Extensions to OSPF for Advertising Optional Router Capabilities</title> <author initials="A." surname="Lindem" fullname="A. Lindem" role="editor"> <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 domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique 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)). This 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 functional 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/rfc8126" 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 constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</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/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that 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/rfc8402" 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 segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t> <t>SR can be directly applied to the MPLS architecture with no change 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 popped 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 segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The 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/rfc8660" quoteTitle="true" derivedAnchor="RFC8660"> <front> <title>Segment Routing with MPLS Data Plane</title> <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" role="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 Litkowski"> <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/rfc8661" quoteTitle="true" derivedAnchor="RFC8661"> <front> <title>Segment Routing Interworking with LDP</title> <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" role="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 Litkowski"> <organization showOnFrontPage="true"/> </author> <date month="December" year="2019"/> </front> <seriesInfo name="RFC" value="8661"/> <seriesInfo name="DOI" value="10.17487/RFC8661"/> </reference> </references> <referencestitle="Normative References"> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4915.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6845.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7120.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3101.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-ldp-interop.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-mpls.xml"?> <?rfc ?>pn="section-11.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" 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 Label 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/rfc5036" quoteTitle="true" derivedAnchor="RFC5036"> <front> <title>LDP Specification</title> <author initials="L." surname="Andersson" fullname="L. Andersson" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="I." surname="Minei" fullname="I. Minei" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="B." surname="Thomas" fullname="B. Thomas" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="October"/> <abstract> <t>The architecture for Multiprotocol Label Switching (MPLS) is described 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 between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures 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/rfc7474" quoteTitle="true" derivedAnchor="RFC7474"> <front> <title>Security Extension for OSPFv2 When Using Manual Key Management</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="editor"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="April"/> <abstract> <t>The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic 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 number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation 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/rfc7855" quoteTitle="true" derivedAnchor="RFC7855"> <front> <title>Source Packet Routing in Networking (SPRING) Problem Statement 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 number 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 imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).</t> <t>This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements 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/rfc8666" 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" role="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 title="Informative References"> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"?> <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-ospfv3-segment-routing-extensions.xml"?></references> <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="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="false" pn="section-appendix.b"> <name slugifiedName="name-contributors">Contributors</name> <t pn="section-appendix.b-1">The following people gave a substantial contribution to the content of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, Bruno Decraene, 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="Psenak"> <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="Previdi"> <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> </rfc>