rfc8666xml2.original.xml   rfc8666.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8666"
<?rfc tocompact="yes"?> docName="draft-ietf-ospf-ospfv3-segment-routing-extensions-23" category="st
<?rfc tocdepth="3"?> d" submissionType="IETF" consensus="true" ipr="trust200902" obsoletes="" updates
<?rfc tocindent="yes"?> ="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
docName="draft-ietf-ospf-ospfv3-segment-routing-extensions-23"
ipr="trust200902">
<front> <front>
<title abbrev="OSPFv3 Extensions for Segment Routing">OSPFv3 Extensions <title abbrev="OSPFv3 Extensions for Segment Routing">OSPFv3 Extensions
for Segment Routing</title> for Segment Routing</title>
<seriesInfo name="RFC" value="8666"/>
<author fullname="Peter Psenak" initials="P." role="editor" <author fullname="Peter Psenak" initials="P." role="editor" surname="Psenak"
surname="Psenak"> >
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Eurovea Centre, Central 3</street> <street>Eurovea Centre, Central 3</street>
<street>Pribinova Street 10</street> <street>Pribinova Street 10</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>81109</code> <code>81109</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Stefano Previdi" initials="S." role="editor" surname="Prev
<author fullname="Stefano Previdi" initials="S." role="editor" idi">
surname="Previdi"> <organization>Cisco Systems, Inc.</organization>
<organization>Individual</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <code/>
<country/>
<code></code>
<country></country>
</postal> </postal>
<email>stefano.previdi@net</email> <email>stefano@previdi.net</email>
</address> </address>
</author> </author>
<date month="December" year="2019"/>
<date year=""/>
<area>Routing</area> <area>Routing</area>
<workgroup>Open Shortest Path First IGP</workgroup> <workgroup>Open Shortest Path First IGP</workgroup>
<keyword>MPLS, SID, IGP, OSPF, Label advertisement, Segment Routing</keyword
<keyword>MPLS</keyword> >
<keyword>SID</keyword>
<keyword>IGP</keyword>
<keyword>OSPF</keyword>
<keyword>Label advertisement</keyword>
<keyword>Segment Routing</keyword>
<abstract> <abstract>
<t>Segment Routing (SR) allows a flexible definition of end-to-end <t>Segment Routing (SR) allows a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are advertised topological subpaths called "segments". These segments are advertised
by the link-state routing protocols (IS-IS and OSPF).</t> by the link-state routing protocols (IS-IS and OSPF).</t>
<t>This document describes the OSPFv3 extensions required for Segment Rout
<t>This draft describes the OSPFv3 extensions required for Segment Routing ing
with MPLS data plane.</t> with the MPLS data plane.</t>
</abstract> </abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</note>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Segment Routing (SR) allows a flexible definition of end-to-end <t>Segment Routing (SR) allows a flexible definition of end-to-end paths
paths within IGP topologies by encoding paths as sequences of within IGP topologies by encoding paths as sequences of topological
topological sub-paths, called "segments". These segments are advertised subpaths called "segments". These segments are advertised by the
by the link-state routing protocols (IS-IS and OSPF). Prefix segments link-state routing protocols (IS-IS and OSPF). Prefix segments represent
represent an ECMP-aware shortest-path to a prefix (or a node), as per an ECMP-aware shortest path to a prefix (or a node) as per the state of
the state of the IGP topology. Adjacency segments represent a hop over a the IGP topology. Adjacency segments represent a hop over a specific
specific adjacency between two nodes in the IGP. A prefix segment is adjacency between two nodes in the IGP. A prefix segment is typically a
typically a multi-hop path while an adjacency segment, in most cases, multi-hop path while an adjacency segment, in most cases, is a one-hop
is a one-hop path. SR's control-plane can be applied to both IPv6 path. SR's control plane can be applied to both IPv6 and MPLS data
and MPLS data-planes, and does not require any additional signalling (othe planes, and it does not require any additional signaling (other than IGP
r than extensions). The IPv6 data plane is out of the scope of this
IGP extensions). The IPv6 data plane is out of the scope of this specifica specification; the OSPFv3 extension for SR with the IPv6 data plane will b
tion - e
OSPFv3 extension for SR with IPv6 data plane will be specified in a separa specified in a separate document. When used in MPLS networks, SR paths
te document. do not require any LDP or RSVP-TE signaling. However, SR can
When used in MPLS networks, SR paths do not require any LDP or RSVP-TE sig interoperate in the presence of Label Switched Paths (LSPs) established wi
nalling. th RSVP or LDP.</t>
However, SR can interoperate in the presence of LSPs established with RSVP <t>This document describes the OSPFv3 extensions required for Segment
or LDP.</t> Routing with the MPLS data plane.</t>
<t>Segment Routing architecture is described in <xref target="RFC8402" for
<t>This draft describes the OSPFv3 extensions required for Segment Routing mat="default"/>.</t>
with MPLS <t>Segment Routing use cases are described in <xref target="RFC7855" forma
data plane.</t> t="default"/>.</t>
<t>Segment Routing architecture is described in <xref target="RFC8402"/>.<
/t>
<t>Segment Routing use cases are described in <xref target="RFC7855"/>.</t
>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>This section lists some of the terminology used in this document:
<section title="Terminology"> </t>
<dl newline="false" spacing="normal" indent="12">
<t>This section lists some of the terminology used in this document: <dt>ABR:</dt>
<dd>Area Border Router</dd>
<list style="hanging"> <dt>Adj-SID:</dt>
<dd>Adjacency Segment Identifier</dd>
<t>ABR - Area Border Router</t> <dt>AS:</dt>
<dd>Autonomous System</dd>
<t>Adj-SID - Adjacency Segment Identifier</t> <dt>ASBR:</dt>
<dd>Autonomous System Boundary Router</dd>
<t>AS - Autonomous System</t> <dt>DR:</dt>
<dd>Designated Router</dd>
<t>ASBR - Autonomous System Boundary Router</t> <dt>IS-IS:</dt>
<dd>Intermediate System to Intermediate System</dd>
<t>DR - Designated Router</t> <dt>LDP:</dt>
<dd>Label Distribution Protocol</dd>
<t>IS-IS - Intermediate System to Intermediate System</t> <dt>LSP:</dt>
<dd>Label Switched Path</dd>
<t>LDP - Label Distribution Protocol</t> <dt>MPLS:</dt>
<dd>Multiprotocol Label Switching</dd>
<t>LSP - Label Switched Path</t> <dt>OSPF:</dt>
<dd>Open Shortest Path First</dd>
<t>MPLS - Multi Protocol Label Switching</t> <dt>SPF:</dt>
<dd>Shortest Path First</dd>
<t>OSPF - Open Shortest Path First</t> <dt>RSVP:</dt>
<dd>Resource Reservation Protocol</dd>
<t>SPF - Shortest Path First</t> <dt>SID:</dt>
<dd>Segment Identifier</dd>
<t>RSVP - Resource Reservation Protocol</t> <dt>SR:</dt>
<dd>Segment Routing</dd>
<t>SID - Segment Identifier</t> <dt>SRGB:</dt>
<dd>Segment Routing Global Block</dd>
<t>SR - Segment Routing</t> <dt>SRLB:</dt>
<dd>Segment Routing Local Block</dd>
<t>SRGB - Segment Routing Global Block</t> <dt>SRMS:</dt>
<dd>Segment Routing Mapping Server</dd>
<t>SRLB - Segment Routing Local Block</t> <dt>TLV:</dt>
<dd>Type Length Value</dd>
<t>SRMS - Segment Routing Mapping Server</t> </dl>
<t>
<t>TLV - Type Length Value</t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
</list></t> 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"/> <xref target="
RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Segment Routing Identifiers"> <name>Segment Routing Identifiers</name>
<t>Segment Routing defines various types of Segment Identifiers (SIDs): <t>Segment Routing defines various types of Segment Identifiers (SIDs):
Prefix-SID, Adjacency-SID, and LAN Adjacency SID.</t> Prefix-SID, Adjacency SID, and LAN Adjacency SID.</t>
<section anchor="SIDLABEL" numbered="true" toc="default">
<section anchor="SIDLABEL" title="SID/Label Sub-TLV"> <name>SID/Label Sub-TLV</name>
<t>The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined <t>The SID/Label sub-TLV appears in multiple TLVs or sub-TLVs defined
later in this document. It is used to advertise the SID or label later in this document. It is used to advertise the SID or label
associated with a prefix or adjacency. The SID/Label Sub-TLV has followi associated with a prefix or adjacency. The SID/Label sub-TLV has the fol
ng lowing
format:<figure> format:</t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) | | SID/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork><t
>where:</t>
where: <ul empty="true"><li><dl newline="false" spacing="normal">
</artwork> <dt>Type:</dt>
</figure><list style="hanging"> <dd>7</dd>
<t>Type: 7</t> <dt>Length:</dt>
<dd>3 or 4 octets.</dd>
<t>Length: Either 3 or 4 octets</t> <dt>SID/Label:</dt>
<dd>If the length is set to 3, then the 20 rightmost bits
<t>SID/Label: If length is set to 3, then the 20 rightmost bits represent a label. If the length is set to 4, then the value represe
represent a label. If length is set to 4, then the value represents nts
a 32-bit SID.</t> a 32-bit SID.</dd>
</dl></li></ul>
<t>The receiving router MUST ignore the SID/Label Sub-TLV if the len
gth is
other than 3 or 4.</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="SRCAP" numbered="true" toc="default">
<section anchor="SRCAP" title="Segment Routing Capabilities"> <name>Segment Routing Capabilities</name>
<t>Segment Routing requires some additional router capabilities to be adve rtised to <t>Segment Routing requires some additional router capabilities to be adve rtised to
other routers in the area.</t> other routers in the area.</t>
<t>These SR capabilities are advertised in the OSPFv3 Router Information O paque LSA <t>These SR capabilities are advertised in the OSPFv3 Router Information O paque LSA
(defined in <xref target="RFC7770"/>) and specified in (defined in <xref target="RFC7770" format="default"/>) and specified in
<xref target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> <xref target="RFC8665" format="default"/>.</t>
</section>
</section> <section anchor="PFXRANGE" numbered="true" toc="default">
<name>OSPFv3 Extended Prefix Range TLV</name>
<section anchor="PFXRANGE" title="OSPFv3 Extended Prefix Range TLV"> <t>In some cases, it is useful to advertise attributes for a range of
prefixes in a single advertisement. The SR Mapping Server,
<t>In some cases it is useful to advertise attributes for a range of which is described in <xref target="RFC8661" format="default"/>,
prefixes in a single advertisement. The Segment Routing Mapping Server,
which is described in <xref target="I-D.ietf-spring-segment-routing-ldp-in
terop"/>,
is an example of where SIDs for multiple prefixes can be advertised. To is an example of where SIDs for multiple prefixes can be advertised. To
optimize such advertisement in case of multiple prefixes from a optimize such advertisement in case of multiple prefixes from a
contiguous address range, OSPFv3 Extended Prefix Range TLV is defined."</t contiguous address range, OSPFv3 Extended Prefix Range TLV is defined.</t>
>
<t>The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the followin g LSAs <t>The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the followin g LSAs
defined in <xref target="RFC8362"/>: defined in <xref target="RFC8362" format="default"/>:
<list style="hanging"> </t>
<t>E-Intra-Area-Prefix-LSA</t> <ul empty="true" spacing="normal">
<t>E-Inter-Area-Prefix-LSA</t> <li>E-Intra-Area-Prefix-LSA</li>
<t>E-AS-External-LSA</t> <li>E-Inter-Area-Prefix-LSA</li>
<t>E-Type-7-LSA</t> <li>E-AS-External-LSA</li>
</list></t>
<t>Multiple OSPFv3 Extended Prefix Range TLVs MAY be advertised in each LS <li>E-Type-7-LSA</li>
A mentioned </ul>
above. The OSPFv3 Extended Prefix Range TLV has the following format: <fig <t>Multiple OSPFv3 Extended Prefix Range TLVs <bcp14>MAY</bcp14> be advert
ure> ised in each LSA mentioned
<artwork> above. The OSPFv3 Extended Prefix Range TLV has the following
format: </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | AF | Range Size | | Prefix Length | AF | Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+- -+ +- -+
| | | |]]></artwork>
<t>where:</t><ul empty="true"><li><dl newline="false" spacing="normal">
where: </artwork> <dt>Type:</dt>
</figure><list style="hanging"> <dd>9</dd>
<t>Type: 9</t> <dt>Length:</dt>
<dd>Variable, in octets, depending on the sub-TLVs.</dd>
<t>Length: Variable, in octets, dependent on Sub-TLVs.</t> <dt>Prefix Length:</dt>
<dd>Length of prefix in bits.</dd>
<t>Prefix length: Length of prefix in bits.</t> <dt>AF:</dt>
<dd>
<t>AF: Address family for the prefix. <t>Address family for the prefix.
<list style="hanging">
<t>AF: 0 - IPv4 unicast</t>
<t>AF: 1 - IPv6 unicast</t>
</list></t>
<t>Range size: Represents the number of prefixes that are covered by </t>
the <dl newline="false" spacing="normal">
advertisement. The Range Size MUST NOT exceed the number of <dt>AF:</dt>
prefixes that could be satisfied by the prefix length wit <dd>0 - IPv4 unicast</dd>
hout <dt>AF:</dt>
<dd>1 - IPv6 unicast</dd>
</dl>
</dd>
<dt>Range Size:</dt>
<dd>
<t>Represents the number of prefixes that are covered by the
advertisement. The Range Size <bcp14>MUST NOT</bcp14> exceed the num
ber of
prefixes that could be satisfied by the Prefix Length wit
hout
including: including:
<list style="hanging"> </t>
<ul empty="true" spacing="normal">
<t>Addresses from the IPv4 multicast address range (224.0
.0.0/3), if the
AF is IPv4 unicast</t>
<t>Addresses other than the IPv6 unicast addresses, if th
e
AF is IPv6 unicast</t>
</list></t>
<t>Flags: Reserved. MUST be zero when sent and are ignore <li>Addresses from the IPv4 multicast address range (224.0.0.0/3), i
d when received.</t> f the
AF is IPv4 unicast.</li>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored <li>Addresses other than the IPv6 unicast addresses, if the
on reception.</t> AF is IPv6 unicast.</li>
</ul>
</dd>
<dt>Flags:</dt>
<dd>Reserved. <bcp14>MUST</bcp14> be zero when sent and are ignored when
received.</dd>
<dt>Reserved:</dt>
<dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUST</b
cp14> be ignored on reception.</dd>
<dt>Address Prefix:</dt>
<dd>
<t>Address Prefix: <ul empty="true" spacing="normal">
<list style="hanging">
<t>For the address family IPv4 unicast, the prefix itself is <li>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 encoded as a 32-bit value. The default route is represented by a prefix of
length 0.</t> length 0.</li>
<t>For the address family IPv6 unicast, the prefix, encoded as an <li>For the address family IPv6 unicast, the prefix is encoded as an even
even multiple multiple of 32-bit words and padded with zeroed bits as necessary. This
of 32-bit words, padded with zeroed bits as necessary. This encod encoding consumes ((PrefixLength + 31) / 32) 32-bit words. </li>
ing
consumes ((PrefixLength + 31) / 32) 32-bit words. </t>
<t>Prefix encoding for other address families is beyond the scope of <li>Prefix encoding for other address families is beyond the scope o f
this specification. Prefix encoding for other address families ca n this specification. Prefix encoding for other address families ca n
be defined in the future standard-track IETF specifications.</t> be defined in future Standards Track specifications from the IETF
</list></t> stream.</li>
</list></t> </ul>
</dd>
<t>The range represents the contiguous set of prefixes with the same prefix </dl></li></ul>
length <t>The range represents the contiguous set of prefixes with the same prefi
x length
as specified by the Prefix Length field. The set starts with the prefix tha t is as specified by the Prefix Length field. The set starts with the prefix tha t is
specified by the Address Prefix field. The number of prefixes in the range is equal specified by the Address Prefix field. The number of prefixes in the range is equal
to the Range size.</t> to the Range Size.</t>
<t>If the OSPFv3 Extended Prefix Range TLVs advertising the exact same ran
<t>If the OSPFv3 Extended Prefix Range TLVs advertising the exact same rang ge appears
e appears
in multiple LSAs of the same type, originated by the same OSPFv3 router, th e LSA with in multiple LSAs of the same type, originated by the same OSPFv3 router, th e LSA with
the numerically smallest Instance ID MUST be used and subsequent instances the numerically smallest Instance ID <bcp14>MUST</bcp14> be used, and subse
of the quent instances of the
OSPFv3 Extended Prefix Range TLVs MUST be ignored.</t> OSPFv3 Extended Prefix Range TLVs <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
<section anchor="PREFIXSID" numbered="true" toc="default">
<name>Prefix-SID Sub-TLV</name>
<t>The Prefix-SID sub-TLV is a sub-TLV of the following OSPFv3 TLVs as
defined in <xref target="RFC8362" format="default"/> and in <xref target
="PFXRANGE" format="default"/>:
</t>
<ul empty="true" spacing="normal">
<section anchor="PREFIXSID" title="Prefix SID Sub-TLV"> <li>Intra-Area Prefix TLV</li>
<t>The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as
defined in <xref target="RFC8362"/> and in <xref target="PFXRANGE"/>:
<list style="hanging">
<t>Intra-Area Prefix TLV</t>
<t>Inter-Area Prefix TLV</t>
<t>External Prefix TLV</t> <li>Inter-Area Prefix TLV</li>
<t>OSPFv3 Extended Prefix Range TLV</t> <li>External Prefix TLV</li>
</list></t>
<t>It MAY appear more than once in the parent TLV and has the following <li>OSPFv3 Extended Prefix Range TLV</li>
format: </ul>
<figure> <t>It <bcp14>MAY</bcp14> appear more than once in the parent TLV and has t
<artwork> he following format:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | Reserved | | Flags | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) | | SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork><t
where:</artwork> >where:</t>
</figure><list style="hanging"> <ul empty="true"><li><dl newline="false" spacing="normal">
<t>Type: 4</t> <dt>Type:</dt>
<dd>4</dd>
<t>Length: 7 or 8 octets, dependent on the V-flag</t> <dt>Length:</dt>
<dd>7 or 8 octets, depending on the V-Flag.</dd>
<t>Flags: Single octet field. The following flags are defined: <figu <dt>Flags:</dt>
re <dd>
align="center"> <t>Single-octet field. The following flags are defined: </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| |NP|M |E |V |L | | | | |NP|M |E |V |L | | |
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+]]></artwork>
where:</artwork> <t>where:</t>
</figure><list style="hanging"> <dl newline="false" spacing="normal">
<dt>NP-Flag:</dt>
<t>NP-Flag: No-PHP flag. If set, then the penultimate hop MUST <dd>No-PHP (Penultimate Hop Popping) Flag. If set, then the penultim
NOT pop the Prefix-SID before delivering packets to the ate hop <bcp14>MUST
node that advertised the Prefix-SID.</t> NOT</bcp14> pop the Prefix-SID before delivering packets to the
node that advertised the Prefix-SID.</dd>
<t>M-Flag: Mapping Server Flag. If set, the SID was advertised <dt>M-Flag:</dt>
by a Segment Routing Mapping Server as described in <dd>Mapping Server Flag. If set, the SID was advertised
<xref target="I-D.ietf-spring-segment-routing-ldp-interop"/>.</t by an SR Mapping Server as described in
> <xref target="RFC8661" format="default"/>.</dd>
<dt>E-Flag:</dt>
<t>E-Flag: Explicit-Null Flag. If set, any upstream neighbor <dd>Explicit Null Flag. If set, any upstream neighbor
of the Prefix-SID originator MUST replace the Prefix-SID with of the Prefix-SID originator <bcp14>MUST</bcp14> replace the Pre
the Explicit-NULL label (0 for IPv4, 2 for IPv6) before forwardi fix-SID with
ng the packet.</t> the Explicit NULL label (0 for IPv4, 2 for IPv6) before forwardi
ng the packet.</dd>
<t>V-Flag: Value/Index Flag. If set, then the Prefix-SID <dt>V-Flag:</dt>
<dd>Value/Index Flag. If set, then the Prefix-SID
carries an absolute value. If not set, then the Prefix-SID carri es carries an absolute value. If not set, then the Prefix-SID carri es
an index.</t> an index.</dd>
<dt>L-Flag:</dt>
<t>L-Flag: Local/Global Flag. If set, then the value/index <dd>Local/Global Flag. If set, then the value/index
carried by the Prefix-SID has local significance. If not set, th en carried by the Prefix-SID has local significance. If not set, th en
the value/index carried by this Sub-TLV has global significance. the value/index carried by this sub-TLV has global significance.
</t> </dd>
<dt>Other bits:</dt>
<t>Other bits: Reserved. These MUST be zero when sent and are ig <dd>Reserved. These <bcp14>MUST</bcp14> be zero when sent and are ig
nored when nored when
received.</t> received.</dd>
</list></t> </dl>
</dd>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored <dt>Reserved:</dt>
on reception.</t> <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUST</b
cp14> be ignored on reception.</dd>
<t>Algorithm: Single octet identifying the algorithm the Prefix-SID <dt>Algorithm:</dt>
is associated with as defined in <dd><t>Single octet identifying the algorithm the Prefix-SID
<xref target="I-D.ietf-ospf-segment-routing-extensions"/>.</t> is associated with as defined in the IGP Algorithm Types registry
<xref target="ALGOREG" format="default"/>.</t>
<t>A router receiving a Prefix-SID from a remote node and with an al
gorithm
value that such remote node has not advertised in the SR-Algorithm T
LV
<xref target="I-D.ietf-ospf-segment-routing-extensions"/> MUST ignor
e the
Prefix-SID Sub-TLV.</t>
<t>SID/Index/Label: According to the V-Flag and L-Flag, it contains:
<list style="hanging">
<t>V-flag is set to 0 and L-flag is set to 0: The SID/Index/Label fi
eld
is a 4 octet index defining the offset in the SID/Labe
l space
advertised by this router</t>
<t>V-flag is set to 1 and L-flag is set to 1: The SID/Index/Label fi
eld
is a 3 octet local label where the 20 rightmost bits a
re used for
encoding the label value.</t>
<t>All other combinations of V-flag and L-flag are invalid and any S <t>A router receiving a Prefix-SID from a remote node and with an algori
ID thm
advertisement received with an invalid setting for V a value that the remote node has not advertised in the SR-Algorithm TL
nd L flags MUST V
be ignored.</t> <xref target="RFC8665" format="default"/> <bcp14>MUST</bcp14> ignore
</list></t> the
Prefix-SID sub-TLV.</t></dd>
<dt>SID/Index/Label:</dt>
<dd>
<t>According to the V-Flag and L-Flag, it contains:
</t>
<ul empty="true" spacing="normal">
</list></t> <li>V-Flag is set to 0 and L-Flag is set to 0: The SID/Index/Label
field is a 4-octet index defining the offset in the SID/Label
space advertised by this router.</li>
<t>If an OSPFv3 router advertises multiple Prefix-SIDs for the same pref <li>V-Flag is set to 1 and L-Flag is set to 1: The SID/Index/Label
ix, field is a 3-octet local label where the 20 rightmost bits are
topology, and algorithm, all of them MUST be ignored.</t> used for encoding the label value.</li>
<t>When calculating the outgoing label for the prefix, the router MUST <li>All other combinations of V-Flag and L-Flag are invalid and
take into account, as described below, the E, NP, and M flags advertised any SID Advertisement received with an invalid setting for V- and
by the L-Flags <bcp14>MUST</bcp14> be ignored.</li>
next-hop router if that router advertised the SID for the prefix. This </ul>
MUST be done </dd>
</dl></li></ul>
<t>If an OSPFv3 router advertises multiple Prefix-SIDs for the same prefix
,
topology, and algorithm, all of them <bcp14>MUST</bcp14> be ignored.</t>
<t>When calculating the outgoing label for the prefix, the router <bcp14>M
UST</bcp14>
take into account, as described below, the E-, NP-, and M-Flags advertis
ed by the
next-hop router if that router advertised the SID for the prefix. This
<bcp14>MUST</bcp14> be done
regardless of whether the next-hop router contributes to the best path t o the regardless of whether the next-hop router contributes to the best path t o the
prefix.</t> prefix.</t>
<t>The NP-Flag (No-PHP) <bcp14>MUST</bcp14> be set and the E-Flag <bcp14>M
<t>The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Pre UST</bcp14> be clear for Prefix-SIDs
fix-SIDs
allocated to prefixes that are propagated between areas by an ABR based on allocated to prefixes that are propagated between areas by an ABR based on
intra-area or inter-area reachability, unless the advertised prefix is d irectly intra-area or inter-area reachability, unless the advertised prefix is d irectly
attached to such ABR.</t> attached to such ABR.</t>
<t>The NP-Flag (No-PHP) <bcp14>MUST</bcp14> be set and the E-Flag <bcp14>M
<t>The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for Pre UST</bcp14> be clear for Prefix-SIDs
fix-SIDs
allocated to redistributed prefixes, unless the redistributed prefix is directly allocated to redistributed prefixes, unless the redistributed prefix is directly
attached to the advertising ASBR.</t> attached to the advertising ASBR.</t>
<t>If the NP-Flag is not set, then any upstream neighbor of the Prefix-S <t>If the NP-Flag is not set, then:</t>
ID <ul empty="true" spacing="normal">
originator MUST pop the Prefix-SID. This is equivalent to the penultimat
e
hop popping mechanism used in the MPLS dataplane. If the NP-flag is not
set,
then the received E-flag is ignored.</t>
<t>If the NP-flag is set then:<list style="hanging"> <li>Any upstream neighbor of the Prefix-SID
originator <bcp14>MUST</bcp14> pop the Prefix-SID. This is equivalent to
the
penultimate hop-popping mechanism used in the MPLS data plane.</li>
<t> If the E-flag is not set, then any upstream neighbor of the Prefix-S <li>The received E-Flag is ignored.</li>
ID </ul>
originator MUST keep the Prefix-SID on top of the stack. This is useful <t>If the NP-Flag is set and the E-Flag is not set, then:</t>
when <ul empty="true" spacing="normal">
the originator of the Prefix-SID needs to stitch the incoming packet int
o a continuing
MPLS LSP to the final destination. This could occur at an ABR
(prefix propagation from one area to another) or at an ASBR
(prefix propagation from one domain to another).</t>
<t>If the E-flag is set, then any upstream neighbor of the Prefix-SID o <li>Any upstream neighbor of the Prefix-SID originator <bcp14>MUST</bcp1
riginator 4> keep the
MUST replace the Prefix-SID with an Explicit-NULL label. This Prefix-SID on top of the stack. This is useful when the originator of
the Prefix-SID needs to stitch the incoming packet into a continuing
MPLS LSP to the final destination. This could occur at an ABR (prefix
propagation from one area to another) or at an ASBR (prefix
propagation from one domain to another).
</li>
</ul>
<t>If both the NP-Flag and E-Flag are set, then:</t>
<ul empty="true" spacing="normal">
<li>Any upstream neighbor of the Prefix-SID originator
<bcp14>MUST</bcp14> replace the Prefix-SID with an Explicit NULL label.
This
is useful, e.g., when the originator of the Prefix-SID is the final des tination is useful, e.g., when the originator of the Prefix-SID is the final des tination
for the related prefix and the originator wishes to receive the packet with the for the related prefix and the originator wishes to receive the packet with the
original Traffic Class field <xref target="RFC5462"/>.</t> original Traffic Class field <xref target="RFC5462" format="default"/>.
</list></t> </li>
</ul>
<t>When the M-Flag is set, the NP-flag and the E-flag MUST be ignored on <t>When the M-Flag is set, the NP-Flag and the E-Flag <bcp14>MUST</bcp14>
reception.</t> be ignored on reception.</t>
<t>As the Mapping Server does not specify the originator of a prefix adver
<t>As the Mapping Server does not specify the originator of a prefix adv tisement,
ertisement,
it is not possible to determine PHP behavior solely based on the Mapping Server it is not possible to determine PHP behavior solely based on the Mapping Server
advertisement. However, PHP behavior SHOULD be done in following cases: Advertisement. However, PHP behavior <bcp14>SHOULD</bcp14> be done in th
<list style="hanging"> e following cases:
<t>The Prefix is intra-area type and the downstream neighbor is t </t>
he originator <ul empty="true" spacing="normal">
of the prefix.</t>
<t>The Prefix is inter-area type and the downstream neighbor is a <li>The Prefix is intra-area type and the downstream neighbor is the ori
n ABR, which is ginator
advertising prefix reachability and is setting the LA-bit in the of the prefix.</li>
Prefix
Options as described in <xref target="RFC8362"/>.</t>
<t>The Prefix is external type and the downstream neighbor is an ASBR, which is <li>The Prefix is inter-area type and the downstream neighbor is an ABR, which is
advertising prefix reachability and is setting the LA-bit in the Prefix advertising prefix reachability and is setting the LA-bit in the Prefix
Options as described in <xref target="RFC8362"/>.</t> Options as described in <xref target="RFC8362" format="default"/>
</list></t> .</li>
<t>When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range T <li>The Prefix is external type and the downstream neighbor is an ASBR,
LV, then which is
the value advertised in the Prefix SID Sub-TLV is interpreted as a star advertising prefix reachability and is setting the LA-bit in the
ting Prefix
Options as described in <xref target="RFC8362" format="default"/>
.</li>
</ul>
<t>When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range TLV
, then
the value advertised in the Prefix-SID sub-TLV is interpreted as a star
ting
SID/Label value.</t> SID/Label value.</t>
<t>Example 1: If the following router addresses (loopback addresses)
<t>Example 1: If the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix-SID indexes: </t>
need to be mapped into the corresponding Prefix SID indexes: <figure <artwork name="" type="" align="left" alt=""><![CDATA[
suppress-title="true">
<artwork>
Router-A: 2001:DB8::1/128, Prefix-SID: Index 1 Router-A: 2001:DB8::1/128, Prefix-SID: Index 1
Router-B: 2001:DB8::2/128, Prefix-SID: Index 2 Router-B: 2001:DB8::2/128, Prefix-SID: Index 2
Router-C: 2001:DB8::3/128, Prefix-SID: Index 3 Router-C: 2001:DB8::3/128, Prefix-SID: Index 3
Router-D: 2001:DB8::4/128, Prefix-SID: Index 4 Router-D: 2001:DB8::4/128, Prefix-SID: Index 4]]></artwork>
</artwork> <t>then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV w
</figure></t> ould be set
<t>then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV
would be set
to 2001:DB8::1, the Prefix Length would be set to 128, the Range Size wo uld be set to 4, and to 2001:DB8::1, the Prefix Length would be set to 128, the Range Size wo uld be set to 4, and
the Index value in the Prefix-SID Sub-TLV would be set to 1.</t> the Index value in the Prefix-SID sub-TLV would be set to 1.</t>
<t>Example 2: If the following prefixes need to be mapped into the
<t>Example 2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes: </t>
corresponding Prefix-SID indexes: <figure suppress-title="true"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
2001:DB8:1::0/120, Prefix-SID: Index 51 2001:DB8:1::0/120, Prefix-SID: Index 51
2001:DB8:1::100/120, Prefix-SID: Index 52 2001:DB8:1::100/120, Prefix-SID: Index 52
2001:DB8:1::200/120, Prefix-SID: Index 53 2001:DB8:1::200/120, Prefix-SID: Index 53
2001:DB8:1::300/120, Prefix-SID: Index 54 2001:DB8:1::300/120, Prefix-SID: Index 54
2001:DB8:1::400/120, Prefix-SID: Index 55 2001:DB8:1::400/120, Prefix-SID: Index 55
2001:DB8:1::500/120, Prefix-SID: Index 56 2001:DB8:1::500/120, Prefix-SID: Index 56
2001:DB8:1::600/120, Prefix-SID: Index 57 2001:DB8:1::600/120, Prefix-SID: Index 57]]></artwork>
</artwork> <t>then the Prefix field in the OSPFv3 Extended Prefix Range TLV would be
</figure></t> set
<t>then the Prefix field in the OSPFv3 Extended Prefix Range TLV would b
e set
to 2001:DB8:1::0, the Prefix Length would be set to 120, the Range Size would be set to 7, to 2001:DB8:1::0, the Prefix Length would be set to 120, the Range Size would be set to 7,
and the Index value in the Prefix-SID Sub-TLV would be set to 51.</t> and the Index value in the Prefix-SID sub-TLV would be set to 51.</t>
</section> </section>
<section anchor="ADJSID" numbered="true" toc="default">
<section anchor="ADJSID" title="Adjacency Segment Identifier (Adj-SID)"> <name>Adjacency Segment Identifier (Adj-SID)</name>
<t>An Adjacency Segment Identifier (Adj-SID) represents a router <t>An Adjacency Segment Identifier (Adj-SID) represents a router
adjacency in Segment Routing.</t> adjacency in Segment Routing.</t>
<section anchor="ADJSIDSUBTLV" numbered="true" toc="default">
<section anchor="ADJSIDSUBTLV" title="Adj-SID Sub-TLV"> <name>Adj-SID Sub-TLV</name>
<t>The Adj-SID sub-TLV is an optional sub-TLV of the Router-Link TLV as
<t>The Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV as defined in
defined in <xref target="RFC8362" format="default"/>. It <bcp14>MAY</bcp14> appear
<xref target="RFC8362"/>. It MAY appear multiple times multiple times
in the Router-Link TLV. in the Router-Link TLV.
The Adj-SID Sub-TLV has the following format:<figure> The Adj-SID sub-TLV has the following format:</t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+]]></artwork><t
>where:</t>
where:</artwork> <ul empty="true"><li><dl newline="false" spacing="normal">
</figure><list style="hanging"> <dt>Type:</dt>
<t>Type: 5</t> <dd>5</dd>
<dt>Length:</dt>
<t>Length: 7 or 8 octets, dependent on the V flag.</t> <dd>7 or 8 octets, depending on the V-Flag.</dd>
<dt>Flags:</dt>
<t>Flags: Single octet field containing the following flags:<figure <dd>
align="center"> <t>Single-octet field containing the following flags:</t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|B|V|L|G|P| | |B|V|L|G|P| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork><t>where:</t>
<dl newline="false" spacing="normal">
where:</artwork> <dt>B-Flag:</dt>
</figure><list style="hanging"> <dd>Backup Flag. If set, the Adj-SID refers to an
<t>B-Flag: Backup Flag. If set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IP Fast
adjacency that is eligible for protection (e.g., using IPFRR or Reroute (IPFRR) or MPLS-FRR (MPLS Fast Reroute)) as
MPLS-FRR) as described in <xref target="RFC8402"
described in section 3.5 of <xref target="RFC8402"/>.</t> sectionFormat="of" section="3.4"/>.</dd>
<dt>V-Flag:</dt>
<t>The V-Flag: Value/Index Flag. If set, then the Adj-SID <dd>Value/Index Flag. If set, then the Adj-SID
carries an absolute value. If not set, then the Adj-SID carries carries an absolute value. If not set, then the Adj-SID carries
an index.</t> an index.</dd>
<dt>L-Flag:</dt>
<t>The L-Flag: Local/Global Flag. If set, then the value/index <dd>Local/Global Flag. If set, then the value/index
carried by the Adj-SID has local significance. If not set, then carried by the Adj-SID has local significance. If not set, then
the value/index carried by this Sub-TLV has global significance. the value/index carried by this sub-TLV has global significance.
</t> </dd>
<dt>G-Flag:</dt>
<t>The G-Flag: Group Flag. When set, the G-Flag indicates that t <dd>Group Flag. When set, the G-Flag indicates that the
he Adj-SID refers to a group of adjacencies (and therefore <bcp14>M
Adj-SID refers to a group of adjacencies (and therefore MAY be a AY</bcp14> be assigned
ssigned to other adjacencies as well).</dd>
to other adjacencies as well).</t> <dt>P-Flag.</dt>
<dd>Persistent Flag. When set, the P-Flag indicates that
<t>P-Flag. Persistent flag. When set, the P-Flag indicates that
the Adj-SID is persistently allocated, i.e., the Adj- SID value the Adj-SID is persistently allocated, i.e., the Adj- SID value
remains the same across router restart and/or interfa remains the same across router restart and/or interfa
ce flap.</t> ce flap.</dd>
<dt>Other bits:</dt>
<t>Other bits: Reserved. These MUST be zero when sent and are <dd>Reserved. These <bcp14>MUST</bcp14> be zero when sent and are
ignored when received.</t> ignored when received.</dd>
</list></t> </dl>
</dd>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored o <dt>Reserved:</dt>
n reception.</t> <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUST<
/bcp14> be ignored on reception.</dd>
<t>Weight: Weight used for load-balancing purposes. The use of the <dt>Weight:</dt>
weight is defined in <xref target="RFC8402"/>.</t> <dd>Weight used for load-balancing purposes. The use of the
weight is defined in <xref target="RFC8402" format="default"/>.</dd>
<t>SID/Index/Label: as described in <xref target="PREFIXSID"/>.</t> <dt>SID/Index/Label:</dt>
<dd>As described in <xref target="PREFIXSID" format="default"/>.</dd>
</list></t> </dl></li></ul>
<t>An SR-capable router <bcp14>MAY</bcp14> allocate an Adj-SID for each
<t>An SR-capable router MAY allocate an Adj-SID for each of its of its
adjacencies and set the B-Flag when the adjacency is eligible for protec tion by an adjacencies and set the B-Flag when the adjacency is eligible for protec tion by an
FRR mechanism (IP or MPLS) as described in <xref target="RFC8402"/>.</t> FRR mechanism (IP or MPLS) as described in <xref target="RFC8402" format
="default"/>.</t>
<t>An SR-capable router MAY allocate more than one Adj-SID to an adjacen <t>An SR-capable router <bcp14>MAY</bcp14> allocate more than one Adj-SI
cy.</t> D to an adjacency.</t>
<t>An SR-capable router <bcp14>MAY</bcp14> allocate the same Adj-SID to
<t>An SR-capable router MAY allocate the same Adj-SID to different adjac different adjacencies.</t>
encies.</t> <t>When the P-Flag is not set, the Adj-SID <bcp14>MAY</bcp14> be persist
ent. When
<t>When the P-flag is not set, the Adj-SID MAY be persistent. When the P-Flag is set, the Adj-SID <bcp14>MUST</bcp14> be persistent.</t>
the P-flag is set, the Adj-SID MUST be persistent.</t>
</section> </section>
<section anchor="LANADJSIDSUBTLV" numbered="true" toc="default">
<section anchor="LANADJSIDSUBTLV" title="LAN Adj-SID Sub-TLV"> <name>LAN Adj-SID Sub-TLV</name>
<t>The LAN Adj-SID Sub-TLV is an optional Sub-TLV of the Router-Link TLV <t>The LAN Adjacency SID is an optional sub-TLV of the Router-Link
. It MAY TLV. It <bcp14>MAY</bcp14> appear multiple times in the Router-Link TLV.
appear multiple times in the Router-Link TLV. It is used to advertise It is used
a SID/Label for an adjacency to a non-DR router on a broadcast, NBMA, or to advertise a SID/Label for an adjacency to a non-DR router on a
hybrid broadcast, Non-Broadcast Multi-Access (NBMA), or hybrid <xref target="RF
<xref target="RFC6845"/> network. C6845" format="default"/> network.
<figure> </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID | | Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+]]></artwork><t
>where:</t>
where:</artwork> <ul empty="true"><li><dl newline="false" spacing="normal">
</figure><list style="hanging"> <dt>Type:</dt>
<t>Type: 6</t> <dd>6</dd>
<dt>Length:</dt>
<t>Length: 11 or 12 octets, dependent on V-flag.</t> <dd>11 or 12 octets, depending on the V-Flag.</dd>
<dt>Flags:</dt>
<t>Flags: same as in <xref target="ADJSIDSUBTLV"/></t> <dd>Same as in <xref target="ADJSIDSUBTLV" format="default"/>.</dd>
<dt>Weight:</dt>
<t>Weight: Weight used for load-balancing purposes. The use of the <dd>Weight used for load-balancing purposes. The use of the
weight is defined in <xref target="RFC8402"/>.</t> weight is defined in <xref target="RFC8402" format="default"/>.</dd>
<dt>Reserved:</dt>
<t>Reserved: SHOULD be set to 0 on transmission and MUST be ignored <dd><bcp14>SHOULD</bcp14> be set to 0 on transmission and <bcp14>MUST<
on reception.</t> /bcp14> be ignored on reception.</dd>
<dt>Neighbor ID:</dt>
<t>Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- <dd>The Router ID of the neighbor for which the LAN Adjacency SID is
SID is advertised.</dd>
advertised.</t> <dt>SID/Index/Label:</dt>
<dd><t>As described in <xref target="PREFIXSID" format="default"/>.</t
<t>SID/Index/Label: as described in <xref target="PREFIXSID"/>.</t> >
<t>When the P-flag is not set, the LAN Adj-SID MAY be persistent. Wh
en
the P-flag is set, the LAN Adj-SID MUST be persistent.</t>
</list></t> <t>When the P-Flag is not set, the LAN Adjacency SID <bcp14>MAY</bcp14
> be persistent. When
the P-Flag is set, the LAN Adjacency SID <bcp14>MUST</bcp14> be p
ersistent.</t></dd>
</dl></li></ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Elements of Procedure"> <name>Elements of Procedure</name>
<section title="Intra-area Segment routing in OSPFv3 "> <section numbered="true" toc="default">
<t>An OSPFv3 router that supports segment routing MAY advertise Prefix- <name>Intra-area Segment Routing in OSPFv3</name>
<t>An OSPFv3 router that supports Segment Routing <bcp14>MAY</bcp14> adv
ertise Prefix-
SIDs for any prefix to which it is advertising reachability (e.g., SIDs for any prefix to which it is advertising reachability (e.g.,
a loopback IP address as described in <xref target="PREFIXSID"/>).</t> a loopback IP address as described in <xref target="PREFIXSID" format="d
efault"/>).</t>
<t>A Prefix-SID can also be advertised by SR Mapping Servers (as <t>A Prefix-SID can also be advertised by SR Mapping Servers (as
described in <xref target="I-D.ietf-spring-segment-routing-ldp-interop"/ >). A Mapping described in <xref target="RFC8661" format="default"/>). A Mapping
Server advertises Prefix-SIDs for remote prefixes that exist in the Server advertises Prefix-SIDs for remote prefixes that exist in the
OSPFv3 routing domain. Multiple Mapping Servers can advertise Prefix-SID s OSPFv3 routing domain. Multiple Mapping Servers can advertise Prefix-SID s
for the same prefix, in which case the same Prefix-SID MUST be advertise d by for the same prefix, in which case the same Prefix-SID <bcp14>MUST</bcp1 4> be advertised by
all of them. The SR Mapping Server could use either area flooding scope or all of them. The SR Mapping Server could use either area flooding scope or
autonomous system flooding scope when advertising Prefix SIDs for autonomous system flooding scope when advertising Prefix-SIDs for
prefixes, based on the configuration of the SR Mapping Server. prefixes, based on the configuration of the SR Mapping Server.
Depending on the flooding scope used, the SR Mapping Server chooses the Depending on the flooding scope used, the SR Mapping Server chooses the
OSPFv3 LSA type that will be used. If the area flooding scope is needed, OSPFv3 LSA type that will be used. If the area flooding scope is needed,
an E-Intra-Area-Prefix-LSA <xref target="RFC8362"/> an E-Intra-Area-Prefix-LSA <xref target="RFC8362" format="default"/>
is used. If autonomous system flooding scope is needed, is used. If autonomous system flooding scope is needed,
an E-AS-External-LSA <xref target="RFC8362"/> is used.</t> an E-AS-External-LSA <xref target="RFC8362" format="default"/> is used.<
/t>
<t>When a Prefix-SID is advertised by the Mapping Server, which is <t>When a Prefix-SID is advertised by the Mapping Server, which is
indicated by the M-flag in the Prefix-SID Sub-TLV (<xref indicated by the M-Flag in the Prefix-SID sub-TLV (<xref
target="PREFIXSID"/>), the route type as implied by the LSA type is igno target="PREFIXSID" format="default"/>), the route type as implied by
red and the the LSA type is ignored and the Prefix-SID is bound to the
Prefix-SID is bound to the corresponding prefix independent of the route corresponding prefix independent of the route type.</t>
type.</t>
<t>Advertisement of the Prefix-SID by the Mapping Server using an <t>Advertisement of the Prefix-SID by the Mapping Server using an
Inter-Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV Inter-Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV
<xref target="RFC8362"/> does not itself <xref target="RFC8362" format="default"/> does not itself
contribute to the prefix reachability. The NU-bit <xref target="RFC5340" contribute to the prefix reachability. The NU-bit <xref target="RFC5340"
/> MUST be set in the format="default"/> <bcp14>MUST</bcp14> be set in the
PrefixOptions field of the LSA which is used by the Mapping Server to PrefixOptions field of the LSA, which is used by the Mapping Server to
advertise SID or SID Range, which prevents the advertisement from contri buting to advertise SID or SID Range, which prevents the advertisement from contri buting to
prefix reachability.</t> prefix reachability.</t>
<t>An SR Mapping Server <bcp14>MUST</bcp14> use the OSPFv3 Extended Pref
<t>An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs w ix Range TLVs when advertising SIDs
hen advertising SIDs for prefixes. Prefixes of different route types can be combined in a sin
for prefixes. Prefixes of different route-types can be combined in a sin gle OSPFv3
gle OSPFv3
Extended Prefix Range TLV advertised by an SR Mapping Server.</t> Extended Prefix Range TLV advertised by an SR Mapping Server.</t>
<t>Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas, similar <t>Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between areas, similar
to propagation of prefixes between areas. Same rules that are used for p ropagating to propagation of prefixes between areas. Same rules that are used for p ropagating
prefixes between areas <xref target="RFC5340"/> are used for the propaga tion of prefixes between areas <xref target="RFC5340" format="default"/> are use d for the propagation of
the prefix ranges.</t> the prefix ranges.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Inter-area Segment routing in OSPFv3"> <name>Inter-area Segment Routing in OSPFv3</name>
<t>In order to support SR in a multi-area environment, OSPFv3 MUST <t>In order to support SR in a multiarea environment, OSPFv3 <bcp14>MUST
</bcp14>
propagate Prefix-SID information between areas. The following propagate Prefix-SID information between areas. The following
procedure is used to propagate Prefix SIDs between areas.</t> procedure is used to propagate Prefix-SIDs between areas.</t>
<t>When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an <t>When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an
intra-area prefix to all its connected areas, it will also include the intra-area prefix to all its connected areas, it will also include the
Prefix-SID Sub-TLV, as described in <xref target="PREFIXSID"/>. The Prefix-SID sub-TLV as described in <xref target="PREFIXSID" format="defa
Prefix-SID value will be set as follows: <list style="hanging"> ult"/>. The
<t>The ABR will look at its best path to the prefix in the source ar Prefix-SID value will be set as follows: </t>
ea <ul empty="true" spacing="normal">
<li>The ABR will look at its best path to the prefix in the source are
a
and find the advertising router associated with the best and find the advertising router associated with the best
path to that prefix.</t> path to that prefix.</li>
<t>The ABR will then determine if such router advertised a Prefix-SI D <li>The ABR will then determine if this router advertised a Prefix-SID
for the prefix and use it when advertising the Prefix-SID to other for the prefix and use it when advertising the Prefix-SID to other
connected areas.</t> connected areas.</li>
<t>If no Prefix-SID was advertised for the prefix in the source <li>If no Prefix-SID was advertised for the prefix in the source
area by the router that contributes to the best path to the area by the router that contributes to the best path to the
prefix, the originating ABR will use the Prefix-SID advertised by an y prefix, the originating ABR will use the Prefix-SID advertised by an y
other router when propagating the Prefix-SID for the prefix to other other router when propagating the Prefix-SID for the prefix to other
areas.</t> areas.</li>
</list></t> </ul>
<t>When an OSPFv3 ABR advertises Inter-Area-Prefix-LSA LSAs from an <t>When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an
inter-area route to all its connected areas, it will also include the inter-area route to all its connected areas, it will also include the
Prefix-SID Sub-TLV, as described in <xref target="PREFIXSID"/>. The Prefix-SID sub-TLV as described in <xref target="PREFIXSID" format="defa
Prefix-SID value will be set as follows: <list style="hanging"> ult"/>. The
<t>The ABR will look at its best path to the prefix in the backbone Prefix-SID value will be set as follows: </t>
<ul empty="true" spacing="normal">
<li>The ABR will look at its best path to the prefix in the backbone
area and find the advertising router associated with the best area and find the advertising router associated with the best
path to that prefix.</t> path to that prefix.</li>
<t>The ABR will then determine if such router advertised a Prefix-SI D <li>The ABR will then determine if this router advertised a Prefix-SID
for the prefix and use it when advertising the Prefix-SID to other for the prefix and use it when advertising the Prefix-SID to other
connected areas.</t> connected areas.</li>
<t>If no Prefix-SID was advertised for the prefix in the backbone <li>If no Prefix-SID was advertised for the prefix in the backbone
area by the ABR that contributes to the best path to the prefix, area by the ABR that contributes to the best path to the prefix,
the originating ABR will use the Prefix-SID advertised by any the originating ABR will use the Prefix-SID advertised by any
other router when propagating the Prefix-SID for the prefix to other other router when propagating the Prefix-SID for the prefix to other
areas.</t> areas.</li>
</list></t> </ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Segment Routing for External Prefixes"> <name>Segment Routing for External Prefixes</name>
<t>AS-External-LSAs are flooded domain wide. When an ASBR, which <t>AS-External-LSAs are flooded domain wide. When an ASBR, which
supports SR, originates an E-AS-External-LSA, it SHOULD also include supports SR, originates an E-AS-External-LSA, it <bcp14>SHOULD</bcp14> a
a Prefix-SID Sub-TLV, as described in <xref target="PREFIXSID"/>. lso include
a Prefix-SID sub-TLV as described in <xref target="PREFIXSID" format="de
fault"/>.
The Prefix-SID value will be set to the SID that has been reserved for The Prefix-SID value will be set to the SID that has been reserved for
that prefix.</t> that prefix.</t>
<t>When a Not-So-Stubby Area (NSSA) <xref target="RFC3101" format="defau
<t>When an NSSA <xref target="RFC3101"/> ABR translates an E-NSSA-LSA in lt"/> ABR
to an E-AS-External-LSA, it translates an E-NSSA-LSA into an E-AS-External-LSA, it <bcp14>SHOULD</bc
SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR p14> also
determines its best path to the prefix advertised in the translated advertise the Prefix-SID for the prefix. The NSSA ABR determines its
E-NSSA-LSA and finds the advertising router associated with that path. best path to the prefix advertised in the translated E-NSSA-LSA and
If the advertising router has advertised a Prefix-SID for the prefix, finds the advertising router associated with that path. If the
then the NSSA ABR uses it when advertising the Prefix-SID for the advertising router has advertised a Prefix-SID for the prefix, then
the NSSA ABR uses it when advertising the Prefix-SID for the
E-AS-External-LSA. Otherwise, the Prefix-SID advertised by any other E-AS-External-LSA. Otherwise, the Prefix-SID advertised by any other
router will be used.</t> router will be used.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Advertisement of Adj-SID"> <name>Advertisement of Adj-SID</name>
<t>The Adjacency Segment Routing Identifier (Adj-SID) is advertised <t>The Adjacency Segment Routing Identifier (Adj-SID) is advertised
using the Adj-SID Sub-TLV as described in <xref target="ADJSID"/>.</t> using the Adj-SID sub-TLV as described in <xref target="ADJSID" format="
default"/>.</t>
<section title="Advertisement of Adj-SID on Point-to-Point Links"> <section numbered="true" toc="default">
<t>An Adj-SID MAY be advertised for any adjacency on a P2P link that i <name>Advertisement of Adj-SID on Point-to-Point Links</name>
s <t>An Adj-SID <bcp14>MAY</bcp14> be advertised for any adjacency on a
in neighbor state 2-Way or higher. If the adjacency on a P2P link point-to-point (P2P) link that is in neighbor state 2-Way or
transitions from the FULL state, then the Adj-SID for that adjacency higher. If the adjacency on a P2P link transitions from the FULL
MAY be removed from the area. If the adjacency transitions to a state, then the Adj-SID for that adjacency <bcp14>MAY</bcp14> be remov
state lower than 2-Way, then the Adj-SID advertisement MUST be withdra ed from the
wn area. If the adjacency transitions to a state lower than 2-Way, then
from the area.</t> the Adj-SID Advertisement <bcp14>MUST</bcp14> be withdrawn from the ar
ea.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Adjacency SID on Broadcast or NBMA Interfaces"> <name>Adjacency SID on Broadcast or NBMA Interfaces</name>
<t>Broadcast, NBMA, or hybrid <xref target="RFC6845"/> networks in OSP <t>Broadcast, NBMA, or hybrid <xref target="RFC6845" format="default"/
Fv3 are > networks in OSPFv3 are
represented by a star topology where the DR is the central represented by a star topology where the DR is the central
point to which all other routers on the broadcast, NBMA, or hybrid net work connect. point to which all other routers on the broadcast, NBMA, or hybrid net work connect.
As a result, routers on the broadcast, NBMA, or hybrid network adverti se only As a result, routers on the broadcast, NBMA, or hybrid network adverti se only
their adjacency to the DR. Routers that do not act as DR do not form o r advertise their adjacency to the DR. Routers that do not act as DR do not form o r advertise
adjacencies with each other. They do, however, maintain 2-Way adjacenc y state adjacencies with each other. They do, however, maintain 2-Way adjacenc y state
with each other and are directly reachable.</t> with each other and are directly reachable.</t>
<t>When Segment Routing is used, each router on the broadcast, NBMA, o r hybrid <t>When Segment Routing is used, each router on the broadcast, NBMA, o r hybrid
network MAY advertise the Adj-SID for its adjacency to the DR using th network <bcp14>MAY</bcp14> advertise the Adj-SID for its adjacency to
e the DR using the
Adj-SID Sub-TLV as described in <xref target="ADJSIDSUBTLV"/>.</t> Adj-SID sub-TLV as described in <xref target="ADJSIDSUBTLV" format="de
fault"/>.</t>
<t>SR-capable routers MAY also advertise a LAN-Adj-SID for other neigh <t>SR-capable routers <bcp14>MAY</bcp14> also advertise a LAN
bors Adjacency SID for other neighbors (e.g., Backup Designated Router
(e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid network using (BDR), DR-OTHER, etc.) on the broadcast, NBMA, or hybrid network
the using the LAN Adj-SID sub-TLV as described in <xref
LAN-Adj-SID Sub-TLV as described in <xref target="LANADJSIDSUBTLV"/>.< target="LANADJSIDSUBTLV" format="default"/>.</t>
/t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This specification updates two existing OSPFv3 registries.</t>
<section anchor="EPLTLVREG" numbered="true" toc="default">
<name>"OSPFv3 Extended-LSA TLVs" Registry</name>
<t>The following values have been allocated:</t>
<section anchor="IANA" title="IANA Considerations"> <table anchor="IANA1" align="left">
<name>OSPFv3 Extended-LSA TLVs</name>
<t>This specification updates several existing OSPFv3 registries.</t> <thead>
<tr>
<section anchor="EPLTLVREG" title="OSPFv3 Extended-LSA TLV Registry"> <th>Value</th>
<th>Description</th>
<t>Following values are allocated:</t> <th>Reference</th>
</tr>
<t>o 9 - OSPFv3 Extended Prefix Range TLV</t> </thead>
<tbody>
<tr>
<td>9</td>
<td>OSPFv3 Extended Prefix Range TLV</td>
<td>This document</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="EXTLSAREG" numbered="true" toc="default">
<name>"OSPFv3 Extended-LSA Sub-TLVs" Registry</name>
<t>The following values have been allocated:</t>
<section anchor="EXTLSAREG" title="OSPFv3 Extended-LSA Sub-TLV registry"> <table anchor="IANA2" align="left">
<name>OSPFv3 Extended-LSA Sub-TLVs</name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
<t>o 4 - Prefix SID Sub-TLV</t> </tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>Prefix-SID sub-TLV</td>
<td>This document</td>
<t>o 5 - Adj-SID Sub-TLV</t> </tr>
<tr>
<td>5</td>
<td>Adj-SID sub-TLV</td>
<td>This document</td>
<t>o 6 - LAN Adj-SID Sub-TLV</t> </tr>
<tr>
<td>6</td>
<td>LAN Adj-SID sub-TLV</td>
<td>This document</td>
</tr>
<tr>
<td>7</td>
<td>SID/Label sub-TLV</td>
<td>This document</td>
<t>o 7 - SID/Label Sub-TLV</t> </tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Error-handling" numbered="true" toc="default">
<name>TLV/Sub-TLV Error Handling
</name>
<t>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. Errors <bcp14>SHOULD</bcp14> be logged subject
to rate limiting.
</t>
</section>
<t>With the OSPFv3 segment routing extensions defined herein, <section anchor="Security" numbered="true" toc="default">
OSPFv3 will now program the MPLS data plane <xref target="RFC3031"></xref> <name>Security Considerations</name>
. <t>With the OSPFv3 Segment Routing extensions defined herein,
Previously, LDP <xref target="RFC5036"></xref> or OSPFv3 will now program the MPLS data plane <xref target="RFC3031" format=
"default"/>.
Previously, LDP <xref target="RFC5036" format="default"/> or
another label distribution mechanism was required to advertise MPLS labels and another label distribution mechanism was required to advertise MPLS labels and
program the MPLS data plane.</t> program the MPLS data plane.</t>
<t>In general, the same types of attacks that can be carried out on the IP <t>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 tr affic control plane can be carried out on the MPLS control plane resulting in tr affic
being misrouted in the respective data planes. However, the latter can be more being misrouted in the respective data planes. However, the latter can be more
difficult to detect and isolate.</t> difficult to detect and isolate.</t>
<t>Existing security extensions, as described in <xref target="RFC5340" fo
<t>Existing security extensions as described in <xref target="RFC5340"></x rmat="default"/> and
ref> and <xref target="RFC8362" format="default"/>, apply to these Segment Routing
<xref target="RFC8362"/> apply to these segment routing
extensions. While OSPFv3 is under a single administrative domain, there c an be extensions. While OSPFv3 is under a single administrative domain, there c an be
deployments where potential attackers have access to one or more networks in the deployments where potential attackers have access to one or more networks in the
OSPFv3 routing domain. In these deployments, stronger authentication mech OSPFv3 routing domain. In these deployments, stronger authentication mech
anisms anisms,
such as those specified in <xref target="RFC4552"></xref> or such as those specified in <xref target="RFC4552" format="default"/> or
<xref target="RFC7166"></xref> <xref target="RFC7166" format="default"/>,
SHOULD be used.</t> <bcp14>SHOULD</bcp14> be used.</t>
<t>Implementations <bcp14>MUST</bcp14> ensure that malformed TLVs and sub-
<t>Implementations MUST assure that malformed TLV and Sub-TLV defined in TLVs defined in this document
this document are detected and that they do not provide a vulnerability for attackers t
are detected and do not provide a vulnerability for attackers to crash th o crash the OSPFv3
e OSPFv3 router or routing process. Reception of a malformed TLV or sub-TLV <bcp14
router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD >SHOULD</bcp14> be counted
be counted and/or logged for further analysis. Logging of malformed TLVs and sub-TLV
and/or logged for further analysis. Logging of malformed TLVs and Sub-TLV s <bcp14>SHOULD</bcp14>
s SHOULD be rate limited to prevent a Denial-of-Service (DoS) attack (distributed
be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise)
or otherwise)
from overloading the OSPFv3 control plane.</t> from overloading the OSPFv3 control plane.</t>
</section> </section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5340.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7770.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6845.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3101.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5036.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3031.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8362.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8402.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5462.xml"/>
<!-- I-D.ietf-spring-segment-routing-ldp-interop: Companion document -->
<reference anchor='RFC8661' target="https://www.rfc-editor.org/info/rfc8661">
<front>
<title>Segment Routing MPLS Interworking with LDP</title>
<section anchor="Acknowledgements" title="Contributors"> <author initials='A' surname='Bashandy' fullname='Ahmed Bashandy' role="editor">
<organization />
</author>
<t>The following people gave a substantial contribution to the content <author initials='C' surname='Filsfils' fullname='Clarence Filsfils' role="edito
of this document and should be considered as co-authors:</t> r">
<organization />
</author>
<t><figure> <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<artwork><![CDATA[ <organization />
</author>
<author initials='B' surname='Decraene' fullname='Bruno Decraene'>
<organization />
</author>
<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
<organization />
</author>
<date month='December' year='2019' />
</front>
<seriesInfo name="RFC" value="8661"/>
<seriesInfo name="DOI" value="10.17487/RFC8661"/>
</reference>
<reference anchor="ALGOREG"
target="https://www.iana.org/assignments/igp-parameters">
<front>
<title>Interior Gateway Protocol (IGP) Parameters</title>
<author><organization>IANA</organization>
</author>
</front>
</reference>
<!-- I-D.ietf-ospf-segment-routing-extensions: I-D exists-->
<reference anchor="RFC8665" target="https://www.rfc-editor.org/info/rfc866
5">
<front>
<title>OSPF Extensions for Segment Routing</title>
<author initials='P' surname='Psenak' fullname='Peter Psenak' role="editor">
<organization/>
</author>
<author initials='S' surname='Previdi' fullname='Stefano Previdi' role="editor">
<organization/>
</author>
<author initials='C' surname='Filfils' fullname='Clarence Filsfils'>
<organization/>
</author>
<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization/>
</author>
<author initials='R' surname='Shakir' fullname='Rob Shakir'>
<organization/>
</author>
<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
<organization/>
</author>
<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization/>
</author>
<date month='December' year='2019'/>
</front>
<seriesInfo name="RFC" value="8665"/>
<seriesInfo name="DOI" value="10.17487/RFC8665"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7855.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4552.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7166.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Contributors</name>
<t>The following people gave a substantial contribution to the content
of this document and should be considered coauthors:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Austria Austria
Email: hannes@rtbrick.com Email: hannes@rtbrick.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
Rob Shakir Rob Shakir
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway United States of America
Mountain View, CA 94043
US
Email: robjs@google.com
Email: robjs@google.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
Wim Henderickx Wim Henderickx
Nokia Nokia
Copernicuslaan 50 Belgium
Antwerp 2018
BE
Email: wim.henderickx@nokia.com
Email: wim.henderickx@nokia.com]]></artwork>
<artwork name="" type="" align="left" alt=""><![CDATA[
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra, Inc.
US United States of America
Email: jefftant.ietf@gmail.com
]]></artwork>
</figure></t>
Email: jefftant.ietf@gmail.com]]></artwork>
<t>Thanks to Acee Lindem for his substantial contribution to the content o f <t>Thanks to Acee Lindem for his substantial contribution to the content o f
this document.</t> this document.</t>
<t>We would like to thank Anton Smirnov for his contribution as well.</t> <t>We would like to thank Anton Smirnov for his contribution as well.</t>
</section> </section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.211
9.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.534
0.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.7770.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.6845.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.3101.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.5036.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.3031.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8362.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.5462.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 include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
.I-D.ietf-ospf-segment-routing-extensions.xml"?>
<reference anchor="ALGOREG" target="https://www.iana.org/assignments/igp-
parameters/igp-parameters.xhtml#igp-algorithm-types">
<front>
<title>IGP Algorithm Types</title>
<author>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.7855.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.455
2.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.716
6.xml"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 152 change blocks. 
785 lines changed or deleted 816 lines changed or added

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