draft-ietf-ospf-mrt.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 RFC7770 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7770.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-02" 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>Individual</organization>
   <address>
     <postal>
       <street></street>
       <city></city>
         <region></region>
         <code></code>
         <country>USA</country>       
     </postal>
     <email>jefftant.ietf@gmail.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="May" year="2016"/>

    <!-- 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 Profile TLV in Router Information LSA">

<t>A router may advertise an MRT Profile TLV to indicate support for one 
or more MRT Profiles.  The MRT Profile TLV is advertised within the OSPF 
router information LSA which is defined for both OSPFv2 and OSPFv3 in 
<xref target="RFC7770"/>. 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. An implementation SHOULD send 
a default value of 128 for the GADAG Root Selection Priority if another 
value is not explicitly configured.</t> 

<t> The length of this TLV depends on the number of MRT profiles 
supported. The ordering of the profiles inside the TLV is not 
significant. Multiple appearances of this TLV is not an error.
</t>

<t> An advertising router MUST NOT advertise the same Profile ID multiple 
times in one or more TLVs. If a receiving router receives multiple 
appearances of the same Profile ID for the same router, it MUST treat 
the advertising router as NOT supporting the MRT Profile associated with 
that Profile ID. This is the case even if the multiple appearances of 
the same Profile ID have the same GADAG Priority values. However, other 
Profile IDs advertised by the same advertising router that are not 
repeated should continue to be honored by the receiving router. The 
receiving router SHOULD also log an error message regarding the 
multiple appearances of the same Profile ID for the same router.
</t> 

</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>

<t> Note that a router that advertises support for MRT with the MRT Profile TLV 
MUST also support receipt of the MRT-Ineligible Link sub-TLVs.  This ensures that all
routers participating in a given MRT Island have the same view of the links included
in the MRT Island.</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, some proposals to
avoid micro-forwarding loops during convergence<xref
target="RFC5715"/> require 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 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 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 Profile TLV, the MRT-Ineligible Link sub-TLV, the OSPFv3 
MRT-Ineligible Link sub-TLV, and the Controlled Convergence TLV are 
defined in this document. A router that does not understand the MRT 
Profile TLV will ignore it. A router that does not advertise an MRT 
Profile TLV with a Profile ID may do so either because it doesn't 
understand the MRT Profile TLV, or because it understands these 
extensions, but chooses not to advertise support for any MRT profile. 
Routers that support the MRT Profile TLV will treat either case in the 
same manner, by excluding the router not advertising the MRT Profile 
from the particular MRT Island.</t>

<t> The MRT-Ineligible Link sub-TLVs will be ignored by a router that 
doesn't understand MRT, and a router supporting MRT must support receipt 
of the MRT-Ineligible Link sub-TLVs.</t> 

<t> Finally, applications that utilize the Controlled Convergence TLV can 
use local configuration to account for routers that do not understand 
the Controlled Convergence TLV.</t> 

<section title="Handling MRT Capability Changes">

<t>When a router that is running a version of software supporting MRT 
is downgraded to software that does not support MRT, it is important 
that the routers still running MRT do not continue to use the Router 
Information LSA (RI LSA) containing the MRT Profile TLV advertised by 
the downgraded router before the downgrade. As long as the downgraded 
router supports Opaque LSAs, the downgraded router will purge the old RI 
LSA containing the MRT Profile TLV that it originated before the 
downgrade. This will occur when the downgraded router receives the 
self-originated RI LSA after restarting, as described in Section 13.4 
and 14.1 of <xref target="RFC2328"/>. This behavior is clearly required 
when the downgraded router supports the RI LSA. </t> 

<t>It is also reasonable to expect this behavior even when the software 
on the downgraded router does not understand the RI LSA. Although this 
precise behavior is not explicitly described in <xref target="RFC2328"/> , it is reasonable to infer from the 
documents. As long as the downgraded router supports Opaque LSAs, it is 
required to flood link-state type 10 (area-local scope) Opaque LSAs, 
even those that it does not understand <xref target="RFC5250"/>. So, 
when a restarting router receives a self-originated link-state type 10 
Opaque LSA whose Option Type it does not recognize, it can (in 
principle) flood it or purge it. Purging an unknown self-originated 
Opaque LSA is the most reasonable thing to do.</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="MRT Profile and Controlled Convergence TLVs">
<t>IANA is requested to allocate values for the following OSPF Router 
Information TLV Types <xref target="RFC7770"/>: 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;
    &RFC7770;
    &RFC5340;
	<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5250.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>