One document matched: draft-ietf-ospf-mrt-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC3137 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3137.xml">
<!ENTITY RFC4915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4915.xml">
<!ENTITY RFC4970 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4970.xml">
<!ENTITY RFC5340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY I-D.atlas-rtgwg-mrt-mc-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-rtgwg-mrt-mc-arch.xml">
<!ENTITY I-D.atlas-bryant-shand-lf-timers SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-bryant-shand-lf-timers.xml">
<!ENTITY I-D.ietf-ospf-ospfv3-lsa-extend SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-ospfv3-lsa-extend.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ospf-mrt-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="OSPF Extensions to Support MRT">OSPF Extensions to Support Maximally Redundant Trees</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Shraddha Hegde" initials="S." surname="Hegde">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>Embassy Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560093</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>cbowers@juniper.net</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z. " surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<date day="18" month="October" year="2015"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>OSPF Working Group</workgroup>
<abstract>
<t>This document specifies extensions to OSPF to support the
distributed computation of Maximally Redundant Trees (MRT). Some
example uses of the MRTs include IP/LDP Fast-Reroute and global
protection or live-live for multicast traffic. The extensions
indicate what MRT profile(s) each router supports. Different MRT
profiles can be defined to support different uses and to allow
transitioning of capabilities. An extension is introduced to
flood MRT-Ineligible links, due to administrative policy.</t>
<t>The need for a mechanism to allow routers to advertise a
worst-case FIB compute/install time is well understood for
controlling convergence. This specification introduces the
Controlled Convergence TLV to be carried in the Router
Information LSA.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the OSPF extensions necessary to
support the architecture that defines how IP/LDP Fast-Reroute
can use MRTs <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. At least one
common standardized algorithm (such as the lowpoint algorithm
explained and fully documented in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>) is required so
that the routers supporting MRT computation consistently compute
the same MRTs. MRT can also be used to protect multicast
traffic via either global protection or local protection.<xref
target="I-D.atlas-rtgwg-mrt-mc-arch"/></t>
<t>IP/LDP Fast-Reroute using MRTs can provide 100% coverage for
link and node failures in an arbitrary network topology where
the failure doesn't split the network. It can also be deployed
incrementally inside an OSPF area; an MRT Island is formed of
connected supporting routers and the MRTs are computed inside
that island.</t>
<t>In the default MRT profile, a supporting router both computes
the MRTs and creates the necessary transit forwarding state
necessary to provide the two additional forwarding topologies,
known as MRT-Blue and MRT-Red.</t>
</section><!-- End of Introduction !-->
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/></t>
</section>
<section title="Terminology">
<t>For ease of reading, some of the terminology defined in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> is repeated here.</t>
<t><list style="hanging">
<t hangText="network graph: ">A graph that reflects the network
topology where all links connect exactly two nodes and broadcast
links have been transformed into the standard pseudo-node
representation.</t>
<t hangText="Redundant Trees (RT): ">A pair of trees where the
path from any node X to the root R along the first tree is
node-disjoint with the path from the same node X to the root
along the second tree. These can be computed in 2-connected
graphs.</t>
<t hangText="Maximally Redundant Trees (MRT): ">A pair of trees
where the path from any node X to the root R along the first tree
and the path from the same node X to the root along the second
tree share the minimum number of nodes and the minimum number of
links. Each such shared node is a cut-vertex. Any shared links
are cut-links. Any RT is an MRT but many MRTs are not RTs.</t>
<t hangText="MRT Island: "> From the computing router, the set of
routers that support a particular MRT profile and are connected
via MRT-eligible links.</t>
<t hangText="GADAG: ">Generalized Almost Directed Acyclic Graph -
a graph that is the combination of the ADAGs of all blocks.
Transforming a network graph into a GADAG is part of the MRT
algorithm.</t>
<t hangText="MRT-Red: "> MRT-Red is used to describe one of the
two MRTs; it is used to described the associated forwarding
topology and MT-ID. Specifically, MRT-Red is the decreasing MRT
where links in the GADAG are taken in the direction from a higher
topologically ordered node to a lower one.</t>
<t hangText="MRT-Blue: "> MRT-Blue is used to describe one of the
two MRTs; it is used to described the associated forwarding
topology and MT-ID. Specifically, MRT-Blue is the increasing MRT
where links in the GADAG are taken in the direction from a lower
topologically ordered node to a higher one.</t>
</list></t>
</section>
<section title="Overview of OSPF Extensions for MRT">
<t>There are two separate aspects that need to be advertised in OSPF.
Both derive from the need for all routers supporting an MRT profile to
compute the same pair of MRTs to each destination. By executing the
same algorithm on the same network graph, distributed routers will
compute the same MRTs. Convergence considerations are discussed in
<xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. </t>
<t>The first aspect that must be advertised is which MRT profile(s)
are supported and the associated GADAG Root Selection Priority. The
second aspect that must be advertised is any links that are not
eligible, due to administrative policy, to be part of the MRTs. This
must be advertised consistently across the area so that all routers in
the MRT Island use the same network graph.</t>
<section title="Supporting MRT Profiles">
<t>An MRT Profile defines the exact MRT Algorithm, the MRT-Red LDP MT-ID,
the MRT-Blue LDP MT-ID, and the forwarding mechanisms supported for the
transit MRT-Red and MRT-Blue forwarding topologies. Finally, the MRT
Profile defines exact behavioral rules such as:
<list style="symbols">
<t>how reconvergence is handled,</t>
<t>inter-area forwarding behavior,</t>
</list></t>
<t>A router that advertises support for an MRT Profile MUST provide the
specified forwarding mechanism for its MRT-Red and MRT-Blue forwarding
topologies. A router that advertises support for an MRT Profile MUST
implement an algorithm that produces the same set of MRT-Red and
MRT-Blue next-hops for its MRT-Red and MRT-Blue topologies as is
provided by the algorithm specified in the MRT Profile.</t>
<t>A router MAY indicate support for multiple MRT Profiles. A router
computes its local MRT Island for each separate MRT Profile that the
router supports. Supporting multiple MRT Profiles also provides
a mechanism for transitioning from one profile to another.
Different uses of MRT
forwarding topologies may behave better on different MRT profiles.</t>
<t>The default MRT Profile is defined in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. Its behavior is
intended to support IP/LDP unicast and multicast fast-reroute.</t>
</section>
<section title="GADAG Root Selection">
<t>One aspect of the MRT algorithms is that the selection of the GADAG
root can affect the alternates and the traffic through that GADAG
root. Therefore, it is important to provide an operator with control
over which router will play the role of GADAG root. A measure of the
centrality of a node may help determine how good a choice a particular
node is.</t>
<t>The GADAG Root Selection Policy (defined as part of an MRT profile)
may make use of the GADAG Root Selection
Priority value advertised in the MRT Profile TLV of the Router Information
LSA. For example, the GADAG Root Selection Policy for the default
MRT profile is the following: Among the routers in the
MRT Island and with the highest priority advertised, an implementation
MUST pick the router with the highest Router ID to be the GADAG
root.</t>
</section>
<section title="Triggering an MRT Computation">
<t>When an MRT Computation is triggered, it is triggered for a given
MRT Profile in a given area. First, the associated MRT Island is
determined. Then, the GADAG Root is selected. Finally, the actual
MRT algorithm is run to compute the transit MRT-Red and MRT-Blue
topologies. Additionally, the router MAY choose to compute MRT-FRR
alternates or make other use of the MRT computation results.</t>
<t>Prefixes can be attached and detached and have their associated
MRT-Red and MRT-Blue next-hops computed without requiring a new MRT
computation.</t>
</section>
</section>
<section title="MRT Capability Advertisement">
<t>A router that supports MRT indicates this by setting a newly
defined M bit in the Router LSA. If the router provides no other
information via a separate MRT Profile TLV, then the router supports
the default MRT Profile with a GADAG Root Selection Priority of
128.</t>
<t>In addition, a router can advertise a newly-defined MRT Profile TLV
within the scope of the OSPF router information LSA <xref
target="RFC4970"/>. This TLV also includes the GADAG Root Selection
Priority.</t>
<section title = "Advertising MRT Capability in OSPFv2">
<t>A new M-bit is defined in the Router-LSA (defined in <xref
target="RFC2328"/> and updated in <xref target="RFC4915"/>), as pictured
below.</t>
<figure title="M-bit in OSPFv2 Router LSA">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*|*|M|N|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # MT-ID | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="M bit: "> When set, the router supports MRT. If no
separate MRT Profile TLV is advertised in the associated Router
Information LSA, then the router supports the default MRT Profile
for the default MT topology and
has a GADAG Root Selection Priority of 128.</t>
</list></t>
</section>
<section title = "Advertising MRT Capability in OSPFv3">
<t>Similarly, the M-bit is defined in the OSPFv3 Router LSA <xref
target="RFC5340"/> as shown below. Since there can be multiple router
LSAs in OSPFv3, the M-bit SHOULD be set in all of them. However, in the
case of a mismatch, the values in the LSA with the lowest Link State ID
take precedence.</t>
<figure title="M-bit in OSPFv3 Router LSA">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0|M|Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="M bit: "> When set, the router supports MRT. If no separate
MRT Profile TLV is advertised in the associated Router Information LSA,
then the router supports the default MRT Profile for the default MT
topology and has a GADAG Root Selection Priority of 128.</t>
</list></t>
</section>
<section title="MRT Profile TLV in Router Information LSA">
<t>A router may advertise an MRT Profile TLV to indicate support for
multiple MRT Profiles, for a non-default MRT Profile, and/or to
indicate a non-default GADAG Root Selection Priority. The MRT Profile
TLV is advertised within the OSPF router information LSA which is
defined for both OSPFv2 and OSPFv3 in
<xref target="RFC4970"/>. The RI LSA MUST have area scope.</t>
<t> Note that the presence of the MRT Profile TLV indicates support for
a given MRT profile in the default topology (MT-ID = 0). The extensions
in this document do not define a method to advertise support for MRT
profiles in topologies with non-zero MT-ID. </t>
<figure title="MRT Profile TLV in Router Information LSA">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(1) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(n) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA)
LENGTH: 4 * (number of Profiles)
Profile ID : 1 byte
GADAG Priority: 1 byte
]]></artwork>
</figure>
<t> Each Profile ID listed indicates support for a given MRT Profile, as defined
in <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. A Profile ID
value of 0 corresponds to the default MRT profile.</t>
<t> The GADAG Priority is the GADAG Root Selection Priority associated
with the advertising router in the MRT Island for the associated MRT
Profile, as indicated by the Profile ID. If multiple MRT Profiles are
supported, then the length of this TLV varies. The ordering of the
profiles inside the TLV is not significant. Multiple appearances of
this TLV is not an error.</t>
<t> Lack of support for the default MRT profile
is indicated by the presence of
an MRT Profile TLV with a non-zero Profile ID value,
and the absence of an MRT Profile TLV with a zero Profile ID value.</t>
</section>
</section>
<section title="Advertising MRT-ineligible links for MRT">
<t>Due to administrative policy, some otherwise eligible links in the
network topology may need to be excluded from the network graph upon
which the MRT algorithm is run. Since the same network graph must be
used across the area, it is critical for OSPF to flood which links to
exclude from the MRT calculation. This is done by introducing a new
MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried
in the Extended Link TLV defined in
<xref target="I-D.ietf-ospf-prefix-link-attr"/>. For
OSPFv3, this sub-TLV is carried in the Router-Link TLV defined in
<xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/>.
</t>
<t>If a link is marked by administrative policy as MRT-Ineligible,
then a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router-Link TLV)
for that link, including the MRT-Ineligible Link sub-TLV. The
OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV
have area wide scope.</t>
<section title="MRT-Ineligible Link sub-TLV">
<figure title="MRT-Ineligible Link sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV
TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV
(To Be Allocated by IANA)
LENGTH: 0
]]></artwork>
</figure>
<t>This zero-length sub-TLV can appear in the OSPFv2 Extended
Link TLV or the OSPFv3 Router-Link TLV. Its presence indicates
that the associated link MUST NOT be used in the MRT calculation for
all profiles.</t>
</section>
</section>
<section title="Worst-Case Network Convergence Time">
<t>As part of converging the network after a single failure, Section
12.2 of <xref target ="I-D.ietf-rtgwg-mrt-frr-architecture"/>
describes the need to wait for a configured or advertised period for
all routers to be using their new SPTs. Similarly, any work on
avoiding micro-forwarding loops during convergence<xref
target="RFC5715"/> requires determining the maximum among all routers
in the area of the worst-case route computation and FIB installation
time. More details on the specific reasoning and need for flooding it
are given in <xref target="I-D.atlas-bryant-shand-lf-timers"/>.</t>
<figure title="Controlled Convergence TLV in Router Information LSA">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | FIB compute/install time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA)
LENGTH: 4
FIB compute/install time: This is the worst-case time the router
may take to compute and install all OSPF routes in the area
after a change to a stable network. The value is
in milliseconds.
]]></artwork>
</figure>
<t>The Controlled Convergence TLV is carried in the Router Information
LSA and flooded with area-wide scope.
The FIB compute/install time value sent by a router SHOULD be an estimate taking
into account network scale or real-time measurements, or both.
Advertisements SHOULD be dampened to avoid frequent
communication of small changes in the FIB compute/install time.</t>
<t>A router receiving the Controlled Convergence sub-TLV SHOULD
estimate the network convergence time as the maximum of the
FIB compute/install times advertised by the routers in an area,
including itself. In order to account for routers that do not advertise
the Controlled Convergence sub-TLV, a router MAY use a locally configured
minimum network convergence time as a lower bound on the computed
network convergence time. A router MAY use a locally configured
maximum network convergence time as an upper bound on the computed
network convergence time.
</t>
</section>
<section title="Backwards Compatibility">
<t>The MRT capability bit, the MRT Profile, the MRT-Ineligible Link,
and the OSPFv3 MRT-Ineligible Link TLVs are defined in this document.
They should not introduce any interoperability issues. Routers that
do not support the MRT capability bit in the router LSA SHOULD
silently ignore it. Routers that do not support the new MRT-related
TLVs SHOULD silently ignore them.</t>
<section title="Handling MRT Capability Changes">
<t>When a router changes from supporting MRT to not supporting MRT, it
is possible that Router Information LSAs with MRT-related TLVs remain
in the neighbors' database briefly. Such MRT-related TLVs SHOULD be
ignored when the associated Router LSA from that router does not have
the M-bit set in its Router LSA.</t>
<t>When a router changes from not supporting MRT to supporting MRT, it
will flood its Router LSA(s) with the M-bit set and may send an
updated Router Information LSA. If a Router LSA is received with the
M-bit newly set, an MRT computation SHOULD be scheduled but MAY be
delayed up to 60 seconds to allow reception of updated related Router
Information LSAs. In general, when changes in MRT-related information
are received, an MRT computation SHOULD be triggered.</t>
<t>The rationale behind using the M-bit in the Router LSA is to properly
handle the MRT capability changes in case of software version downgrade.
Without the M-bit mechanism, routers would need to rely only on the
presence or absence of the MRT Profile TLV in the Router Information LSA
to determine which other routers support MRT. This could lead the to
following scenario. Router A is running a software version supporting
MRT and has MRT enabled with profile 0. Therefore, router A advertises
the MRT Profile TLV in the Router Information LSA, and other routers in
the network store that RI LSA. Router A is downgraded to a version of
software supporting neither MRT nor the Router Information LSA. When
router A restarts, it will not originate the RI LSA, since it doesn't
support it. However, the other routers in the network will still have a
RI LSA from router A indicating support for MRT with profile 0. This is
an undesirable state.</t>
<t> Requiring the M-bit in the Router LSA avoids this scenario. Before
the software downgrade, router A originates a Router LSA with the M-bit
set. After the software downgrade, router A will originate a new Router
LSA with the M-bit unset. The M bit in router LSA ensures the latest
MRT capability information is available for computation when there is
a downgrade to a version that doesn't support MRT and RI LSA.</t>
</section>
</section>
<section title="Implementation Status">
<t>
[RFC Editor: please remove this section prior to publication.]
</t>
<t>Please see <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/> for
details on implementation status.</t>
</section>
<section title="Security Considerations">
<t>This OSPF extension is not believed to introduce new security
concerns. It relies upon the security architecture already provided
for Router LSAs and Router Information LSAs.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Anil Kumar SN for
his suggestions and review.</t>
</section>
<section title="IANA Considerations">
<section title="M-bit">
<t>IANA is requested to allocate the M-bit(value 0x20 in the
router properties field of the Router-LSA) <xref target="RFC2328"/>
<xref target="RFC4940"/> from
the OSPFv2 Router Properties Registry.
The contents of the OSPFv2 Router Properties Registry
after implementing the above request is shown below.</t>
<figure>
<artwork align="left"><![CDATA[
Value Description Reference
----- ----------- ---------
0x01 B-bit [RFC2328]
0x02 E-bit [RFC2328]
0x04 V-bit [RFC2328]
0x08 W-bit [RFC1584]
0x10 Nt-bit [RFC3101]
0x20 M-bit [This draft]
]]></artwork>
</figure>
<t> This document also defines the corresponding M-bit for OSPFv3
Router-LSAs. <xref target="RFC4940"/> created several IANA registries
for OSPFv2 and OSPFv3, including the OSPFv2 Router Properties Registry
above. However, it did not create a corresponding OSPFv3 Router
Properties Registry. <xref target="RFC5340"/> discusses the
corresponding OSPFv2 bits which were already defined at the time, and it
indicates that those bits have the same meaning in OSPFv3 as in OSPFv2.
Therefore, it would be reasonable to assume that the OSPFv2 Router
Properties Registry also applies to OSPFv3. This documents requests that
IANA make this assumption explicit in the following way.</t>
<t>IANA is requested to rename the "OSPFv2 Router Properties Registry"
to the "OSPF Router Properties Registry (both v2 and v3)". The following
text should remain in this document.</t>
<t> The IANA registry "OSPF Router Properties Registry (both v2 and v3)"
applies to the 8-bit field following the length field in the Router-LSA
in both OSPFv2 and OSPFv3. </t>
</section>
<section title="MRT Profile and Controlled Convergence TLVs">
<t>IANA is requested to allocate values for the following OSPF Router
Information TLV Types <xref target="RFC4970"/>: MRT Profile TLV
(TBA-MRT-OSPF-1), and Controlled Convergence TLV (TBA-MRT-OSPF-4). The
requested entries in the OSPF Router Information (RI) TLVs registry are shown
below.</t>
<figure>
<artwork align="left"><![CDATA[
Type Value Capabilities Reference
------------- ---------------------- ------------
TBA-MRT-OSPF-1 MRT Profile TLV [This draft]
TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft]
]]></artwork>
</figure>
</section>
<section title="MRT-Ineligible Link sub-TLV">
<t>IANA is requested to allocate a value from the OSPF Extended Link TLV
sub-TLV registry defined in <xref
target="I-D.ietf-ospf-prefix-link-attr"/> for the MRT-Ineligible Link
sub-TLV (TBA-MRT-OSPF-2). The OSPF Extended Link TLV sub-TLV registry
after implementing the above request is shown below.</t>
<figure>
<artwork align="left"><![CDATA[
Value Description Reference
------------- ---------------------- ------------
0 Reserved [prefix-link-attr-draft]
TBA-MRT-OSPF-2 MRT-Ineligible Link sub-TLV [This draft]
2-32767 Unassigned [prefix-link-attr-draft]
32768-33023 Reserved for Experimental Use [prefix-link-attr-draft]
33024-65535 Reserved [prefix-link-attr-draft]
]]></artwork>
</figure>
<t>IANA is requested to allocate a value from the
OSPFv3 Extended-LSA sub-TLV registry
<xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/>
for the MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-3).
The OSPFv3 Extended-LSA sub-TLV registry has not yet been
created by IANA. </t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2328;
&RFC4970;
&RFC5340;
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4940.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-architecture-07.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-mrt-frr-algorithm-06.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-prefix-link-attr-13.xml"?>
&I-D.ietf-ospf-ospfv3-lsa-extend;
</references>
<references title="Informative References">
&RFC2119;
&RFC3137;
&RFC4915;
&RFC5715;
&I-D.atlas-rtgwg-mrt-mc-arch;
&I-D.atlas-bryant-shand-lf-timers;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:34:11 |